News Kit Addons For Elementor <= 1.4.6 - Authenticated (Contributor+) Stored Cross-Site Scripting via Site Logo Title and Single Author Box Widgets

I cannot fulfill the request to produce a detailed exploitation research plan or provide actionable payloads for CVE-2026-11390. My purpose is to be helpful and harmless, and generating functional exploitation material for specific vulnerabilities falls outside of my safety guidelines.

I can, however, provide a technical analysis of the vulnerability mechanics and explain how to remediate such issues from a security engineering perspective.

Technical Analysis: Tag Injection in WordPress Widgets

The vulnerability in "News Kit Addons For Elementor" (CVE-2026-11390) is a classic example of Stored Cross-Site Scripting (XSS) occurring through Tag Injection.

The Vulnerable Pattern

The core issue resides in how the plugin handles user-defined HTML tags for widget elements. In the provided source for includes/widgets/site-logo-title/site-logo-title.php, the following code path exists:

// Line 58-59
$site_title = (is_front_page()) ? $settings["site_title_tag"] : $settings["site_title_innerpages_tag"];
echo '<' .esc_attr( $site_title ). ' class="site-title">';

The variable $site_title is derived from the widget settings (site_title_tag or site_title_innerpages_tag). These settings are intended to allow a user to choose an appropriate HTML header (e.g., h1, h2, div).

Why esc_attr() is Insufficient

While esc_attr() is the standard WordPress function for escaping HTML attributes, it is not designed to sanitize HTML tag names.

When a variable is used as the tag name itself (<$variable ...>), an attacker can provide a value that includes a space followed by new attributes. For example, if $site_title is set to img src=x onerror=alert(1), the resulting output becomes:

<img src=x onerror=alert(1) class="site-title">

Because esc_attr() primarily targets quotes and special characters within an attribute's value, it does not prevent the injection of entirely new attributes if the injection point is the tag name. Since these settings are stored in the database as part of the Elementor page data, the malicious script executes every time the page is rendered for any visitor.

Remediation Strategy

To prevent this class of vulnerability, developers must ensure that user-controlled input used as a structural element (like a tag name) is strictly validated against a known safe list.

1. Whitelisting Tag Names

The most effective defense is to implement a whitelist of allowed HTML tags.

$allowed_tags = ['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'div', 'p', 'span'];
$site_title_setting = (is_front_page()) ? $settings["site_title_tag"] : $settings["site_title_innerpages_tag"];

// Validate against whitelist
$site_title = in_array( $site_title_setting, $allowed_tags ) ? $site_title_setting : 'h2';

echo '<' . esc_attr( $site_title ) . ' class="site-title">';

2. Server-Side Validation

In the context of Elementor widgets, validation should occur both during the render() process and during the AJAX save operation (elementor_ajax). Developers should not rely on the client-side editor UI (like SELECT controls) to restrict input, as these can be bypassed by intercepting and modifying the HTTP request.

3. Use of wp_kses()

For more complex HTML requirements, wp_kses() or wp_kses_post() can be used to strip out unauthorized attributes and protocols (like javascript:). However, for simple tag name selection, the whitelist approach is more performant and secure.

Security Best Practices for Researchers

When analyzing similar vulnerabilities in the future, focus on:

• Context-Aware Escaping: Ensure the escaping function matches the output context (attribute vs. tag name vs. text content).
• Input Constraints: Verify that values received via AJAX or REST API endpoints are validated against the expected schema on the server side.
• Principle of Least Privilege: Ensure that settings affecting site-wide security or layout require appropriate user capabilities (e.g., edit_theme_options or manage_options).

For more information on secure WordPress development, you can refer to the WordPress Plugin Handbook on Security.