Outdated and unverified code on your pages

Bootstrap, Handlebars, DOMPurify: three libraries with known holes still on live sites

jQuery gets named in every "outdated library" article, and rightly so. But it's not the only one sitting on live pages at a version with a published exploit. Three others show up constantly, and they're easy to overlook because they're not the kind of dependency you think about after you add it: a UI framework, a templating engine, and, ironically, a security library whose whole job is to protect you.

If any of these is on your page below its safe version, the vulnerability isn't theoretical. The CVE is public, the exploit is usually published alongside it, and you're shipping it to every visitor's browser.

The three, and what's wrong with each old version

These break in different ways, which is worth understanding because two of them are XSS and one is worse.

$ view-source: bootstrap.min.js
detected bootstrap 4.1.3 (shipped 2018)
4.1.3on your page
4.3.1XSS in data-template / tooltip sanitizer fixed
CVE-2019-8331. public exploit, no patch on this version
Bootstrap below 4.3.1 has an XSS in its tooltip and popover data attributes. The fix is public, so is the exploit.

Bootstrap below 4.3.1 carries an XSS (CVE-2019-8331) in the way its tooltips and popovers handle data attributes: content that should be inert can be crafted to execute. Handlebars below 4.7.7 is the nastiest of the three, because it's prototype pollution that can escalate to remote code execution on the server when Handlebars runs server-side, not just a client-side script injection. DOMPurify is the most ironic: it's the library you add specifically to sanitize HTML and prevent XSS, and versions below 3.x have known sanitizer bypasses, meaning the tool you trusted to scrub dangerous markup can be tricked into letting it through. An outdated sanitizer is worse than no sanitizer, because you wrote the rest of your code assuming it works.

Why old versions hang around

Nobody keeps an old library on purpose. It persists because of how front-end dependencies actually get added and never revisited.

You copied a Bootstrap CDN link from a tutorial in 2019 and it's still pinned to that exact version. You added Handlebars for one feature and it became load-bearing, so nobody dares bump it. DOMPurify came in transitively, pulled by something else, and you don't even know it's there. The version on the page is frozen at whatever it was when you added it, while the CVEs against that version keep getting published. The library doesn't update itself, and "it still works" is not the same as "it's still safe." This is the same dynamic as an outdated jQuery build and an end-of-life library that gets no patches at all: the code runs fine and the hole runs with it.

How to read what you're shipping, and fix it

The version is usually right there in the URL or the file. A CDN link often has the version in the path (/[email protected]/). A bundled copy has it in the banner comment at the top of the minified file, or you can read it from your package-lock.json. Once you know the version, the fix is a bump.

<!-- versions with public CVEs -->
<link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css">
<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/handlebars.min.js"></script>
<!-- dompurify 2.x pulled in transitively -->
The version is in the URL or the lockfile. The fix is a bump past the safe line, then redeploy.

Bump Bootstrap to at least 4.3.1 (or move to 5.x), Handlebars to 4.7.7 or later, and DOMPurify to 3.x or above. For libraries pulled in transitively, update the parent or pin a safe version in your lockfile. If you're loading any of these from a CDN, add Subresource Integrity to the tag while you're in there, so the version you pin is the version that runs.

The version of each of these on your page is in the script URL or the banner comment in the file you serve, which means it's readable from outside without any access to your build. SurfaceCheckr fetches your pages and linked scripts, identifies these libraries by their URL or in-file banner, parses the version, and flags any sitting below the safe line with the matching CVE. We read the version you're serving; we don't exploit it, send a payload, or confirm the hole is reachable in your specific usage, because that's active testing and we stay passive. What we hand you is the list of libraries on your page that have a published vulnerability at the version you're shipping, which for most sites is a list they last looked at the day they added them.

Find it before someone else does.

Paste your domain. The grade and issue count are free, and you'll see in a couple of minutes exactly what's reachable from outside.