CVE-2022-25148

What it actually does

WP Statistics for WordPress versions up to and including 13.1.5 contain an unauthenticated SQL injection vulnerability in handling of the `current_page_id` parameter in `includes/class-wp-statistics-hits.php`. Because user-controlled input is not sufficiently escaped or parameterized before being incorporated into SQL queries, a remote attacker can inject arbitrary SQL. Successful exploitation can allow extraction of WordPress database contents, modification of stored data, creation or alteration of privileged accounts depending on database permissions, and potentially denial of service through expensive or destructive queries.

Why it matters to the business

A public WordPress site using a vulnerable WP Statistics plugin version can be compromised without login credentials, potentially exposing user data, administrator password hashes, content, customer information, analytics data, and site configuration secrets. With a CVSS score of 9.8, high EPSS probability, and weaponized exploit maturity, this should be treated as urgent even though it is not listed in CISA KEV. Compromise can lead to website defacement, malware injection, SEO spam, credential theft, regulatory exposure, and operational downtime.

How an attack unfolds

An attacker first identifies a WordPress site running WP Statistics version 13.1.5 or earlier, typically by checking plugin metadata, static assets, or fingerprinting exposed WordPress behavior. The attacker then sends unauthenticated HTTP requests containing crafted SQL syntax in the `current_page_id` parameter that reaches the vulnerable hit-tracking code path. Because the plugin fails to safely parameterize this value, the injected SQL is executed by the WordPress database user. The attacker can use boolean-based, error-based, or time-based SQL injection techniques to confirm the flaw, enumerate database structure, dump sensitive records such as users and password hashes, and in some cases modify database rows to create persistence, change administrator credentials, inject malicious content, or disrupt the site.

How to fix it

Upgrade WP Statistics to a fixed release, preferably the latest available version from the official WordPress plugin repository or vendor. If a specific minimum version is required, use version 13.1.6 or later, as versions up to and including 13.1.5 are affected. If immediate upgrading is not possible, disable and remove the WP Statistics plugin until it can be updated. Restrict direct access to WordPress administrative and plugin-related endpoints where feasible, deploy a web application firewall rule to block SQL injection payloads in the `current_page_id` parameter, and ensure the WordPress database user has only the privileges required for normal operation. After patching, rotate WordPress administrator passwords and review database integrity if exploitation is suspected.

How to confirm the fix worked

Confirm that WP Statistics is no longer present at an affected version by checking the WordPress Plugins page, the plugin `readme.txt` or metadata where accessible, filesystem plugin version information, or software inventory records. Verify the installed version is 13.1.6 or later, preferably the latest release. Test externally that requests containing SQL metacharacters or time-delay functions in `current_page_id` are blocked or do not produce database errors, timing changes, or abnormal responses. Review WAF, web server, and application logs for historical requests containing `current_page_id` with SQL syntax. Confirm no unexpected WordPress administrator users, changed site URLs, injected posts/pages/widgets, suspicious plugin/theme files, or modified database options remain after remediation.

Typical attack path

1. Fingerprint a WordPress site and determine whether the WP Statistics plugin is installed.
2. Confirm the plugin version is 13.1.5 or earlier, or attempt exploitation when version information is hidden.
3. Send unauthenticated requests to the vulnerable statistics hit-tracking endpoint or page flow with a crafted `current_page_id` parameter.
4. Use SQL injection techniques such as boolean conditions, UNION queries, error triggering, or time delays to validate database execution.
5. Enumerate database names, table prefixes, WordPress users, options, and plugin data.
6. Extract sensitive records such as administrator usernames, email addresses, password hashes, session-related values, or configuration data available to the database user.
7. Optionally modify database content, create or elevate accounts, inject malicious JavaScript or spam content, or cause availability impact with heavy or destructive queries.
8. Use stolen credentials or database changes to obtain longer-term WordPress administrative access.

How to detect it

Investigate web access logs, CDN logs, reverse proxy logs, WAF events, PHP error logs, WordPress debug logs, database slow query logs, and authentication logs for unauthenticated requests carrying suspicious `current_page_id` values. Prioritize requests containing SQL operators, comments, UNION SELECT patterns, information_schema access, MySQL time-delay functions, encoded quotes, or stacked-query separators. Look for database errors exposed in HTTP responses or PHP logs near these requests, including SQL syntax errors from WordPress database calls. Review database logs for abnormal SELECTs against WordPress users/options tables, information_schema enumeration, time-delay functions, or heavy queries correlated with public web requests. Post-exploitation artifacts may include newly created administrator users, modified user email addresses or password hashes, changed `siteurl` or `home` options, injected scripts in posts/widgets/options, unfamiliar plugins or themes, and new PHP files under WordPress writable directories. Because exploitation is weaponized and unauthenticated, absence of WordPress login events does not rule out compromise.

• current_page_id=
• current_page_id=%27
• current_page_id='
• current_page_id=%22
• current_page_id="
• current_page_id%3D
• current_page_id=*
• current_page_id=0%20OR%20
• current_page_id=1%20OR%201=1
• current_page_id=1' OR '1'='1
• current_page_id=1%27%20OR%20%271%27%3D%271
• current_page_id=1--
• current_page_id=1%2D%2D
• current_page_id=1%23
• current_page_id=1/*
• current_page_id=1%2F%2A
• UNION SELECT
• UNION%20SELECT
• information_schema
• INFORMATION_SCHEMA
• SLEEP(
• sleep(
• SLEEP%28
• BENCHMARK(
• benchmark(
• BENCHMARK%28
• WAITFOR DELAY
• extractvalue(
• EXTRACTVALUE(
• updatexml(
• UPDATEXML(
• concat(
• CONCAT(
• group_concat(
• GROUP_CONCAT(
• SQL syntax
• You have an error in your SQL syntax
• WordPress database error
• includes/class-wp-statistics-hits.php
• wp-content/plugins/wp-statistics/
• /wp-content/plugins/wp-statistics/readme.txt

What your security team should do

• Immediately identify all WordPress sites running WP Statistics and prioritize any instance at version 13.1.5 or earlier.
• Upgrade WP Statistics to 13.1.6 or later, preferably the latest available release; disable the plugin where patching cannot be completed quickly.
• Because exploit maturity is weaponized and EPSS is high, perform compromise assessment on exposed sites rather than treating patching alone as sufficient.
• Search web server, CDN, reverse proxy, WAF, and WordPress logs for suspicious `current_page_id` requests containing SQL keywords, comments, quotes, encoded characters, or time-delay functions.
• Review WordPress users for unexpected administrator accounts, recent password resets, unfamiliar email addresses, and suspicious login activity following possible SQL injection attempts.
• Inspect posts, pages, widgets, theme files, plugin files, and WordPress options for injected JavaScript, spam links, redirects, or unauthorized configuration changes.
• Rotate administrator passwords and invalidate sessions if exploitation is suspected; consider rotating database credentials if database modification or credential exposure is plausible.
• Ensure WordPress database accounts follow least privilege and do not have unnecessary administrative database permissions.
• Deploy or tune WAF rules for SQL injection attempts against WordPress parameters, especially `current_page_id`.
• Add vulnerable WordPress plugins to continuous asset inventory and patch management workflows so plugin-level exposure is tracked like server software vulnerabilities.