news noscript vulnerability allows malicious scripts to run unchecked

NoScript vulnerability allows malicious scripts to run unchecked

Security researcher Linus Särud has uncovered a security vulnerability in the popular NoScript browser extension that could allow an attacker to run arbitrary JavaScript in a victim's browser. An exploit of this vulnerability could expose private data or lead users to download malicious software.

The attack works because NoScript has a limited whitelist of trusted domains, allowing the host browser to load commonly-used tools from certain content delivery networks like This feature tries to preserve websites' functionality while simultaneously blocking any potentially malicious code.

Because the extension will implicitly trust any subdomain whose parent domain is present in the whitelist, Särud found that NoScript will trust the subdomain, which hosts Google's Cloud Storage service. He uploaded a small test script there, which cleanly got past NoScript.

Särud built upon the work of Matthew Bryant, another security researcher, who found that the whitelist itself was stale—it contained the unused domain Bryant registered for a mere $10.69, and put up a proof-of-concept script that NoScript dutifully let through.

Both Särud and Bryant contacted NoScript's author about these issues. An updated version of the extension that closes the loopholes noted above is now available, so NoScript users should update immediately.

0 responses to “NoScript vulnerability allows malicious scripts to run unchecked

  1. More insecure JavaScript crappage. My prediction – in the next 5 years if we’re lucky the big browser vendors will come up with a broken clone of the Java virtual machine complete with a half-arsed clone of the security mechanisms.

  2. Only an issue if you have, et al. whitelisted — which at least some of us do not, so this purported vulnerability is not valid in some cases.

    I would be nice if a ‘except this subdomain’ feature did exist though, which I’m hoping the update provides. Will check shortly…

  3. A part of me is wondering exactly why it is that the default package even has a white-list. It’s not like your internet is functional without at least a month of script-permissions cherry picking, so what is so special that makes more special than, say, or any of a dozen other CDNs that don’t get the same preferential treatment?

    Honestly, while I like no-script, I wish it was focused on specific scripts, rather than specific domains, and I also don’t see the need for a pre-existing secret whitelist… curated or not. If I wanted that, I’d go with the less secure “Yes Script” and take my chances.

  4. I just went through and cleaned out my whitelist of unnecessary stuff. Probably worth doing every few months… some stuff was accidentally put there instead of temporary permissions.

    “” was not one of them however…

  5. I’m just surprised they let their whitelist go stale.

    Although it’s not a big/huge operation, noscript.

  6. Mine updated last night. I wonder if it was the fix for this outdated whitelist issue. I’ll check the updates the next time NoScript updates again.

    Thanks for the heads up.

  7. No, you are still better off with no script. It just means noscript isn’t perfect, but then what software is perfect?

    I definitely wouldn’t call this a vulnerability. If it got through noscript then you still other layers of protection like AV and other malware protection. I feel the title is a bit sensational.

  8. Doesn’t sound like it, outside of a (slightly)false sense of security perhaps.

    If you count the vast number of potentially harmful things it can block I don’t think there being a few holes is going to make not using NoScript a valid alternative, especially if there aren’t any new vulnerabilities that weren’t there to begin with.

  9. No. So while it’s good to fix NoScript, calling this a “NoScript Vulnerability” is a bit much. It’s more like: Under some scenarios NoScript fails to prevent already vulnerable web browsers from executing malicious javascript.

  10. Does this make users any more vulnerable than if they hadn’t used NoScript at all?

  11. Considering NoScript seems to update itself 3 times a week, this shouldn’t be a problem for long.