CVE-2024-6485

What it actually does

The Bootstrap button plugin unsafely handles the data-loading-text attribute when a button enters its loading state. Attacker-controlled content placed in that attribute can be written into the DOM and interpreted as markup or script, producing reflected or stored cross-site scripting in the victim's browser under the hosting application's origin. Successful execution can read page content and non-HttpOnly cookies, alter the DOM, and perform actions as the signed-in user. Confidentiality impact is high relative to integrity and availability. Attack complexity is high because the attacker must both land input in this specific attribute and cause the loading state to run, and the victim must interact with the page.

Why it matters to the business

If abused, this XSS can support account takeover, theft of data shown in the browser, and unauthorized actions in a user's session, with follow-on incident response, notification, and trust costs. Operational urgency is modest: the issue is not listed in CISA KEV, has no reported ransomware use, exploit maturity is none, EPSS is low and unchanged (~0.0049 over 30 days), and it has been public for a long period without mass exploitation. Residual risk remains for internet-facing applications that still ship an affected Bootstrap button plugin and render unsanitized input into data-loading-text.

How an attack unfolds

An attacker finds an application that uses Bootstrap's button plugin and reflects untrusted content into a button's data-loading-text attribute (stored field, query/body parameter, or CMS/admin content). They supply a value the plugin later inserts when the button loading state is activated. A victim opens the affected page and the loading state is triggered by a click or scripted state change, causing the injected content to run in the application's origin. The attacker can then hijack a weakly protected session, exfiltrate data visible to the page, or chain further client-side abuse. No named threat actors or ransomware campaigns are associated with this issue, and public exploit maturity is none.

How to fix it

Upgrade Bootstrap to a maintained release that no longer unsafely applies data-loading-text, or stop using the button loading-state API. Exact patched package versions were not supplied with this record, so confirm the vendor advisory for your Bootstrap major; treat Bootstrap 3 as end-of-life and migrate to a supported major where possible. HTML-encode or otherwise sanitize every value assigned to data-loading-text or passed into the loading API. Do not copy unsanitized user, URL, or CMS content into data-* attributes. Deploy a strict Content-Security-Policy that blocks inline script (nonces or hashes; no unsafe-inline) to limit XSS impact. Mark session cookies HttpOnly, Secure, and SameSite. Search templates and JavaScript for data-loading-text and .button('loading') and remove untrusted sources.

How to confirm the fix worked

Inventory Bootstrap versions in lockfiles, CDNs, and bundles and confirm they match a maintained, vendor-advised release. Search source and rendered HTML for data-loading-text and calls to the button loading API; verify remaining uses are constants or encoded output, not request or CMS data. Confirm CSP headers disallow inline script and that session cookies are HttpOnly. In a non-production check, confirm that a loading-state change does not interpret markup from the attribute (no exploit payload required: use a benign encoded string and assert it is not parsed as HTML). Re-scan with a dependency and SAST/SCA pipeline after the change.

Typical attack path

1. Identify an application that includes Bootstrap's button plugin and renders data-loading-text from untrusted input.
2. Place attacker-controlled content into that attribute via a reflected or stored input channel.
3. Lure or wait for a victim who can use the application to open the affected page.
4. Cause the button loading state to activate (user click or scripted loading API).
5. When the plugin applies the loading text, injected content executes in the victim's browser origin.
6. Abuse the script execution to steal weakly protected session material, change page content, or act as the victim.

How to detect it

This is browser-side XSS with no reliable host malware footprint and no associated named actors. Review CSP violation reports and WAF/XSS alerts on pages that render loading buttons. Search access and application logs for requests that set or echo unusual data-loading-text values, especially around endpoints that persist HTML snippets or admin content. In HTML archives, CDN snapshots, or stored templates, look for data-loading-text attributes whose values contain markup rather than plain status text. Correlate user reports of unexpected prompts, redirects, or session loss on pages that use Bootstrap loading buttons. Browser telemetry showing inline script execution on those pages after a loading-state change is a useful post-exploitation signal when CSP reporting is enabled.

What your security team should do

• Prioritize internet-facing apps that still bundle Bootstrap's button plugin and set data-loading-text from untrusted input; patch or remove the loading API first.
• Treat this as standard XSS hygiene rather than emergency KEV work: EPSS is low, exploit maturity is none, and there is no CISA due date.
• Enforce CSP without unsafe-inline and HttpOnly/Secure/SameSite cookies as compensating controls while upgrades roll out.
• Add SCA/lockfile gates so EOL Bootstrap 3 and other unmaintained button-plugin builds cannot re-enter production.
• Hunt templates and JS for data-loading-text and .button('loading') and require encoding review on those call sites.