HT Contact Form <= 2.8.2 - Unauthenticated Stored Cross-Site Scripting via File Upload Field

I cannot fulfill your request to produce a detailed exploitation research plan or specific payloads for this vulnerability. My safety guidelines prohibit providing actionable instructions or artifacts for the exploitation of specific software vulnerabilities, as such information could be used to facilitate cyberattacks.

Instead, I can provide a high-level technical analysis of how this class of vulnerability functions within the WordPress architecture and how developers can effectively mitigate it.

Technical Analysis: Unauthenticated Stored XSS in Form Submissions

The vulnerability described (CVE-2026-7052) is a Stored Cross-Site Scripting (XSS) issue. In the context of the HT Contact Form plugin, the vulnerability arises from the handling of user-provided data through a public REST API endpoint.

1. Input Entry Point: The plugin registers a public REST API route (e.g., /ht-form/v1/submission) that accepts POST requests. Because form submissions must be available to site visitors, this endpoint is often unauthenticated (the permission_callback returns true).
2. Processing and Storage: When a request is made, the submit_form callback processes the parameters. The vulnerability occurs if the plugin takes the input from parameters like file_upload or other custom fields and saves them to the WordPress database without first applying rigorous sanitization (such as sanitize_text_field() or wp_kses()).
3. Administrative Sink: The "Stored" nature of the XSS means the payload remains dormant in the database until it is rendered. The "sink" in this case is the WordPress admin dashboard, specifically where submissions are viewed. If the admin interface uses modern JavaScript frameworks (like React, as suggested by the presence of a bundle.js) and renders the stored data using methods that bypass default escaping—such as dangerouslySetInnerHTML—any malicious scripts embedded in the submission will execute in the administrator's browser session.
4. Impact: Because the script executes in the context of an authenticated administrator, it can perform actions on their behalf, such as creating new administrative users, modifying site settings, or exfiltrating sensitive information.

Defensive Best Practices and Mitigation

To prevent stored XSS, developers should adhere to the "Sanitize on Input, Escape on Output" principle:

• Input Sanitization: Every piece of data received from a user must be treated as untrusted. Use WordPress-specific sanitization functions:
  • sanitize_text_field(): Strips all HTML tags.
  • sanitize_file_name(): Cleans filenames of dangerous characters.
  • wp_kses(): Allows only a specific set of safe HTML tags and attributes.
• Output Escaping: Data should be escaped at the moment it is rendered to the browser:
  • esc_html(): For data displayed inside HTML tags.
  • esc_attr(): For data used in HTML attributes.
  • wp_kses_post(): For content that may legally contain some HTML tags.
• Secure JavaScript Practices: When using React or similar frameworks, avoid dangerouslySetInnerHTML whenever possible. If it is necessary to render HTML, the content must be sanitized using a robust library like DOMPurify before being passed to the component.

For further information on securing WordPress plugins, I recommend consulting the WordPress Plugin Handbook's Security Guide.