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.