Overview
A newly disclosed vulnerability in Real Cookie Banner: GDPR & ePrivacy Cookie Consent, a WordPress plugin installed on more than 100,000 sites, allows unauthenticated attackers to store malicious JavaScript inside a public comment and have it execute in the browser of anyone who later views that comment. Tracked as CVE-2026-92977 and reported by Wordfence, the flaw carries a CVSS v3.1 score of 7.2 (High) and affects all plugin versions up to and including 5.3.5. The vendor has shipped a fix in version 5.3.6.
Unlike most of this plugin's prior security issues, which required an authenticated Contributor-or-higher account, this vulnerability requires no account at all — any site visitor who can submit a comment can attempt exploitation. Real Cookie Banner is widely deployed specifically because it handles GDPR/ePrivacy consent management, which means the sites running it are disproportionately likely to process EU personal data and already carry a heightened compliance profile.
Technical Details
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-92977 |
| Vulnerability Type | Stored Cross-Site Scripting (CWE-79) |
| Affected Product | Real Cookie Banner: GDPR & ePrivacy Cookie Consent (WordPress plugin, vendor: devowl) |
| Affected Versions | All versions ≤ 5.3.5 |
| Fixed Version | 5.3.6 |
| Attack Vector | Network — public comment form, no authentication required |
| CVSS v3.1 Score | 7.2 (High) |
| CVSS Vector | AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N |
| Reported By | Wordfence Threat Intelligence |
| Disclosure Date | October 2–3, 2026 |
| Active Installs (approx.) | 100,000+ |
| CISA KEV Listed | No |
| Public Exploit Code | Not observed at time of publication |
How It Works
The Vulnerable Surface
Real Cookie Banner hooks into WordPress's native comment system and performs its own HTML processing on comment content when rendering certain blocked-content notices and cookie-consent UI elements. The flaw lives specifically in how the plugin's rendering pipeline — inc/view/Blocker.php and the bundled vendor/devowl-wp/fast-html-tag/src/FastHtmlTag.php helper — reprocesses HTML attributes inside comment markup, independent of WordPress's own sanitization.
A Two-Stage Sanitization Bypass
The exploitation path has two distinct stages, which is why it slipped past WordPress's built-in protections:
- Save time — An attacker submits a comment containing a crafted
titleattribute on an anchor tag. The payload's structure is deliberately shaped to pass through WordPress core's commentksesfiltering untouched, because at save time it does not yet resemble an executable script. - Render time — When the comment is later displayed, the plugin applies a page-wide regular expression (in
FastHtmlTag.php) that strips the closing quote delimiter from certain HTML attributes. That stripping operation inadvertently promotes the previously "safe-looking" stored content into a live, executable HTML attribute — allowing injected JavaScript to run in the security context of the page for every visitor who views it.
Because the payload is written once and executes on every subsequent page view, this is a classic stored XSS: the malicious comment persists on the server until a site administrator deletes or edits it.
Why No Authentication Is Required
Most WordPress comment forms accept submissions from anyone, including logged-out visitors. On sites where comments are open, an attacker does not need a user account, an API key, or any prior access — only the ability to submit a comment on a page where Real Cookie Banner's affected rendering logic runs.
The Moderation Caveat
Exploitation is still subject to each site's comment moderation workflow. If a site requires comments to be manually approved before they appear publicly (the WordPress default for first-time commenters, and common practice generally), the malicious comment will not execute against real visitors until a moderator approves it — which also means a careless "approve" click by a site admin or moderator effectively deploys the payload against every subsequent visitor, including, potentially, the admin's own next page load.
Impact Assessment
| Impact Area | Description |
|---|---|
| Confidentiality | Low-to-moderate — injected script runs in the visitor's browser session and can access cookies, local storage, and any data the page exposes to client-side JavaScript. |
| Integrity | Low-to-moderate — an attacker can deface rendered content, inject fake consent prompts, or manipulate what the cookie banner displays to visitors. |
| Availability | None directly, but malicious scripts can degrade page performance or redirect visitors. |
| Privileged Targets | Session hijacking becomes more severe if an administrator views the affected page (e.g., while moderating comments), potentially exposing wp-admin session cookies or enabling admin-context actions. |
| Compliance Exposure | Elevated — this plugin exists specifically to manage GDPR/ePrivacy consent; a successful XSS on a consent-management surface undermines the very compliance control the plugin is meant to enforce. |
| Scope | Changed (CVSS "S:C") — the vulnerability impacts resources beyond the vulnerable component's own security scope, consistent with a comment being rendered across the broader page context. |
Recommendations
For WordPress Site Administrators
- Update immediately to Real Cookie Banner 5.3.6 or later via the WordPress Plugins screen or
wp plugin update real-cookie-banner. - Until patched, consider disabling public comments on pages where the plugin renders consent/blocker UI, or switch comment moderation to require approval for every comment, not just first-time commenters.
- Audit existing comments for suspicious
titleattributes on anchor tags or unusual HTML-like fragments submitted via the comment form; remove or edit any that look malformed. - Confirm the plugin's auto-update setting is enabled going forward, or add Real Cookie Banner to your patch-management tracking given its direct ties to compliance tooling.
For Security Teams
- Treat any WordPress asset running Real Cookie Banner ≤ 5.3.5 with open comments as exploitable without authentication and prioritize accordingly in vulnerability scanning.
- Add detection content for anomalous
title=attribute patterns in comment submissions at the WAF layer as a compensating control while patches roll out across managed sites. - Review browser-side logging/SIEM sources for unexpected script execution or outbound requests originating from pages that render user comments.
- Flag any site where an administrator regularly moderates comments as higher priority — admin-session compromise via this path is the most damaging realistic outcome.
For Site Owners / Content Moderators
- Do not approve comments containing unfamiliar HTML-looking text, encoded characters, or attributes you don't recognize, even if the comment text itself looks benign.
- If you moderate comments from an authenticated admin session, consider reviewing pending comments in a separate, unprivileged browser profile until the plugin is updated.
Key Takeaways
- CVE-2026-92977 is an unauthenticated stored XSS vulnerability in Real Cookie Banner ≤ 5.3.5, exploitable via the standard public comment form — no WordPress account required.
- The root cause is a two-stage bypass: a crafted anchor
titleattribute survives WordPress's commentksesfilter at save time, then gets promoted into an executable attribute by the plugin's own regex-based HTML processing at render time. - The fix is already available — update to version 5.3.6 or later without delay.
- Exploitation still depends on each site's comment moderation settings; sites with strict moderation have a window to catch malicious comments before approval, but a single careless approval activates the payload for all subsequent visitors.
- With 100,000+ active installs and a direct role in GDPR/ePrivacy compliance tooling, this plugin's attack surface is unusually consequential relative to a "medium-looking" 7.2 CVSS score.
- No public proof-of-concept or CISA KEV listing exists at time of publication, but Wordfence's technical writeup provides enough detail that functional exploit code could follow quickly — patch proactively rather than waiting for in-the-wild signals.