CVE-2026-84151 in Post Grid Plugin
Summary
by MITRE • 09/24/2026
The Post Grid WordPress plugin before 7.9.5 does not limit an expansion of the WordPress allowed-HTML list to its own markup and applies it site-wide, allowing users with the Contributor role and above to store iframe, style and input elements that are normally stripped from their content, leading to HTML injection (phishing frames, CSS defacement and spoofed input forms) that renders to any visitor and to administrators reviewing the content.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in Post Grid versions prior to 7.9.5 represents a significant security flaw rooted in improper access control and insufficient validation of user-supplied data within the WordPress ecosystem. Specifically, the plugin fails to restrict the expansion of the global allowed HTML list to its own specific markup requirements. Instead, it applies these expanded permissions site-wide, effectively altering the content filtering mechanisms for all plugins and core functionalities that rely on this shared configuration. This architectural oversight allows users with Contributor role privileges or higher to inject elements such as iframes, style tags, and input fields into their posts, which are typically stripped by WordPress's default sanitization processes due to security policies designed to prevent cross-site scripting attacks.
From a technical perspective, the core issue lies in how the plugin interacts with the wp_kses_allowed_html filter or similar whitelisting mechanisms without scoping the changes appropriately. By modifying global state rather than local context, the vulnerability bypasses standard content sanitization routines that would otherwise neutralize potentially dangerous HTML tags. This results in stored cross-site scripting conditions where malicious payloads are persisted on the server side and subsequently rendered to any visitor viewing the affected post or page. The presence of iframe elements enables phishing attacks by embedding external pages within the legitimate site context, while style tags can be exploited for CSS defacement or clickjacking techniques that manipulate visual presentation to deceive users. Additionally, input fields allow for spoofed forms designed to harvest credentials or sensitive information under the guise of a trusted domain.
The operational impact of this vulnerability is severe due to its broad applicability and low privilege requirement. Since Contributor-level accounts are often granted by site administrators for content creation purposes without full administrative trust, attackers can exploit these lower-privilege accounts to execute persistent attacks against all site visitors. The attack vector includes phishing frames that mimic legitimate login pages or critical alerts, CSS defacement that alters the visual integrity of the website to spread misinformation or damage brand reputation, and spoofed input forms that capture user data such as usernames and passwords. Furthermore, because these malicious elements render correctly in browsers, they also pose a risk to administrators who review content before publication, potentially leading to credential theft if an administrator interacts with a hidden form or is tricked by a phishing frame during the editorial process.
This vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS). More specifically, it falls under Stored XSS where malicious scripts are permanently stored on target servers and executed whenever users request the affected information. In terms of MITRE ATT&CK framework classification, this behavior corresponds to T1059 Command and Control Interface Over a Different Protocol or potentially T1189 Drive-by Compromise depending on the specific payload delivery method, but primarily it facilitates Initial Access through Phishing via Trusted Sites if used in conjunction with social engineering. The lack of scope restriction for HTML whitelisting also reflects CWE-74 Improper Neutralization Special Elements in Output Used by a Downstream Component indicating that one component's output is consumed by another without proper sanitization, leading to unintended side effects across the application environment.
Mitigation strategies must focus on immediate remediation and long-term hardening of WordPress configurations. The primary solution involves upgrading Post Grid to version 7.9.5 or later where this issue has been addressed through improved scoping of HTML whitelist modifications so that they do not affect global site-wide filtering rules. For sites unable to upgrade immediately, administrators should restrict the Contributor role's capabilities using security plugins like Wordfence or Sucuri to prevent access to visual editors that allow raw HTML insertion. Additionally implementing a Content Security Policy header can help mitigate some impacts by restricting where scripts and frames are loaded from, although this is not a substitute for fixing the underlying vulnerability. Regular auditing of user roles and permissions ensures that only trusted individuals have elevated privileges capable of modifying content structures, thereby reducing the attack surface available to potential adversaries seeking to exploit stored XSS vectors within the WordPress platform.