My guess: many CDNs allow you to exclude the querystring from the cache key, so it's possible that one person requested the URL with ?torrent in the querystring (which causes S3 to serve a .torrent response) and that the request hit a cold cache. The response with type application/x-bittorrent was then cached under the querystring-less cache key, causing it to be served to anyone else hitting that edge node with the path /widgets/tweet_button.html.
platform.twitter.com is currently CNAMEd to EdgeCast CDN. It looks like the CDN is sitting in front of Amazon S3; http://platform.twitter.com/blahblahblah gives an S3-like 403 response.
Not only can S3 serve the file as a torrent, if you provide it as a torrent link and have disabled read access to the file, S3 will still serve as the tracker as long as other peers in the swarm have a full copy of the file to serve.
This visualization of the domain name resolution for platform.twitter.com might help to understand the issue. I don't know how to interpret it however.
http://dnsviz.net/d/platform.twitter.com/dnssec/
This seems like a major security issue, since some browsers (Chrome, at the very least, and probably others) can be set to automatically open a torrent client when links to .torrent files are clicked.
It implies downloading a file onto the users machine without user consent which is, in itself, a problem. More importantly, an attacker could craft a torrent file that exploits vulnerabilities in the torrent client. If, just by visiting a site, an attacker can download an arbitrary file onto your machine and then have it automatically opened in a known program you're in big trouble.
I don't understand, if the user is prompted to download the file using an external application it's no different than a direct download.
If users have their browsers configured to automatically start the download of any .torrent files without confirmation, twitter giving bogus .torrent is no more dangerous than $malware_site linking a .torrent. So that's not a security issue on twitter's site.
And anyway, I still fail to see how downloading a file (through bittorent or otherwise) constitutes a security breach on its own. Unless of course the bittorent client auto-executes binaries when it's done downloading, but that's just silly (and still nothing to do with twitter's security policy).
The flow of a (possible) attack is something like this:
1. User configures browser to automatically start torrent downloads when a ".torrent" link is clicked
2. User clicks twitt button which leads to a torrent file
3. The file is downloaded and opened in a torrent client
At this point, one could imagine a specifically crafted torrent file which exploits some vulnerability of the torrent client to gain (say) arbitrary code execution and now the user is, to use a mild term, screwed.
This attack could be used by any malicious site, really, but it's easier to get people to click a twitt button rather than some link on some site and besides, by preforming the attack this way the attacker would infect a sizable chunk of all internet sites (any site that uses the twitt button).
One could also imagine a specially crafted image file which exploits some vulnerability of the graphics library to gain arbitrary code execution. Then you just need the user to look at the twitter button.
Again: this is just my guess.