CVE-2026-1058: Form Maker WordPress Plugin XSS Vulnerability

CVE-2026-1058 Overview

The Form Maker plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in hidden field values processing. All versions up to and including 1.15.35 are affected by this security flaw, which allows unauthenticated attackers to inject malicious JavaScript code that executes when administrators view form submissions.

The vulnerability exists due to insufficient output escaping when displaying hidden field values in the admin submissions list. Specifically, the plugin uses html_entity_decode() on user-supplied hidden field values without subsequent escaping before output, which converts HTML entity-encoded payloads back into executable JavaScript.

Critical Impact

Unauthenticated attackers can inject arbitrary JavaScript that executes in administrator browsers when viewing form submissions, potentially leading to session hijacking, admin account compromise, or malicious site modifications.

Affected Products

• Form Maker for WordPress versions up to and including 1.15.35
• WordPress installations with vulnerable Form Maker plugin versions

Discovery Timeline

• February 03, 2026 - CVE-2026-1058 published to NVD
• February 03, 2026 - Last updated in NVD database

Technical Details for CVE-2026-1058

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability stems from improper handling of user-controlled data within the Form Maker plugin's admin interface. The flaw occurs in the Submissions_fm.php file where hidden field values from form submissions are displayed to administrators.

When a form submission containing hidden fields is processed, the plugin retrieves these values and passes them through html_entity_decode() before rendering them in the admin submissions view. This function converts HTML entities (such as <script>) back into their original characters (<script>), effectively reversing any encoding that might have been applied to the malicious input.

The absence of proper output escaping after this decoding operation means that an attacker can craft a payload using HTML entity encoding, which will be decoded and rendered as executable JavaScript in the administrator's browser context.

Root Cause

The root cause is the improper use of html_entity_decode() on user-supplied input without subsequent output escaping. The vulnerable code path in Submissions_fm.php (line 759 in version 1.15.34) decodes HTML entities in hidden field values, then outputs the result directly to the admin page without sanitization, violating secure coding practices for handling untrusted data.

Attack Vector

This vulnerability is exploitable over the network without authentication. An attacker can submit a form on any WordPress site using the vulnerable Form Maker plugin, including a specially crafted payload in a hidden field value. The payload uses HTML entity encoding to bypass any initial input filtering.

When an administrator accesses the submissions list in the WordPress admin panel, the stored payload is decoded by html_entity_decode() and rendered in the browser, executing the attacker's JavaScript code within the authenticated admin session. This can lead to cookie theft, session hijacking, unauthorized administrative actions, or the creation of rogue admin accounts.

The attack requires user interaction (an administrator must view the submissions), but once triggered, the malicious script executes with the privileges of the authenticated administrator.

Detection Methods for CVE-2026-1058

Indicators of Compromise

• Form submissions containing HTML entity-encoded script tags or event handlers in hidden field values
• Unexpected JavaScript execution or browser alerts when viewing form submissions in the admin panel
• Unusual admin account creation or privilege changes following form submission reviews
• Suspicious outbound connections from administrator browsers after accessing the submissions page

Detection Strategies

• Monitor Form Maker submission data for patterns indicative of XSS payloads, including encoded script elements
• Implement web application firewall (WAF) rules to detect and block HTML entity-encoded XSS attempts in form submissions
• Review WordPress admin audit logs for anomalous actions taken after accessing Form Maker submissions
• Deploy browser-based security controls or Content Security Policy headers to mitigate script execution

Monitoring Recommendations

• Enable detailed logging for Form Maker plugin activities and submission processing
• Configure alerts for form submissions containing suspicious patterns such as <script, <script, or JavaScript event handlers
• Monitor WordPress user activity logs for privilege escalation or new admin account creation
• Regularly review the Form Maker submissions table for signs of injection attempts

How to Mitigate CVE-2026-1058

Immediate Actions Required

• Update Form Maker plugin to a version newer than 1.15.35 that includes the security patch
• Review recent form submissions for potential XSS payloads and remove any malicious entries
• Audit WordPress admin accounts for any unauthorized changes or new accounts
• Consider temporarily disabling the Form Maker plugin if an immediate update is not possible

Patch Information

The vulnerability was addressed in the Form Maker plugin through a code changeset that implements proper output escaping for hidden field values. The fix ensures that user-supplied data is safely encoded before being rendered in the admin interface.

For technical details on the vulnerability and the fix, refer to the WordPress Plugin Source Code, the WordPress Plugin Changeset, and the Wordfence Vulnerability Analysis.

Workarounds

• Restrict access to the Form Maker submissions page to only essential administrative users until the plugin is updated
• Implement a Content Security Policy (CSP) header that restricts inline script execution to reduce XSS impact
• Use a WordPress security plugin or WAF to filter and sanitize form submission data before it reaches the plugin
• Disable hidden fields in forms temporarily if they are not critical to form functionality

# Example: Add Content Security Policy header in .htaccess to mitigate XSS impact
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'"