CVE-2026-5924 in Getwid Plugin
Summary
by MITRE • 09/23/2026
The Getwid – Gutenberg Blocks plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Google Maps block's 'customStyle' attribute in all versions up to, and including, 2.1.3. This is due to the use of eval() on user-controlled block content in the frontend JavaScript mapStyles() function. 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified within the Getwid Gutenberg Blocks plugin for WordPress represents a significant security risk stemming from improper input validation and unsafe execution of dynamic code. Specifically, this flaw is classified as a Stored Cross-Site Scripting issue located in the Google Maps block's customStyle attribute across all versions up to 2.1.3. The root cause lies in the frontend JavaScript function mapStyles(), which utilizes the eval() method on user-controlled content derived from the block settings. By allowing arbitrary scripts to be stored within the post or page content and subsequently executed via eval, the application fails to sanitize input before processing it as executable code, creating a direct pathway for malicious script injection that persists in the database until manually removed.
From an operational perspective, this vulnerability allows authenticated attackers with Contributor-level access and above to inject arbitrary web scripts into pages managed by the site. Unlike reflected XSS where the payload is delivered via URL parameters or headers, stored XSS ensures that the malicious code resides on the server-side storage, such as a database entry associated with a specific post or page. Consequently, every time an administrator, editor, or any other user accesses the compromised page in their web browser, the injected script executes automatically within the context of the victim's session. This persistence makes the attack particularly dangerous because it does not require social engineering to trick users into clicking malicious links; simply viewing the affected content triggers the exploit, potentially leading to widespread compromise if high-privilege accounts are targeted or if the scripts steal sensitive data such as authentication cookies or session tokens from multiple visitors.
The technical implications of using eval() on unsanitized user input align closely with CWE-95, which describes improper neutralization of directives in dynamically evaluated code, and CWE-79, concerning Improper Neutralization of Input During Web Page Generation known generically as Cross-site Scripting. Furthermore, the exploitation technique maps to MITRE ATT&CK tactic TA0001 Initial Access via Valid Accounts, specifically leveraging stored XSS for persistence or credential harvesting under techniques like T1566.002 Phishing: Spearphishing Link if used in conjunction with social engineering, though here it is more accurately described as a direct exploitation of application logic to compromise user sessions and potentially escalate privileges through session hijacking. The use of eval() is particularly hazardous because it allows the execution of arbitrary JavaScript code constructed from string inputs, bypassing standard DOM-based security controls that might otherwise prevent script injection in safer rendering contexts like innerHTML with proper escaping.
To mitigate this vulnerability, immediate action must be taken to update the Getwid plugin to version 2.1.4 or later, where the developers have presumably addressed the unsafe use of eval() and implemented proper input sanitization for the customStyle attribute. In environments where updating is not immediately feasible, administrators should restrict user roles that can edit posts containing Google Maps blocks to only those with Administrator privileges, thereby reducing the attack surface available to lower-privileged users like Contributors or Authors. Additionally, implementing a Content Security Policy (CSP) header on the WordPress site can help mitigate the impact of any successful XSS attacks by restricting the sources from which scripts are allowed to execute, although this is considered a compensating control rather than a fix for the underlying code flaw. Regular security audits and static analysis tools should be employed during development or maintenance cycles to detect similar patterns of dynamic code execution based on user input across all installed plugins to prevent recurrence of such vulnerabilities.