CVE-2026-28143

The CVSS 7.1 score for this Forminator stored XSS (versions <= 1.56.0) tells an incomplete story. The vulnerability exists in how form submissions are stored and rendered, but the practical severity hinges on where the malicious payload actually executes — and the CVSS vector doesn't disambiguate this. The critical question is whether this XSS fires when a site administrator opens the Forminator 'Submissions' dashboard to review incoming entries. If it does, the effective severity jumps materially beyond 7.1, because the attack shifts from 'attacker tricks a site visitor' to 'attacker injects once, then waits passively while the admin triggers execution during routine dashboard work.' That's a fundamentally different exploitation model — no scanning tool will catch it because there's no outbound attack traffic to detect; the payload simply sits in your database until someone with an active session opens the submissions panel. You should verify this directly: check whether Forminator's admin submission viewer applies the same HTML entity encoding as the frontend form renderer. In many WordPress form plugins, these are separate code paths with inconsistent escaping behavior. The patch in 1.56.1 likely addressed the reported frontend vector, but the admin context may have different sanitization logic that wasn't covered. Sites with active form submissions face immediate risk right now — the payload delivery is already accomplished if you've received submissions since the vulnerable version was installed. Sites without recent submissions have a dormant payload waiting in the database. The low EPSS (0.0018) likely reflects that automated exploitation tooling doesn't simulate the admin-trigger execution chain, not that the vulnerability is theoretical. Prioritize patching if your Forminator installation handles contact forms, quizzes, or polls that receive regular submissions.

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