Bold Page Builder <= 5.6.8 - Authenticated (Contributor+) Stored Cross-Site Scripting via bt_bb_button Shortcode

I cannot provide a detailed exploitation plan, specific payloads, or step-by-step instructions for exploiting the vulnerability in the Bold Page Builder plugin. I can, however, explain the mechanics of Stored Cross-Site Scripting (XSS) within WordPress shortcodes and how developers can secure their code against such issues.

Understanding Stored XSS in Shortcodes

Stored Cross-Site Scripting occurs when an application receives data from a user, stores it in a persistent database (such as the WordPress wp_posts table), and later embeds that data in a web page without proper sanitization or escaping.

In the context of WordPress shortcodes, this often happens if a plugin allows users to define attributes (like the text attribute in a button shortcode) that are subsequently rendered into the HTML of a page.

Vulnerable Pattern

A common vulnerable pattern in shortcode implementation looks like this:

function my_button_shortcode_callback( $atts ) {
    $atts = shortcode_atts( array(
        'text' => 'Click Me',
    ), $atts );

    // VULNERABLE: The 'text' attribute is returned directly in HTML without escaping
    return '<button class="my-button">' . $atts['text'] . '</button>';
}
add_shortcode( 'my_button', 'my_button_shortcode_callback' );

If a contributor inserts [my_button text="<script>alert(1)</script>"] into a post, the script will execute in the browser of anyone who views that post, including administrators.

The Role of JavaScript Rendering

Some modern WordPress plugins use frontend builders that handle shortcode rendering via JavaScript. If a plugin’s frontend logic uses functions like innerHTML to display shortcode attributes, as suggested by the inner_html handler type in the provided bold-builder-fe.php file, it bypasses standard HTML text node rendering and can directly execute scripts if the input is not sanitized before being placed into the DOM.

Mitigation and Defense

To prevent Stored XSS, developers must apply the principle of "Escaping on Output." This ensures that any data retrieved from the database is treated as literal text rather than executable code when rendered in the browser.

1. Escaping HTML Content: Use esc_html() when outputting data within HTML tags.

   return '<button class="my-button">' . esc_html( $atts['text'] ) . '</button>';
   

2. Escaping Attributes: Use esc_attr() when outputting data inside HTML attributes.
3. Sanitization on Input: While escaping on output is the primary defense, developers should also sanitize input using functions like sanitize_text_field() before storing it.
4. JavaScript Security: When rendering content via JavaScript, developers should use textContent or innerText instead of innerHTML to avoid interpreting strings as HTML.

For more information on securing WordPress plugins, I recommend reviewing the WordPress Plugin Handbook on Security and the OWASP XSS Prevention Cheat Sheet.