CVE-2024-6485: Cross-Site Scripting (XSS) in Bootstrap 3 Button Plugin

The vulnerability affects the End-of-Life (EOL) Bootstrap 3.x branch, specifically within the Button plugin (js/button.js). This component provides a mechanism to visually indicate state changes during asynchronous operations, utilizing HTML data attributes like data-loading-text to swap button content temporarily.

The core issue is classified as CWE-79: Improper Neutralization of Input During Web Page Generation. The plugin retrieves the value of the data-loading-text attribute and reflects it directly into the Document Object Model (DOM) without prior sanitization or context-aware encoding.

Exploitation requires specific preconditions within the host application. An attacker must find an injection vector where user-controlled input is dynamically rendered into the data-loading-text attribute by the server-side template or client-side framework. If this condition is met, the XSS payload is staged and awaits the trigger event.

The flaw resides within the Button.prototype.setState function of the Bootstrap 3 JavaScript library. This method is responsible for managing the visual transitions of button elements, intercepting API calls like .button('loading') to modify the element's inner content.

Within this function, a ternary operator evaluates the node type of the target element. If the element is an <input> tag, the script assigns the variable val to the string 'val'. For all other elements, including standard <button> tags, it assigns val to 'html'.

This logic dictates the jQuery method used to inject the new text. When processing a <button>, the plugin blindly passes the contents retrieved from the data-loading-text attribute directly into jQuery's .html() function.

The .html() method parses the provided string as raw HTML before appending it to the DOM. This automatic parsing mechanism executes any embedded JavaScript contained within specific HTML tags, such as <img> tags utilizing the onerror event handler, establishing the cross-site scripting primitive.

The vulnerable implementation in Bootstrap v3.4.1 demonstrates the unsafe DOM manipulation. The vulnerability is introduced by the dynamic method selection based on the element type.

  Button.prototype.setState = function (state) {
    var d    = 'disabled'
    var $el  = this.$element
    var val  = $el.is('input') ? 'val' : 'html' // Vulnerable assignment
    var data = $el.data()
 
    state += 'Text'
 
    if (data.resetText == null) $el.data('resetText', $el[val]())
 
    // push to event loop to allow forms to submit
    setTimeout($.proxy(function () {
      // Execution point: resolves to $el.html(data['loadingText'])
      $el[val](data[state] == null ? this.options[state] : data[state]) 
 
      if (state == 'loadingText') {
        this.isLoading = true
        $el.addClass(d).attr(d, d).prop(d, true)
      }
    }, this), 0)
  }

The asynchronous nature of the setTimeout block ensures that the DOM updates do not block the main thread during form submissions. However, it guarantees the execution of the injected payload exactly when the application invokes the loading state.

To manually remediate this logic in legacy systems, the assignment variable val must be altered to use jQuery's .text() method instead of .html(). This change ensures that the browser interprets the attribute contents strictly as a text node, completely neutralizing any executable HTML tags.

  // Patched Assignment
  var val  = $el.is('input') ? 'val' : 'text'

Implementing this single-line patch effectively closes the vulnerability at this specific sink. All special characters within the payload, including angle brackets and quotes, will be safely HTML-entity encoded by the browser prior to rendering.

The attack sequence mandates that an attacker successfully injects a malicious payload into the targeted HTML attribute. The host application must utilize a templating engine that reflects unsanitized user input into the data-loading-text property of a Bootstrap button.

The following HTML and JavaScript snippet demonstrates the proof-of-concept necessary to trigger the vulnerability. Modern browsers typically restrict direct execution of <script> tags inserted via .html(), necessitating the use of image-based payloads utilizing the onerror event handler.

<!-- Staged Payload in DOM -->
<button id="vulnerableButton" 
        class="btn btn-primary" 
        data-loading-text="<img src=x onerror=alert('CVE-2024-6485')>">
    Submit Data
</button>
 
<script>
  // Application logic triggering the payload
  $('#vulnerableButton').on('click', function () {
    $(this).button('loading'); 
  });
</script>

The injected code remains dormant in the DOM upon initial page load. Exploitation strictly requires the application to programmatically update the button state. This typically occurs automatically as a side effect of user interaction, such as clicking the button to submit a form or initiate an AJAX request.

Successful exploitation grants the attacker arbitrary JavaScript execution within the security context of the victim's session. The injected script operates with the same permissions as the legitimate application, bypassing Same-Origin Policy (SOP) restrictions.

This execution capability enables severe downstream consequences. Attackers can exfiltrate sensitive session tokens, access local storage data, intercept subsequent user input, or perform authenticated actions on behalf of the compromised user via Cross-Site Request Forgery (CSRF) tokens captured from the DOM.

The CVSS v3.1 base score is calculated at 6.4 (Medium). This severity rating is constrained primarily by the High Attack Complexity (AC:H) requirement. The vulnerability is not a default configuration flaw; it demands a specific, vulnerable implementation pattern by the developers of the host application to become exploitable.

The Exploit Prediction Scoring System (EPSS) rating sits at 0.00135, placing it in the 33rd percentile. This low probability indicates that broad, automated exploitation is highly unlikely. Threat actors must manually map the application surface to identify viable injection points that map directly to this specific Bootstrap data attribute.

The primary and most secure remediation strategy is migrating the application to an actively supported version of the framework, such as Bootstrap 4.x or 5.x. The button state functionality was formally deprecated in Bootstrap v3.3.5 and completely eliminated in v4, structurally removing the vulnerable code path.

For organizations operating legacy systems where upgrading the major framework version is architecturally prohibitive, commercial support options are available. The HeroDevs Never-Ending Support (NES) program provides backported security patches for EOL Bootstrap 3.x deployments, mitigating this issue without requiring systemic application rewrites.

Alternatively, engineering teams can apply a manual hotfix directly to the js/button.js file. By altering the ternary operator to utilize .text() instead of .html() for non-input elements, the application forces safe text rendering. If dynamic HTML within button states is an absolute requirement, all user-supplied data must be routed through a robust HTML sanitizer, such as DOMPurify, prior to DOM insertion.