CVE-2026-11881

This vulnerability in Fluent Forms allows a Contributor-level user to inject malicious JavaScript through form configuration that executes in every visitor's browser — including administrators previewing the form. The issue isn't a missing htmlspecialchars() call. The plugin renders form configuration into an inline script tag without context-aware JavaScript escaping. When a Contributor configures form field labels or values, that data flows directly into a JavaScript string context. Standard HTML encoding won't stop it; you need JS-context escaping (wp_json_encode or equivalent). What makes this critical despite the low privilege required: the blast radius is catastrophically asymmetric. A Contributor can only modify their own form configuration — a narrow, locally contained action. But the rendered output executes in every browser that loads the form. One user's configuration choice becomes universal script execution. The structural problem: WordPress explicitly removes unfiltered_html from Contributors in multisite because they can't be trusted with arbitrary markup. Fluent Forms then gives them form management capability, re-introducing a content authoring surface the platform specifically prevented. The plugin must implement its own trust delegation at the render layer — and that's where this fails. Check your Fluent Forms version. If you're on 6.2.5 or earlier and allow Contributors to manage forms, treat any form configuration as potentially compromised. The fix adds proper JS-context escaping, but the deeper lesson is that any plugin enabling low-privileged users to manage rendered content is operating in a trust domain WordPress's native capability system wasn't designed to protect. Audit similar patterns in other plugins.

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