CVE-2022-0513

What it actually does

CVE-2022-0513 is an unauthenticated SQL injection vulnerability in the WP Statistics WordPress plugin through version 13.1.4. The vulnerable code insufficiently escapes and parameterizes the `exclusion_reason` parameter in `includes/class-wp-statistics-exclusion.php` when the plugin's "Record Exclusions" option is enabled. A remote attacker can send crafted requests that alter backend SQL queries and read sensitive database contents. The CVSS vector indicates high confidentiality impact with no required authentication or user interaction; integrity and availability impact are not the primary documented outcomes.

Why it matters to the business

A public WordPress site running a vulnerable WP Statistics version may allow an internet-based attacker to extract sensitive database information, potentially including user account data, email addresses, password hashes, site configuration data, and other content stored in the WordPress database. Because exploit code is available and EPSS is elevated, exposed sites should be treated as likely targets for opportunistic scanning even though this vulnerability is not currently listed in CISA KEV and is not known from the provided data to be ransomware-associated.

How an attack unfolds

An attacker first identifies a WordPress site using the WP Statistics plugin and determines that the installed version is 13.1.4 or earlier. If the plugin's "Record Exclusions" option is enabled, the attacker sends unauthenticated HTTP requests containing a malicious `exclusion_reason` value. The application passes this attacker-controlled value into a SQL query without adequate parameterization, allowing the attacker to append SQL logic. In practical exploitation, the attacker may use boolean-based, error-based, union-based, or time-based SQL injection payloads to confirm the flaw, enumerate database metadata such as table names, and extract sensitive records from WordPress tables. The attack can be performed remotely over the network and does not require a valid WordPress login.

How to fix it

Upgrade WP Statistics to a vendor-fixed release newer than 13.1.4, preferably the latest available version from the official WordPress plugin repository or vendor source. If immediate upgrade is not possible, disable the WP Statistics "Record Exclusions" option, or temporarily disable/remove the plugin until patched. Apply a web application firewall rule that blocks suspicious SQL syntax in the `exclusion_reason` parameter as a temporary compensating control, but do not rely on filtering as the primary fix. Review WordPress database user privileges and ensure the application account has only the minimum permissions needed. After patching, rotate credentials if there is evidence that database contents, password hashes, salts, API keys, or configuration secrets may have been accessed.

How to confirm the fix worked

Confirm that WP Statistics is updated to a release newer than 13.1.4 or to the latest vendor-supported version. In the WordPress administrative interface or filesystem, verify the plugin version reported in the WP Statistics plugin metadata. Confirm that the "Record Exclusions" setting is disabled if the site cannot be upgraded immediately. Test exposure using a safe, non-destructive SQL injection assessment method in an authorized environment, such as sending benign payloads to the `exclusion_reason` parameter and confirming that responses and timing do not indicate SQL evaluation. Review web server and application logs for prior suspicious requests containing `exclusion_reason` with SQL metacharacters or functions. Validate that WAF or reverse proxy controls, if deployed, are logging and blocking SQL injection attempts against WordPress endpoints.

Typical attack path

1. Scan internet-facing WordPress sites for evidence of the WP Statistics plugin.
2. Identify sites running WP Statistics version 13.1.4 or earlier.
3. Determine whether the "Record Exclusions" feature is enabled or infer exposure through test requests.
4. Send crafted unauthenticated requests containing SQL injection payloads in the `exclusion_reason` parameter.
5. Use SQL injection techniques such as boolean, error, union, or time-based extraction to confirm database access.
6. Enumerate WordPress database schema and sensitive tables.
7. Extract data such as users, email addresses, password hashes, configuration values, or other site content.
8. Optionally use stolen data to support credential attacks, further compromise, or data extortion.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF events, CDN security logs, and WordPress/PHP error logs for unauthenticated requests containing the `exclusion_reason` parameter with SQL injection syntax. Focus on requests to WordPress front-end paths, admin AJAX endpoints, REST endpoints, or plugin-related routes where query parameters or POST bodies include `exclusion_reason`. Look for SQL keywords, comment markers, encoded metacharacters, database metadata references, or timing functions. Time-based attempts may show repeated requests with `SLEEP()` or `BENCHMARK()` and unusually long response times. Error-based exploitation may produce PHP, MySQL, or WordPress database errors in application logs. If suspicious activity is found, perform database-level review where available for unusual query patterns, access to `information_schema`, or mass reads from WordPress user and options tables. Also review for follow-on activity such as new administrator accounts, unexpected plugin/theme changes, web shells, credential stuffing, or anomalous logins after the suspected SQL injection window.

• exclusion_reason=
• %65%78%63%6c%75%73%69%6f%6e%5f%72%65%61%73%6f%6e
• UNION SELECT
• UNION%20SELECT
• UNION+SELECT
• information_schema
• SLEEP(
• SLEEP%28
• BENCHMARK(
• BENCHMARK%28
• extractvalue(
• extractvalue%28
• updatexml(
• updatexml%28
• @@version
• database()
• database%28%29
• schema_name
• table_name
• column_name
• --+
• #
• %23
• /*
• %2F%2A
• wp_users
• wp_options
• /wp-content/plugins/wp-statistics/
• includes/class-wp-statistics-exclusion.php

What your security team should do

• Prioritize patching or disabling WP Statistics on all internet-facing WordPress sites because exploitation is unauthenticated, low-complexity, and exploit code is available.
• Inventory WordPress installations for WP Statistics versions 13.1.4 and earlier, including plugins installed but not actively used.
• If upgrade cannot be completed immediately, disable the "Record Exclusions" option or remove the plugin as a temporary mitigation.
• Search historical web access logs for `exclusion_reason` requests containing SQL injection syntax, especially `UNION SELECT`, `SLEEP`, `BENCHMARK`, `information_schema`, `extractvalue`, or `updatexml`.
• Investigate any positive detections for possible database disclosure, including enumeration of WordPress user tables and configuration values.
• Rotate exposed secrets and require password resets if logs or forensic findings indicate database extraction may have occurred.
• Deploy or tune WAF signatures for SQL injection attempts against WordPress plugin parameters, but treat WAF controls as compensating only.
• Ensure WordPress database accounts are least-privileged and not reused outside the application.