True story from my early days at Microsoft.

You haven't known fear until the day you wake up and see the headline on ZDNet.com that morning is "Worst Internet Explorer Security Hole Ever Has Been Discovered In 'Blah'" where 'Blah' is code you wrote yourself six months previously.

Immediately upon getting to work I checked the change logs and discovered that someone on another team -- someone we trusted to make changes to the product -- had checked out my code, changed a bunch of the security registry key settings for no good reason, checked it back in, and never got a code review or told anyone about it. To this day I have no idea what on earth he thought he was doing; he left the company shortly thereafter. (Of his own accord.)

(UPDATE: A few responses to issues raised in the comments:

First, note that I choose to take the charitable position that the security key changes were unintentional and based on carelessness or unfamiliarity, rather than malice. I have no evidence one way or the other, and believe that it is wise to attribute mistakes to human fallibility.

Second, our checkin systems are much, much stronger now than they were twelve years ago. For example, it is now not possible to check in code without the checkin system emailing the change list to interested parties. In particular, changes made late in the ship cycle have a lot of "process" around them which ensures that the right changes are being made to ensure the stability and security of the product.)

Anyway, the bug was that an object which was NOT safe to be used from Internet Explorer had been accidentally released as being marked "safe for scripting". The object was capable of writing binary files -- OLE Automation type libraries, in fact -- to arbitrary disk locations. This meant that an attacker could craft a type library that contained certain strings of hostile code, save it to a path that was a known executable location, give it the extension of something that would cause a script to run, and hope that somehow the user would accidentally run the code. I do not know of any successful "real world" attacks that used this vulnerability, but it was possible to craft a working exploit with it.

We shipped a patch pretty darn quickly for that one, let me tell you.

I caused and subsequently fixed many more security holes in JScript, but none of them ever got anywhere near the publicity that one did.