Happy Addons for Elementor <= 3.20.3 - Authenticated (Contributor+) Stored Cross-Site Scripting via Custom JS

I cannot provide a detailed exploitation plan or generate specific payloads for CVE-2025-14635. I can, however, explain the general mechanisms of stored Cross-Site Scripting (XSS) in the context of WordPress page builders or discuss secure coding practices to prevent these types of vulnerabilities.

Understanding Stored XSS in Page Builder Plugins

Stored Cross-Site Scripting (XSS) in WordPress plugins often occurs when user-provided data is saved to the database (e.g., in post meta or plugin settings) without adequate sanitization and is later rendered on a page without proper escaping.

In the context of Elementor addons or similar page builders, "Custom JS" features are particularly sensitive. These features are intended to allow site administrators to add scripts to specific pages. If the plugin fails to restrict this capability to users with the unfiltered_html capability (typically only Administrators and Editors on single-site installations), lower-privileged users like Contributors or Authors might be able to inject arbitrary JavaScript.

General Code Flow and Vulnerability Patterns

A typical vulnerability pattern for this type of issue involves:

1. Input Handling: A plugin registers an AJAX action or a REST API endpoint that allows users to update page-specific metadata.
2. Insufficient Authorization: The code checks for basic authentication or a general capability (like edit_posts), but fails to verify if the user should be allowed to submit raw HTML or JavaScript.
3. Missing Sanitization: The input is stored directly in the database using functions like update_post_meta() without using wp_kses() or similar sanitization wrappers.
4. Unsafe Output: When the page is rendered on the frontend, the stored data is echoed directly into the HTML or into a <script> block without using esc_js() or wp_kses_post().

Prevention and Mitigation

To prevent stored XSS, developers should adhere to the following security practices:

• Capability Checks: Always verify that the current user has the appropriate permissions for the specific action. For features involving raw code injection, check for the unfiltered_html capability.
• Sanitize on Input: Use WordPress sanitization functions like sanitize_text_field(), esc_url_raw(), or wp_kses() depending on the expected data type.
• Escape on Output: Always escape data at the point of rendering. Use esc_html(), esc_attr(), esc_js(), or wp_kses() to ensure that data is safe for the specific output context.
• Use Nonces: Implement WordPress nonces to protect against Cross-Site Request Forgery (CSRF) and ensure that requests originate from a legitimate source.

For more information on WordPress security, you can refer to the WordPress Plugin Handbook's security section.