Bug 35516 was reported as a memory leak but if memory leaks you wouldn't notice because you run out of memory first. Rather than telling you to go read the bug, I can summarize it quickly:

XSLT is part of the web XSLT allows scientific notation for input numbers XSLT allows roman numerals for stringifying numbers (why? it's likely useful when numbering an ordered list of items, for example)

You can helpfully combine the above by making a document containing the following, as the bug reporter did:

<xsl:number value="1e100" format="i"/>

and with that you'll discover that libxml's XSLT support consumes all available memory in computing the resulting string.

On the one hand, this is just an amusing anecdote; there are plenty of other ways you can make a page consume all available memory. ("Doctor, it hurts when I write out 1e100 in unary.") On the other hand, every one of these sorts of bugs leads to a full browser crash in single-process browsers. Mozilla quickly fixed the equivalent bug, but now that I look it seems they're cherry-picking it onto branches just recently; who knows how/whether other browser vendors are affected. My security friends tell me that OOMs are common in browsers so this isn't much of an emergency; it's not like there's any shortage of ways to crash IE.

What this anecdote most goes to show is this: there is a ton of API exposed to the web, more than you would ever expect. As I like to say to people, sandboxing WebKit is not because we didn't think WebKit wasn't a well-written piece of software — its popularity proves it is quite good — but rather that there is just too much code there to be confident it is all safe and correct.