Urgent: Complianz <= 7.4.3 Stored XSS via Shortcode — What WordPress Site Owners Must Do Now

Author: Hong Kong Security Expert

TL;DR

A stored Cross-Site Scripting (XSS) vulnerability has been disclosed in the Complianz GDPR/CCPA Cookie Consent plugin for WordPress affecting versions <= 7.4.3 (CVE-2025-11185). An authenticated user with Contributor privileges (or higher) can inject JavaScript via plugin shortcodes. That payload is stored and later rendered, enabling client-side code execution in the context of site visitors and administrators.

If you run this plugin, act quickly:

• Update Complianz to version 7.4.4 or later immediately — this fully fixes the issue.
• If you cannot update right away, use the mitigations below: restrict contributor capabilities, search and remove suspicious shortcodes and script-like content, and apply temporary virtual patches via your WAF or filtering mechanisms.
• Use the detection and incident response checklist below to validate and recover if needed.

Background: what happened and why it matters

The Complianz cookie-consent plugin exposes a stored XSS issue when certain shortcodes accept untrusted input that is not properly sanitized or encoded before output. An attacker who can obtain a Contributor-level account (for example, via registration or account compromise) can create or edit content containing a malicious shortcode payload. When that content is rendered on the frontend — or viewed in certain admin contexts — the malicious script executes in the victim’s browser.

Stored XSS is particularly dangerous because the payload is saved in the site’s database and will execute for every visitor or administrator who views the affected page until it is removed.

Key facts at a glance

• Affected software: Complianz GDPR/CCPA Cookie Consent plugin for WordPress
• Vulnerable versions: <= 7.4.3
• Fixed in: 7.4.4
• CVE: CVE-2025-11185
• Required privilege: Contributor (authenticated)
• Type: Stored Cross-Site Scripting (XSS)
• Patch status: Update available — upgrade immediately

Technical root cause (high-level)

Shortcodes allow plugins to accept attributes and content that are later rendered as HTML. When a plugin fails to sanitize or escape these values before output, an attacker can insert markup or JavaScript that will run in users’ browsers.

In this case, the plugin’s shortcode handling accepted contributor-controlled data and later output it without sufficient encoding or filtering. That combination — authenticated content creation plus unsafe output encoding — results in stored XSS. This is a plugin-specific problem, not an issue with WordPress core shortcode functionality.

Real-world impact and scenarios

Stored XSS consequences extend beyond “client-side nuisance”:

• Session theft: cookies or tokens accessible to JavaScript can be exfiltrated.
• Privilege escalation: if an admin views the malicious content, the attacker may perform actions using that session.
• Reputation and SEO damage: injected adverts, redirects or malicious content harm trust and rankings.
• Malware distribution: redirects to malicious sites or drive-by downloads.
• Data exfiltration: scraping sensitive DOM content viewable in the browser.
• Persistent compromise: stored payloads remain until removed and can support follow-on attacks.

Sites that allow admins or editors to preview contributor content are at heightened risk — an attacker needs only one privileged user to view the malicious content to escalate impact.

How an attacker might exploit this (step-by-step, no exploit code)

1. Attacker registers as a Contributor (or compromises a Contributor account).
2. They add a shortcode with malicious attributes or content to a post/page or other content area that accepts shortcodes.
3. The payload is saved in the database (stored) and may appear innocuous in the editor.
4. When an admin/editor or visitor views the page, the plugin renders the shortcode and emits the malicious JavaScript into the page HTML.
5. The script executes in the victim’s browser and can carry out actions such as session theft, CSRF-like admin actions, defacement, redirects, or data exfiltration.

Exploitability & likelihood

This vulnerability requires an authenticated Contributor-level account. The real-world likelihood depends on how easy it is for attackers to obtain such an account on your site:

• Open registration: higher risk — attackers can self-register.
• Moderated registration: moderate risk (compromise or social engineering possible).
• Restricted registration: lower risk.

Published CVSS is 6.5 (Medium), but if admins regularly preview contributor content the practical impact can be higher.

Indicators of Compromise (IoCs) — what to look for

Search your site and logs for these common signals. They are not exhaustive but will catch many cases.

Content and database checks

• New or edited posts/pages containing unexpected shortcodes or unfamiliar shortcode names related to cookie-consent or privacy features.
• Posts or meta entries containing script tags (show as
  Review My Order

  0

  Subtotal

  Taxes & shipping calculated at checkout

  Checkout