URGENT: Unauthenticated Stored XSS in WP Statistics (≤14.16.4) — What Site Owners Must Do Now

Date: 17 Apr, 2026
Affected software: WP Statistics plugin for WordPress (versions ≤ 14.16.4)
Patched version: 14.16.5
CVE: CVE-2026-5231
Severity: Medium (CVSS 7.1) — unauthenticated stored XSS via the utm_source parameter

As security practitioners based in Hong Kong, we focus on practical, quickly actionable guidance for site owners and administrators. An unauthenticated stored Cross‑Site Scripting (XSS) vulnerability has been disclosed in the WP Statistics plugin (≤14.16.4). While stored XSS does not always equate to an immediate full takeover, it is a serious risk: attackers may store script payloads that execute in a privileged user’s browser (for example, an administrator), enabling session theft, defacement, redirects, or privilege escalation.

This advisory explains the vulnerability, exploitation flow, immediate actions you must take, detection techniques, incident response steps, and long‑term hardening recommendations.

Executive summary (for site owners)

• What happened: WP Statistics versions up to 14.16.4 improperly handled UTM/referrer data (the utm_source parameter), allowing an attacker to inject HTML/JavaScript that can be stored and later rendered in administrative or public views.
• Who is affected: Sites running the WP Statistics plugin version 14.16.4 or earlier.
• Risk: If an attacker can persuade an administrator or other privileged user to view a page that renders stored values, JavaScript can execute in that user’s browser (stored XSS). Resulting impacts include account takeover, site compromise, or data exfiltration when combined with social engineering.
• Immediate actions:
  1. Update WP Statistics to version 14.16.5 or later.
  2. If you cannot update immediately, implement temporary compensating controls such as blocking suspicious input in utm_ parameters at the edge (WAF/request filtering) and restrict access to statistics pages.
  3. Scan databases for suspicious stored values and clean any found entries.
  4. Monitor logs and administrative activity for signs of compromise.

What is stored XSS and why this matters here?

Cross‑Site Scripting (XSS) enables an attacker to execute client‑side code in a victim’s browser. Stored XSS means the malicious content is persisted on the server (usually in a database) and later rendered to users without proper escaping. In this case, WP Statistics records UTM/referrer values for analytics but failed to sufficiently sanitize or escape utm_source before storing or rendering it in certain contexts. An attacker can craft a request to the site containing a malicious utm_source value; that payload can be stored and later execute when a human (often an admin) views a page that displays the saved field.

Why this is particularly risky:

• The initial submission can be done by unauthenticated actors — no login required.
• The stored payload can execute in the context of a privileged user (administrator) when they view the affected page.
• Social engineering and shared admin links amplify risk: attackers may seed payloads and try to lure admins to specific pages.

Typical exploitation flow (high level)

1. An attacker crafts a URL containing a malicious utm_source value, for example:

   https://example.com/?utm_source=

2. The victim or a bot visits the URL, or the attacker causes requests that the site logs.
3. WP Statistics records the utm_source in the database as part of visitor analytics.
4. When an administrator or other privileged user views a dashboard or page where that stored value is rendered without proper escaping, the injected JavaScript executes in their browser.
5. Consequences vary by payload: creating admin users, exfiltrating cookies, loading additional malicious scripts, or performing actions under the admin session.

Note: The vulnerability allows unauthenticated submission, but it requires a privileged user to render the stored content for execution.

Immediate remediation checklist (step‑by‑step)

1. Update WP Statistics to 14.16.5 or later

   The plugin author released a patch in 14.16.5 addressing sanitization/escaping issues. Update immediately via the WordPress dashboard or wp‑cli:

   wp plugin update wp-statistics --version=14.16.5

   Test updates on staging before rolling out to production if you manage many sites.

2. If you cannot update immediately, apply compensating controls
   • Use request‑filtering at the edge (WAF or web server rules) to block or sanitize requests containing script tags or suspicious constructs in utm_ parameters.
   • Restrict access to statistics/reporting pages to administrators only until patched.
3. Scan and remove stored malicious values

   Search the plugin’s database tables for suspicious utm_source values. Typical tables include wp_statistics_visitors or wp_statistics_pageviews, depending on schema.

   Example SQL (run on a staging copy first — take backups):

   SELECT * FROM wp_statistics_visitors
   WHERE utm_source LIKE '%

   Remove or sanitize rows that contain injected markup. If you find signs of active compromise (new admin users, modified files), follow the incident response checklist below.

4. Rotate credentials and review admin accounts
   • Reset passwords for administrative accounts and enforce strong passwords and multi‑factor authentication (MFA).
   • Review wp_users and user roles for unauthorized accounts or privilege changes.
5. Monitor logs and alerts
   • Inspect web server and application logs for requests with suspicious utm_ parameters or encoded payloads (e.g. %3Cscript%3E).
   • Watch for unusual administrative activity, unexpected plugin/module changes, or unexpected scheduled tasks.