CVE-2023-3388

What it actually does

This is a stored cross-site scripting vulnerability caused by insufficient sanitization of the nsc_bar_content_href parameter and insufficient output escaping when the stored value is rendered. In affected versions of Beautiful Cookie Consent Banner for WordPress up to and including 2.10.1, an unauthenticated attacker can submit crafted script content that is persisted by the application and later executed in the browser of any user who views the affected page. Because the malicious script runs in the context of the trusted site, it can read or modify page content, perform actions as the victim within the application, redirect users, inject phishing content, or attempt to steal non-HttpOnly tokens and sensitive page data. Version 2.10.1 contained only a partial fix; the issue is fully addressed in 2.10.2. The supplied package metadata also references dataease/dataease Git fixes in commits 826513053146721a2b3e09a9c9d3ea41f8f10569 and 5f3a33acceac41b158735f405e8263f99c93bdf7, so organizations tracking that package should ensure those commits or later versions are present.

Why it matters to the business

Successful exploitation can turn a trusted web page into a delivery point for malicious browser code. This can lead to account compromise, fraudulent user actions, credential or session theft where browser protections are insufficient, reputational harm from defacement or phishing, and compliance concerns if user data exposed in the browser is accessed by attacker-controlled scripts. The high EPSS score of 0.84461 and weaponized exploit maturity indicate this should be treated as likely to be targeted in the wild even though it is not currently listed in CISA KEV and is not marked as ransomware-associated.

How an attack unfolds

An attacker identifies a site running an affected version of the vulnerable component. They send a crafted unauthenticated request that places JavaScript-bearing content into the nsc_bar_content_href value. Because the application does not adequately sanitize the input before storage and does not safely encode it before rendering, the payload remains stored in the site’s configuration or content. When a visitor, administrator, or other authenticated user loads a page that includes the affected cookie banner content, the attacker’s script executes in that user’s browser under the site’s origin. The script can then alter the page, redirect the user, capture data available to client-side code, or make same-origin requests using the victim’s active session. The attacker may use this to escalate impact by targeting administrators or high-value users who are likely to view the injected page.

How to fix it

Upgrade Beautiful Cookie Consent Banner for WordPress to version 2.10.2 or later; do not rely on 2.10.1 because it was only a partial patch. If the component cannot be upgraded immediately, disable the plugin or remove the vulnerable banner functionality until patched. Add compensating controls such as WAF rules that block script-bearing input to nsc_bar_content_href, strict output encoding, and a restrictive Content Security Policy to reduce script execution risk. Ensure session cookies are HttpOnly and SameSite where possible to limit credential theft from browser-side code. For environments tracking the supplied dataease/dataease Git package metadata, verify deployed code includes fixed commit 826513053146721a2b3e09a9c9d3ea41f8f10569 and/or 5f3a33acceac41b158735f405e8263f99c93bdf7, or a later release containing those fixes.

How to confirm the fix worked

Confirm the deployed component version is 2.10.2 or later, or that the relevant fixed Git commits are present for source-based deployments. Verify that version 2.10.1 is not considered remediated. Review rendered pages containing the cookie consent banner and confirm that user-controllable URL/content values are HTML-escaped or rejected rather than interpreted as markup or JavaScript. In a non-production test environment, submit a benign sentinel value containing characters commonly used in HTML tags and JavaScript URLs and confirm it is rejected, normalized, or rendered as inert text. Validate WAF or application-layer rules by confirming requests containing nsc_bar_content_href with script-like content are blocked or logged. Re-scan exposed sites with an authenticated and unauthenticated web vulnerability scanner after patching.

Typical attack path

1. Identify internet-facing sites or applications using the affected component/version.
2. Send a crafted request containing script content in the nsc_bar_content_href parameter.
3. Rely on the application to persist the malicious value because sanitization is insufficient.
4. Wait for users or administrators to browse to a page that renders the stored banner content.
5. Execute JavaScript in victims’ browsers within the trusted site context.
6. Use the victim browser context to steal accessible data, alter content, redirect traffic, or perform unauthorized same-origin actions.

How to detect it

Review web server, CDN, WAF, reverse proxy, and application logs for requests containing the nsc_bar_content_href parameter, especially unauthenticated POST or configuration-update requests. Prioritize entries containing script tags, javascript: URLs, HTML event handlers, URL-encoded angle brackets, base64-like blobs, or references to unfamiliar external domains. Inspect application configuration and rendered page output for injected scripts, iframes, suspicious redirects, or unexpected external JavaScript sources associated with the cookie consent banner. Correlate suspected injection times with subsequent administrator or user page views, browser telemetry, CSP violation reports, and outbound web requests to attacker-controlled domains. Look for follow-on indicators such as unexpected content changes, new privileged users, changed site settings, mass redirects, or anomalous authenticated actions shortly after affected pages were viewed. Because this is stored XSS, the exploit attempt and the impact may occur at different times: the initial malicious request stores the payload, and later page views trigger execution.

• nsc_bar_content_href=
• nsc_bar_content_href=%3Cscript
• nsc_bar_content_href=<script
• nsc_bar_content_href=javascript:
• nsc_bar_content_href=%6a%61%76%61%73%63%72%69%70%74%3a
• nsc_bar_content_href=*onerror*
• nsc_bar_content_href=*onload*
• nsc_bar_content_href=*onclick*
• nsc_bar_content_href=*document.cookie*
• nsc_bar_content_href=*localStorage*
• nsc_bar_content_href=*sessionStorage*
• nsc_bar_content_href=*XMLHttpRequest*
• nsc_bar_content_href=*fetch(*
• nsc_bar_content_href=*atob(*
• nsc_bar_content_href=*eval(*
• nsc_bar_content_href=*iframe*
• nsc_bar_content_href=*%3Ciframe*
• nsc_bar_content_href=*%3Cimg*
• nsc_bar_content_href=*%3Csvg*
• nsc_bar_content_href=*%3Cscript%3E*
• nsc_bar_content_href=*//
• nsc_bar_content_href=*https://*

What your security team should do

• Prioritize remediation because EPSS is very high and exploitation is weaponized, even without current KEV listing.
• Inventory public-facing WordPress sites and any applications using the affected component or referenced source package metadata.
• Upgrade to Beautiful Cookie Consent Banner 2.10.2 or later; remove or disable vulnerable versions if immediate patching is not possible.
• Treat version 2.10.1 as still vulnerable because the fix was partial.
• Deploy temporary WAF detections for nsc_bar_content_href containing script tags, event handlers, encoded markup, or javascript: URLs.
• Review historical web, WAF, CDN, and application logs for suspicious submissions to nsc_bar_content_href.
• Inspect stored site configuration and rendered banner content for injected markup, redirects, or external script references.
• Force reauthentication or rotate sessions for privileged users if evidence shows malicious script executed on administrative pages.
• Harden browser-side controls with Content Security Policy and HttpOnly/SameSite cookies to reduce XSS blast radius.
• Monitor for follow-on activity such as unauthorized content changes, new administrator accounts, suspicious redirects, or unusual same-origin requests after banner page views.