CVE-2022-25149

What it actually does

This vulnerability is an unauthenticated SQL injection in the WP Statistics WordPress plugin versions up to and including 13.1.5. The plugin insufficiently escapes and parameterizes an IP-related value handled in includes/class-wp-statistics-hits.php, allowing a remote attacker to inject SQL into database queries. The primary technical consequence is unauthorized data disclosure from the WordPress database, including potentially user records, password hashes, email addresses, site configuration, plugin data, and other sensitive content accessible to the database account. The CVSS vector indicates network exploitation, low attack complexity, no authentication, and high confidentiality impact, with no direct integrity or availability impact. Exploit maturity is listed as weaponized and EPSS is high, so internet-facing WordPress sites running the vulnerable plugin should be treated as likely targeted. The supplied package metadata also references bytecodealliance/wasmtime fixed at commit 2ba4bce5cc719e5a74e571a534424614e62ecc41; because that does not align with the WordPress plugin vulnerability description, asset owners should validate product mapping before relying on that package association.

Why it matters to the business

Successful exploitation can expose sensitive website and user data stored in the WordPress database without requiring a valid login. This may lead to privacy incidents, credential-hash exposure, regulatory notification obligations, reputational damage, and follow-on compromise if leaked data enables password cracking or administrator account takeover. Because exploitation is weaponized and the EPSS score is high, organizations with public WordPress sites using vulnerable WP Statistics versions should prioritize remediation even though this CVE is not currently listed in CISA KEV and is not marked as ransomware-associated.

How an attack unfolds

An attacker first identifies a WordPress site using the WP Statistics plugin and determines, through plugin asset paths, metadata, or behavior, that the installed version is 13.1.5 or earlier. The attacker then sends unauthenticated HTTP requests that cause WP Statistics to process a crafted IP-related parameter or spoofed client-IP header. Because the plugin does not safely parameterize that value before using it in SQL, the injected SQL is interpreted by the database. The attacker can use boolean-based, error-based, time-based, or UNION-style SQL injection techniques to enumerate database structure and extract sensitive records such as WordPress users, email addresses, password hashes, options, and plugin data. In many cases the attacker will automate extraction with commodity SQL injection tooling and may then attempt credential cracking, session theft, or additional WordPress compromise using the recovered information.

How to fix it

Upgrade the WP Statistics WordPress plugin to a fixed release newer than 13.1.5, such as 13.1.6 or later where available from the official WordPress plugin repository. If immediate upgrade is not possible, disable or remove the WP Statistics plugin until it can be updated. Place additional controls in front of affected sites, such as a web application firewall rule to block SQL injection payloads in headers and request parameters, but do not treat filtering as a permanent fix. Review WordPress database account privileges and ensure the application database user has only the permissions required for normal operation. Rotate credentials if evidence suggests database contents or password hashes were accessed. If tracking the supplied package metadata, verify whether bytecodealliance/wasmtime is actually in scope for this CVE; if it is part of a separate internal dependency workflow, ensure builds include commit 2ba4bce5cc719e5a74e571a534424614e62ecc41 or later, but do not substitute that for updating the vulnerable WordPress plugin when WP Statistics is present.

How to confirm the fix worked

Confirm plugin inventory shows WP Statistics upgraded beyond 13.1.5 or removed. On disk, verify the plugin version from wp-content/plugins/wp-statistics/readme.txt, plugin headers, package manager inventory, or the WordPress admin plugin page. From the command line, WP-CLI can be used to check installed plugin versions where available. Confirm vulnerable files have been replaced by the updated release and that caching layers are not serving old plugin assets. Perform a safe, non-destructive SQL injection validation using an approved vulnerability scanner or controlled test payload against the previously affected request path or IP-handling behavior; the application should not return database errors, timing differences, or altered responses indicating SQL evaluation. Review WAF and web logs after upgrade to verify that exploit attempts are blocked or no longer produce abnormal application/database behavior.

Typical attack path

1. Scan internet-facing WordPress sites for indicators that the WP Statistics plugin is installed.
2. Fingerprint the plugin version or infer vulnerability by checking exposed plugin assets and behavior.
3. Send unauthenticated requests containing SQL injection payloads in an IP-related input or client-IP forwarding header processed by WP Statistics.
4. Confirm injection using timing, boolean, error, or content differences in responses.
5. Enumerate database names, table names, and WordPress table prefixes.
6. Extract sensitive records such as wp_users, user emails, password hashes, wp_options, and plugin-stored analytics data.
7. Use recovered data for credential cracking, phishing, privilege escalation, or broader WordPress compromise.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse proxy logs, CDN logs, WAF events, WordPress application logs, PHP error logs, and database logs covering the period before remediation. Focus on unauthenticated requests to WordPress endpoints around the time WP Statistics records visits, especially requests with suspicious SQL syntax in query strings, POST bodies, cookies, user-agent values, referrers, or IP-related headers such as X-Forwarded-For, X-Real-IP, Client-IP, X-Client-IP, True-Client-IP, CF-Connecting-IP, and Forwarded. Look for SQL injection techniques including UNION SELECT, boolean conditions, comments, stacked query delimiters, sleep or benchmark timing functions, information_schema enumeration, updatexml/extractvalue error-based payloads, and references to WordPress tables such as wp_users or wp_options. Correlate suspicious requests with database errors, slow queries, spikes in 500 responses, unusual outbound traffic, and subsequent WordPress authentication activity. In WordPress, inspect administrator accounts, recently modified users, password reset events, new plugins/themes, modified PHP files, and wp-config.php changes. In database logs, search for abnormal SELECT statements against user, options, and statistics tables originating from the WordPress application account. Absence of logs does not prove absence of compromise, because blind SQL injection may leave only subtle timing and request-pattern evidence.

• /wp-content/plugins/wp-statistics/
• /wp-content/plugins/wp-statistics/includes/class-wp-statistics-hits.php
• wp-statistics
• class-wp-statistics-hits.php
• X-Forwarded-For: '
• X-Real-IP: '
• Client-IP: '
• X-Client-IP: '
• True-Client-IP: '
• CF-Connecting-IP: '
• Forwarded: for='
• UNION SELECT
• UNION ALL SELECT
• information_schema
• SLEEP(
• BENCHMARK(
• updatexml(
• extractvalue(
• LOAD_FILE(
• INTO OUTFILE
• SELECT @@version
• SELECT database()
• wp_users
• wp_options
• wp_statistics_
• %27%20OR%20
• %27%20UNION%20SELECT
• -- -
• #
• /*

What your security team should do

• Immediately inventory public WordPress sites for WP Statistics plugin versions up to and including 13.1.5.
• Upgrade WP Statistics to a fixed version newer than 13.1.5 or disable the plugin until patching is complete.
• Prioritize internet-facing sites because exploitation is unauthenticated, weaponized, and has a high EPSS probability.
• Hunt historical web, WAF, CDN, and database logs for SQL injection payloads in request parameters and client-IP headers.
• Review WordPress user accounts for suspicious administrator creation, unexpected password resets, or anomalous logins after suspected exploitation.
• If database exposure is suspected, rotate WordPress salts, database credentials, administrator passwords, and any secrets stored in WordPress configuration or options.
• Add or tune WAF detections for SQL injection keywords in X-Forwarded-For, X-Real-IP, Client-IP, Forwarded, and related headers.
• Validate vulnerability-management asset mapping because the supplied affected-product metadata references wasmtime, while the vulnerability description identifies the WP Statistics WordPress plugin.