Bootstrap 4.3.1 and 4.4.1 Vulnerabilities: Audit and Upgrade Guide

When a scanner reports bootstrap 4.3.1 vulnerabilities, the finding is usually less about a specific exploitable bug in Bootstrap itself and more about three converging facts: Bootstrap 4 is past end of life, its bundled-era companion jQuery 3.4.1 carries actively exploited XSS flaws, and one disputed carousel advisory still trips automated tools. That distinction matters, because the correct remediation is different for each. This guide separates the real risk from the scanner noise for teams stuck on Bootstrap v4.3.1 or 4.4.1, and lays out the upgrade path that actually closes the findings.

First, what 4.3.1 fixed rather than introduced

Some context that confuses triage: 4.3.1 was itself a security release. Shipped in February 2019 together with Bootstrap 3.4.1, it patched CVE-2019-8331, an XSS vulnerability in the tooltip and popover plugins' data-template attribute, which lacked sanitization of HTML passed into it. Anything on 4.0.0 through 4.3.0 (or 3.x before 3.4.1) is exposed to that CVE; 4.3.1 and 4.4.1 are not.

So if your audit spreadsheet lists CVE-2019-8331 against Bootstrap v4.3.1, that specific row is a false positive, likely a scanner matching on the major version rather than the patched release. Verify the exact version string in the bundle you ship, not the one in a stale package.json comment; minified vendor copies drift from manifests more often than anyone admits.

The advisory that was withdrawn: the carousel XSS

In July 2024, CVE-2024-6531 was published against Bootstrap 4.0.0 through 4.6.2: an XSS reported in the carousel component, where an anchor's href feeding the data-slide/data-slide-to navigation was said to be inadequately sanitized when extracting the target carousel's ID.

The GitHub advisory (GHSA-vc8w-jr9v-vj7f) was subsequently withdrawn. The Bootstrap team's position: Bootstrap's JavaScript is not a sanitizer, and feeding intentionally dangerous HTML into component attributes falls outside its security model. In other words, if an attacker can already inject arbitrary attributes into your anchors, you have an HTML injection bug in your application, and no UI framework can save you.

Practical consequences for your audit:

• Some vulnerability databases still carry the entry, so SCA tools disagree about whether Bootstrap 4.x is "clean". Expect inconsistent results across scanners and document the withdrawal in your triage notes.
• The underlying reminder stands: never interpolate untrusted input into data-* attributes or href values without output encoding. That is your code's job, framework aside.

The finding that is real: jQuery 3.4.1

Here is where teams on Bootstrap 4.3.1 or 4.4.1 usually have an actual problem. Bootstrap 4's interactive components require jQuery, and projects of that era overwhelmingly pinned jQuery 3.4.1, the current release at the time. jQuery 3.4.1 is affected by two well-documented XSS vulnerabilities, both fixed in jQuery 3.5.0 (April 2020):

• CVE-2020-11022: passing HTML from untrusted sources to jQuery's DOM manipulation methods (.html(), .append(), and friends) could execute untrusted code, even after sanitization, due to the htmlPrefilter behavior.
• CVE-2020-11023: the same class of issue with HTML containing option elements.

CVE-2020-11023 stopped being theoretical a long time ago: CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, with a February 2025 remediation deadline for federal agencies, after exploitation was observed in the wild. A five-year-old medium-severity XSS earning a KEV entry is the clearest possible signal that "it's just a frontend library" is not a triage category.

If you ship Bootstrap 4 with jQuery below 3.5.0, this is the finding to fix first, and the fix is cheap: jQuery 3.5+ is API-compatible for virtually all Bootstrap usage.

npm install jquery@^3.7.1
npm ls jquery   # confirm nothing else pins the old one

Then grep your templates for the CDN copy everyone forgets:

grep -rn "jquery-3.4.1" --include="*.html" .

The structural problem: Bootstrap 4 is end of life

Bootstrap 4 reached end of life on January 1, 2023. The final release of the line is 4.6.2 (July 2022). No further patches will ship for v4, regardless of what gets discovered, and the disputed carousel report of 2024 previews how that plays out: for genuine future issues, the official remediation will always be "upgrade to v5", because there is nothing else to point at. Bootstrap 3.4 sits even further past that line; 3.4.1 was its terminal patch back in 2019.

EOL software is a compliance finding independent of any CVE. SOC 2 and PCI assessments increasingly treat unsupported components as an automatic exception, and an SCA platform such as Safeguard flags EOL packages precisely because the CVE feed for them goes silent, not safe, after the cutoff.

A pragmatic upgrade path

You have three moves, in ascending order of effort:

1. Within v4: move to 4.6.2 and jQuery 3.7.x. Zero-drama drop-in from 4.3.1 or 4.4.1; the 4.x line kept compatibility. This clears the jQuery CVEs and gets you the last v4 patches, but does not clear the EOL finding. Treat it as a step, not a destination.
2. Upgrade to Bootstrap 5. The real fix. v5 drops the jQuery dependency entirely, which removes the largest attack surface in this whole story. Costs: data-* attributes are renamed (data-toggle becomes data-bs-toggle), the grid gains a new xxl tier and gutter behavior changes, form markup is reworked, and Internet Explorer support is gone, if IE is why you froze on v4, that constraint needs an owner and a date.
3. Paid extended support. Vendors sell post-EOL patches for Bootstrap 4 for organizations that genuinely cannot migrate. Legitimate as a bridge; expensive as a lifestyle.

For most codebases, the honest cost of step 2 is CSS review time, not JavaScript rewrites. Budget it component by component, run visual regression on the templates, and delete the jQuery bundle at the end as the prize.

Verifying you are actually clean

After the upgrade, prove it rather than assert it:

• Rescan the built artifact, not the repo, so CDN links and vendored minified files are covered.
• Check the rendered pages for legacy copies with your browser devtools (window.jQuery && jQuery.fn.jquery in the console still tells the truth).
• Add a CI gate so a future contractor cannot reintroduce bootstrap@4 silently; dependency policies and a dynamic scan of the running app catch the copies static manifests miss.

FAQ

Is Bootstrap 4.3.1 vulnerable?

Bootstrap 4.3.1 itself patched the last confirmed Bootstrap 4 XSS (CVE-2019-8331). The 2024 carousel advisory (CVE-2024-6531) against all of 4.x was withdrawn as out of scope. The practical risks of running 4.3.1 today are its EOL status and the vulnerable jQuery 3.4.1 it almost always ships beside.

What about Bootstrap 4.4.1, is it any safer than 4.3.1?

Security-wise they are equivalent: both post-date CVE-2019-8331, both fall in the withdrawn carousel advisory's range, and both are past Bootstrap 4's January 1, 2023 end of life. Neither will receive patches.

Why does my scanner flag jQuery 3.4.1 alongside Bootstrap?

Bootstrap 4's components require jQuery, and jQuery 3.4.1 carries CVE-2020-11022 and CVE-2020-11023, XSS flaws fixed in 3.5.0. CVE-2020-11023 entered CISA's Known Exploited Vulnerabilities catalog in January 2025, so treat it as a priority fix, not backlog noise.

Do I have to go to Bootstrap 5, or is 4.6.2 enough?

Moving to 4.6.2 plus jQuery 3.7 clears the known CVEs cheaply, but Bootstrap 4 remains end of life, so the compliance finding stays open and future issues will never be patched. Bootstrap 5 (which needs no jQuery) is the destination; 4.6.2 is a reasonable waypoint.