Description

The GutenKit – Page Builder Blocks, Patterns, and Templates for Gutenberg Block Editor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘postBodyCss’ parameter in all versions up to, and including, 2.4.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-03T13:05:06.937Z",
  "pubdate": "2026-09-03T13:05:06.937Z",
  "executiveSummary": "The GutenKit – Page Builder Blocks, Patterns, and Templates for Gutenberg Block Editor plugin is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability. This security flaw originates from inadequate input sanitization and output escaping within the 'postBodyCss' parameter. The vulnerability affects all versions of the plugin up to and including 2.4.4.\nThe impact of this vulnerability is significant, as it allows authenticated attackers with Contributor-level privileges or higher to inject arbitrary malicious JavaScript into pages. When a victim, such as an administrator, accesses the compromised page, the injected script executes within the context of the user's session. This facilitates unauthorized actions, potential session hijacking, and the manipulation of site content or administrative settings. Because the script is stored permanently within the database, the payload persists until manually removed or the vulnerability is patched. The risk is classified as high due to the potential for privilege escalation and unauthorized administrative activity originating from low-privileged accounts.",
  "technicalDetails": "The root cause of this vulnerability is improper handling of user-supplied data in the 'postBodyCss' parameter. The plugin fails to apply sufficient sanitization or secure output escaping mechanisms to the content submitted via this parameter, allowing malicious input to be treated as legitimate HTML or JavaScript when rendered in the browser of a victim.\nExploitation requires the attacker to possess Contributor-level access or higher on a WordPress installation utilizing the vulnerable plugin. The attack vector involves submitting a crafted payload containing script tags or other malicious HTML attributes into the 'postBodyCss' field. Upon saving the post or block configuration, the payload is persisted into the WordPress database.\nThe attack flow follows these steps: 1. The attacker authenticates as a user with at least Contributor privileges. 2. The attacker identifies the vulnerable block or setting that utilizes the 'postBodyCss' parameter. 3. The attacker injects a malicious payload into the 'postBodyCss' input field. 4. The server-side code processes the request, failing to sanitize the malicious input, and commits it to the database. 5. When an unsuspecting user, such as an administrator, navigates to a page where this block or CSS configuration is loaded, the WordPress engine retrieves the malicious string from the database and renders it directly into the DOM without escaping.\nThe injected payload behavior is determined by the attacker's script; it executes automatically within the target user's browser session. Because the script executes in the context of the WordPress site, it can perform unauthorized HTTP requests, access sensitive cookies, or execute administrative actions on behalf of the logged-in user. This effectively bypasses typical security controls, leading to a compromise of the affected user's account and potential site-wide disruption.\nThis vulnerability is restricted to environments where the 'postBodyCss' parameter is processed by the plugin's frontend rendering engine. Since the payload is stored server-side, this is a classic Stored XSS attack. The vulnerability persists across all plugin versions up to 2.4.4, necessitating a code-level fix that implements robust input filtering (e.g., using sanitize_text_field or similar WordPress sanitization APIs) and ensures all reflected output is passed through proper escaping functions like esc_js or esc_html."
}