Basticom Framework <= 1.5.2 - Authenticated (Administrator+) Stored Cross-Site Scripting

I cannot provide a functional exploitation plan or specific payloads for CVE-2025-67629. I can, however, analyze the mechanics of authenticated stored cross-site scripting (XSS) within WordPress framework plugins and the technical analysis process used to identify and mitigate such vulnerabilities.

Understanding Authenticated Stored XSS in Frameworks

In the context of a WordPress framework, stored XSS typically occurs when administrative settings or customization options are handled without adequate security controls. While administrators generally have high trust, WordPress implements the unfiltered_html capability to restrict even high-privileged users from injecting scripts in certain environments, such as Multisite installations.

1. Vulnerability Mechanics

The vulnerability arises from a failure in the "Input $\rightarrow$ Storage $\rightarrow$ Output" chain:

• Input: An administrator-level user provides data via an admin settings page.
• Storage: The plugin saves this data using functions like update_option() or update_site_option() without applying sanitization (e.g., sanitize_text_field() or wp_kses()).
• Output: The stored data is later retrieved using get_option() and rendered on a page (either in the admin dashboard or the frontend) without context-aware escaping (e.g., esc_html() or esc_attr()).

2. Technical Analysis and Code Flow

A security researcher analyzing a framework for this type of vulnerability would typically follow this trace:

1. Identify Entry Points: Search for admin menu registrations (add_menu_page) and their associated callback functions. These callbacks often contain the forms that accept user input.
2. Locate Save Logic: Trace the form submission. Frameworks often use the Settings API (register_setting) or custom AJAX handlers (wp_ajax_ hooks) to process updates.
3. Audit Sanitization: Check if the saving logic uses a sanitize_callback or manual sanitization. If update_option( 'framework_setting', $_POST['setting_value'] ) is called directly, the input is stored "raw."
4. Trace the Sink: Search the codebase for where get_option( 'framework_setting' ) is called. The "sink" is the point where this value is echoed. For example:

   // Vulnerable Sink
   echo '<div class="custom-banner">' . get_option('framework_setting') . '</div>';
   

3. The Role of unfiltered_html

In a standard WordPress installation, the Administrator role includes the unfiltered_html capability, allowing them to intentionally post scripts (e.g., for analytics or custom integrations). However, this capability is disabled for all users except the Super Admin in Multisite environments or when the DISALLOW_UNFILTERED_HTML constant is set to true. In these restricted contexts, an Admin's inability to bypass sanitization is a security boundary; if a plugin allows them to store and execute arbitrary scripts, it is considered a vulnerability.

Defensive Best Practices

To prevent stored XSS, developers must adhere to the principle of "Sanitize on Input, Escape on Output."

Safe Input Handling:

// Using the Settings API with a sanitization callback
register_setting( 'plugin_options', 'plugin_setting', [
    'sanitize_callback' => 'sanitize_text_field',
] );

Safe Output Handling:

// Escaping the data before rendering
$setting = get_option( 'plugin_setting' );
echo '<div class="notice">' . esc_html( $setting ) . '</div>';

For cases where some HTML is required, wp_kses() or wp_kses_post() should be used to define a strict allow-list of tags and attributes, ensuring that dangerous elements like <script> or event handlers (e.g., onerror) are stripped.