Huh? It's perfectly valid in theory for one piece of trusted JavaScript to download another from an insecure source and validate it before evalling it - the attack scenario is not the browser being compromised, it's the source delivering malicious code. (Whether this is really a useful thing to do compared to serving all the JS in one place is another question.)
Real systems that try to implement this scheme generally wind up implementing the misconception that everything that contributes to the JS runtime comes from discrete Javascript files.
I tried googling javascript runtime (primarily v8) exploitation and haven't been able to find any examples of this ever happening.
Edit: I'm not saying its not plausible, but wouldn't it require root/user access? What benefit would it provide over other type of attacks with that level of access? Just because there's no browser tools to check for it?
Although these vulnerabilities are imple-
mentation errors in WebKit, the presence of the
bugs illustrates the fragility of the general architec-
ture. (Other browsers have historically had similar
vulnerabilities [17, 18, 19].) We detail these vulner-
abilities and construct proof-of-concept exploits to
demonstrate how an attacker can leverage a leaked
JavaScript pointer to inject a malicious script into
an honest security origin.
That's the thing about Javascript. The tiniest little XSS or subtle origin violation results in the entire browser app being 100% 'pwned' (to use the technical term).
The pwnage can even persist into the future for that user when you consider the ability of browsers to cache content and HTML5's data store.
