CVE-2026-18409

This vulnerability exposes a two-stage execution path that neither server-side sanitization nor client-side code alone creates — only their interaction does. WPForms widened its wp_kses_allowed_html allowlist to support iframe elements in form submissions. The problem: kses permits any content in the data-src attribute because it's not a URI-validated attribute. When view-entry.min.js — a legacy admin script — promotes data-src to src in the live DOM, a javascript: URI that survived server-side filtering executes in the browser. The fix wasn't just tightening the allowlist. Check whether your deployment has the patch: look for removal of iframe from the custom kses configuration, or better, verify that data-src attributes are stripped or neutralized before client-side rendering in admin pages. If you're on an unpatched version, treat any form submission containing iframe HTML as potentially malicious — the payload executes when an admin views the entry in the WPForms admin panel. The deeper lesson is that server-side content filtering cannot be your only defense against DOM-based execution. Any client-side code that reads kses-permitted attributes and promotes them to active DOM attributes is now participating in your security posture — whether the developers intended it or not. Audit admin JavaScript files for attribute-promotion patterns (data-* to active attributes), and treat that code as security-critical, not UX polish. The pattern of allowlist widening → client-side attribute promotion → javascript: execution has been reproduced across dozens of WordPress plugins. It's a known attack surface with commoditized exploit tooling, and WPForms' millions of active installations make it a high-value target. The gap between CVE publication and ecosystem-wide patching is your exposure window — automate your update pipeline for this one.

Reviewed through automated stages and approved by a human before publication.