CVE-2024-2194

What it actually does

This is a stored cross-site scripting flaw in the WP Statistics WordPress plugin in versions up to and including 14.5. The plugin insufficiently sanitizes and escapes data derived from the URL search parameter before later rendering it in plugin-managed pages. An unauthenticated remote attacker can submit a crafted request containing JavaScript or HTML event-handler content that is stored by the plugin and later executed in the browser of any user who views the affected statistics or reporting page. Because execution occurs in the victim user’s browser session, impact depends on that user’s WordPress privileges and can include reading page content available to the user, performing actions with the user’s permissions, modifying site content, creating malicious redirects, or staging further compromise through administrator interaction.

Why it matters to the business

A successful attack can turn routine website analytics viewing into a compromise path for WordPress administrators and editors. For public websites, this can lead to unauthorized site changes, malicious script injection, visitor redirection, SEO spam, credential or session abuse, reputational damage, and incident response costs. The EPSS score is high, indicating meaningful likelihood of exploitation in the wild even though it is not currently listed in CISA KEV. The vulnerability has been public for a long time, so exposed legacy plugin installations should be treated as overdue for remediation. The supplied affected-product metadata references mongodb/mongo Git commits, which conflicts with the vulnerability description; organizations should validate inventory against the WordPress WP Statistics plugin advisory rather than relying solely on package-name matching.

How an attack unfolds

An attacker identifies a WordPress site running a vulnerable version of the WP Statistics plugin. Without authenticating, the attacker sends a request containing a malicious value in the search-related URL parameter that the plugin records for analytics. Because the plugin does not properly sanitize input before storage or escape it before display, the payload remains in the plugin’s stored statistics data. Later, when a site administrator, editor, or other privileged WordPress user opens the affected WP Statistics reporting or analytics page, the stored script executes in that user’s browser. The attacker’s script can then interact with the WordPress admin interface as the victim, attempt to create new administrative users, change site configuration, inject persistent malicious content, exfiltrate accessible nonces or page data, or redirect the user to a follow-on phishing or malware location.

How to fix it

Upgrade the WP Statistics WordPress plugin to a version later than 14.5 that contains the vendor fix. If the plugin cannot be upgraded immediately, disable or remove it until a fixed version can be deployed. Clear or purge historical analytics/statistics records that may contain stored script payloads, because upgrading the plugin may not automatically remove previously stored malicious content. Apply defense-in-depth controls including a WordPress-aware WAF rule for XSS payloads, strict Content Security Policy where feasible, least-privilege WordPress admin accounts, and reduced access to analytics/admin pages. Review the provided fixed-version metadata carefully: the listed mongodb/mongo Git commits 1b3b0073a0b436a8a502b612f24fb2bd572772e5 and f803681c3ae19817d31958965850193de067c516 do not align with the WP Statistics plugin description and should not be treated as the WordPress plugin remediation unless confirmed by the relevant vendor advisory.

How to confirm the fix worked

Confirm the installed WP Statistics plugin version is greater than 14.5 or that the plugin is disabled/removed. In WordPress administration, verify the plugin version from the Plugins page or by inspecting the plugin metadata in wp-content/plugins/wp-statistics. Confirm that cached pages, object caches, and CDN layers have been purged after the update. Review stored analytics/search records exposed through the plugin interface for encoded or decoded script content. Test with a benign XSS validation string in a non-production or authorized test environment and confirm it is rendered as inert text rather than executable markup. Validate that WAF or application logs show blocking or sanitization of common XSS patterns in search-related URL parameters.

Typical attack path

1. Scan public WordPress sites for evidence of the WP Statistics plugin or plugin-specific assets.
2. Confirm the plugin version is vulnerable or infer exposure from accessible plugin files, metadata, or behavior.
3. Send an unauthenticated HTTP request containing a crafted script payload in the vulnerable URL search parameter.
4. Allow the plugin to store the malicious search/URL value in its statistics data.
5. Wait for a privileged WordPress user to view the affected WP Statistics analytics or reporting page.
6. Execute JavaScript in the privileged user’s browser session.
7. Use the victim’s privileges to perform WordPress actions, inject malicious content, create persistence, or redirect users to attacker-controlled infrastructure.

How to detect it

Look for evidence in HTTP access logs, reverse proxy logs, CDN logs, WAF alerts, WordPress application logs, and security plugin logs. Focus on unauthenticated requests to WordPress pages that include search-related URL parameters containing HTML tags, JavaScript schemes, encoded angle brackets, encoded quotes, or event-handler attributes. Review WP Statistics administrative/reporting pages and exported analytics data for stored payloads that resemble scripts, iframes, SVG-based script execution, image error handlers, or redirects. Correlate suspicious requests with later WordPress administrator activity from the same time window, including new user creation, plugin or theme file edits, option changes, post injection, redirect changes, and unexpected administrator logins. Browser-side execution may leave little server-side evidence beyond the original stored payload and subsequent authenticated actions taken by the victim’s browser, so pair web log review with WordPress audit logs and file integrity monitoring. If threat hunting finds suspicious payloads, preserve raw logs and stored analytics records before cleanup.

• wp-content/plugins/wp-statistics
• /wp-admin/admin.php?page=wps_
• wp-statistics
• <script
• %3Cscript
• %253Cscript
• </script>
• %3C%2Fscript%3E
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onclick=
• onmouseover=
• %20onerror%3D
• %20onload%3D
• <img
• %3Cimg
• <svg
• %3Csvg
• <iframe
• %3Ciframe
• document.cookie
• localStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• String.fromCharCode
• window.location
• location.href

What your security team should do

• Prioritize identifying all WordPress sites using WP Statistics, especially internet-facing sites and sites with multiple administrator/editor users.
• Upgrade WP Statistics beyond version 14.5 or disable the plugin where an immediate upgrade is not possible.
• Treat vulnerable installations as potentially exposed due to the high EPSS score and age of public disclosure.
• Search web server, WAF, CDN, and WordPress logs for XSS payloads in search-related query parameters and requests to WordPress pages.
• Inspect WP Statistics analytics/reporting data for stored JavaScript, encoded HTML, suspicious event handlers, or unexpected redirects.
• Review recent WordPress administrative actions for unauthorized user creation, plugin/theme modification, content changes, and configuration changes.
• Rotate credentials and invalidate sessions for privileged WordPress users if evidence suggests a stored payload executed in an administrator browser.
• Do not rely on the supplied mongodb/mongo fixed commit metadata for WordPress plugin remediation unless independently validated against a vendor source.