CVE-2026-6275: StatCounter WordPress Plugin Stored XSS Vulnerability

Technical summary

CVE-2026-6275 is a stored XSS vulnerability in StatCounter plugin versions up to 2.1.1. The statcounter_addToTags() function, hooked to wp_head, retrieves the post author's nickname via the_author_meta() and directly echoes it into a JavaScript double-quoted string context within a <script> block. The absence of esc_js() or equivalent JavaScript-context escaping allows attackers with Author-level or higher privileges to craft a malicious nickname containing JavaScript code that persists in the WordPress database. This payload executes on every page view of that author's posts, affecting all visitors including unauthenticated users.

Business impact

This vulnerability creates a mechanism for privilege escalation and content manipulation within WordPress sites. Compromised author accounts—or attackers who gain author access—can inject JavaScript to harvest visitor credentials, redirect users to phishing sites, distribute malware, or deface content. For multi-author WordPress installations with external contributors, the attack surface expands significantly. The persistent nature of stored XSS means the malicious payload affects all future visitors until remediated, maximizing exposure window.

Affected systems

StatCounter – Free Real Time Visitor Stats plugin versions up to and including 2.1.1 running on WordPress are affected. The vulnerability is triggered whenever any user visits a post authored by an attacker, making any WordPress site using this plugin and hosting author-level users a potential target. Sites with permissive user roles or guest posting features face heightened risk.

Exploitability

Exploitation requires Author-level access or higher (Contributor role cannot author posts by default). The attack requires no user interaction from the victim—scripts execute automatically on page load. The CVSS score of 6.4 (Medium) reflects the requirement for authenticated access, but the network-accessible nature and broad victim reach (all site visitors) elevate practical risk. No active exploitation in the wild is currently documented (KEV status: not added).

Remediation

Update the StatCounter plugin to a patched version that applies esc_js() or similar JavaScript-context escaping to the author nickname output. Verify the fix against the plugin vendor's security advisory. Until patching is possible, restrict Author-level access to trusted internal users only, audit existing author accounts for suspicious nickname values, and consider disabling the plugin if it is not actively used for visitor analytics.

Patch guidance

Check the StatCounter plugin repository and vendor advisories for version 2.1.2 or later, which should address this vulnerability. Apply updates through the WordPress admin dashboard (Plugins > Updates) after testing in a staging environment. If a patch is not yet available, consider disabling the plugin or rolling back to an earlier version if vulnerabilities are confirmed in your deployment. Always verify patch applicability against the plugin's official security announcement.

Detection guidance

Review author and contributor account nicknames in WordPress (Users admin panel) for suspicious JavaScript code, quotes, or special characters that may indicate injection attempts. Check plugin configuration to ensure statcounter_addToTags() is not being exploited. Monitor website traffic and user behavior for redirects or anomalous script execution. Enable WordPress security logging to capture changes to user metadata. If you suspect exploitation, inspect the post_author_meta database table for injected JavaScript payloads targeting the 'nickname' field.

Why prioritize this

Although rated Medium severity, this vulnerability warrants prompt remediation in multi-user WordPress environments. The combination of stored persistence, automatic execution on every post view, and broad victim reach (all site visitors) makes it an attractive vector for attackers with author access. Organizations with guest blogging, contributor networks, or external user bases should prioritize patching. The requirement for authenticated access slightly lowers urgency compared to unauthenticated flaws, but the ease of exploitation once access is obtained justifies timely action.

Risk score, explained

CVSS 3.1 score of 6.4 (Medium) is driven by: Attack Vector (Network) and Attack Complexity (Low) reflecting easy exploitation via web interface; Privileges Required (Low) limiting scope to authenticated users; User Interaction (None) meaning no victim action needed; Scope (Changed) because the payload affects other visitors beyond the attacker; Confidentiality and Integrity (Low) due to potential data theft or content manipulation, though availability is not impacted. The score does not penalize the stored nature or broad exposure—consider raising prioritization internally if your site hosts many authors or has high visitor volume.

Frequently asked questions