Kirki Page Builder CVE-2026-17037

No authentication is required - any network-accessible visitor can submit the malicious 'comment' parameter to the affected Kirki plugin endpoint. The prerequisite is that the Kirki - Freeform Page Builder plugin is installed and active on the WordPress site at version 6.2.0 or earlier. Exploitation for meaningful impact (beyond defacement) additionally requires that an authenticated user - ideally an administrator - visits the page containing the injected payload after it has been stored. The plugin's page-builder context means the 'comment' parameter is likely exposed on customizer or builder-facing endpoints rather than standard WordPress post comments. No special server configuration or non-default WordPress settings appear required.

The CVSS 7.2 score is driven largely by the Scope:Changed metric reflecting cross-context script execution in victim browsers, and PR:N indicating no authentication is required to inject the payload. However, the CVSS vector's UI:N metric is inconsistent with stored XSS mechanics: stored XSS inherently requires a victim to navigate to the injected page, meaning UI:R is more accurate and would reduce the score to approximately 6.1. This discrepancy should be noted by defenders when triaging. EPSS data was not provided, and there is no KEV listing or confirmed POC, so real-world exploitation risk is speculative but structurally high given the zero-barrier write path. The greatest practical risk is against WordPress sites with administrator or editor users who regularly visit the affected pages - a stored payload targeting admin sessions can lead to full site compromise through script-injected privilege escalation. The unauthenticated injection path (no login required) means automated scanning and mass exploitation across WordPress installations is feasible if exploits are developed.

An unauthenticated attacker sends a crafted HTTP request to the Kirki plugin endpoint with a malicious JavaScript payload embedded in the 'comment' parameter. The payload is stored in the WordPress database without sanitization. When a WordPress administrator subsequently visits the affected page to manage site content, their browser silently executes the injected script, which exfiltrates their session cookie or submits a forged admin action to create a backdoor account.