CVE-2023-6063

What it actually does

WP Fastest Cache versions before 1.2.2 fail to properly sanitize and escape attacker-controlled input before including it in a SQL query. Because the vulnerable code path is reachable without authentication over the network, an attacker can perform unauthenticated SQL injection against the WordPress database. The CVSS vector indicates high confidentiality impact with no required privileges or user interaction; practical exploitation is commonly blind or time-based SQL injection used to extract data such as usernames, password hashes, email addresses, session-related values, plugin configuration, and other WordPress database contents.

Why it matters to the business

A successful attack can expose sensitive website and user data from the WordPress database, potentially enabling account takeover, credential reuse attacks, privacy incidents, regulatory notification obligations, and reputational harm. The vulnerability has a high EPSS score and is assessed as weaponized, meaning exploitation is likely in broad internet scanning even though it is not currently listed in CISA KEV. Public WordPress sites using affected WP Fastest Cache versions should be treated as high-priority remediation targets.

How an attack unfolds

An attacker first identifies a WordPress site running the WP Fastest Cache plugin. They then send crafted unauthenticated HTTP requests containing SQL syntax in input consumed by the plugin, commonly in cookie-derived values associated with WordPress login state. The plugin inserts the unsanitized value into a database query, allowing the attacker to alter the query logic. In many real-world scenarios the attacker uses blind or time-based payloads such as conditional expressions, SLEEP, or BENCHMARK to confirm injection, then automates extraction of database contents one character or field at a time. The extracted information may include WordPress user records and password hashes, which can then be cracked offline or used to support further intrusion attempts.

How to fix it

Upgrade WP Fastest Cache to version 1.2.2 or later immediately. If the plugin cannot be upgraded promptly, disable and remove it until remediation is possible. Apply compensating controls at the web application firewall or reverse proxy layer to block SQL injection payloads in Cookie headers and other request fields, but do not treat filtering as a substitute for patching. Ensure WordPress core, themes, and all other plugins are fully updated. After patching, rotate credentials for privileged WordPress accounts if exploitation is suspected, force password resets where appropriate, and review database users and WordPress administrator accounts for unauthorized changes.

How to confirm the fix worked

Confirm the installed WP Fastest Cache plugin version is 1.2.2 or later from the WordPress admin plugin inventory, filesystem plugin metadata, or command-line tooling such as WP-CLI. Check that no older plugin copy remains under the WordPress plugins directory. Validate that external vulnerability scanners no longer report CVE-2023-6063 or WP Fastest Cache SQL injection exposure. If using a WAF, confirm rules inspect Cookie headers as well as URL parameters and request bodies. Review web server access logs after patching to ensure similar malicious requests are blocked or no longer produce abnormal response timing.

Typical attack path

1. Scan internet-facing WordPress sites for evidence of the WP Fastest Cache plugin.
2. Confirm the target is running a vulnerable version before 1.2.2 or test for injectable behavior directly.
3. Send unauthenticated HTTP requests with crafted SQL payloads in plugin-processed input, often cookie values.
4. Use boolean-based or time-based responses to verify SQL injection.
5. Automate database enumeration and extract sensitive WordPress tables such as users and options.
6. Use recovered usernames, email addresses, password hashes, or configuration data to support account takeover, phishing, or follow-on compromise.

How to detect it

Investigate web server access logs, CDN logs, WAF logs, reverse proxy logs, and application security telemetry for unauthenticated requests containing SQL injection syntax in Cookie headers, especially cookies beginning with wordpress_logged_in_. Look for time-based payloads using SLEEP, BENCHMARK, WAITFOR, pg_sleep, conditional SQL functions, UNION SELECT, information_schema, or encoded equivalents. Correlate suspicious requests with unusual response latency, repeated requests that vary one character or number at a time, HTTP 500 errors, database errors, or spikes from single source IPs. Review database logs, if enabled, for anomalous SELECT statements against WordPress tables such as users, usermeta, and options. On the host, inspect WordPress administrator accounts, plugin and theme directories, recently modified PHP files, and unexpected scheduled tasks or web shells, because SQL injection data exposure may be followed by credential-based access or post-exploitation changes.

• Cookie: wordpress_logged_in_
• wordpress_logged_in_%
• wordpress_logged_in_.*SLEEP(
• wordpress_logged_in_.*BENCHMARK(
• wordpress_logged_in_.*UNION SELECT
• wordpress_logged_in_.*information_schema
• wordpress_logged_in_.*concat(
• wordpress_logged_in_.*extractvalue(
• wordpress_logged_in_.*updatexml(
• wordpress_logged_in_.*%27
• wordpress_logged_in_.*--
• wordpress_logged_in_.*%23
• SLEEP(
• BENCHMARK(
• UNION SELECT
• information_schema.tables
• information_schema.columns
• /wp-content/plugins/wp-fastest-cache/
• wpFastestCache
• wp-fastest-cache

What your security team should do

• Immediately inventory WordPress installations for WP Fastest Cache and prioritize any version before 1.2.2 for upgrade or removal.
• Because the exploit is weaponized and EPSS is high, treat internet-facing vulnerable sites as likely scanned and possibly probed.
• Search historical web access logs, WAF logs, CDN logs, and reverse proxy logs for SQL injection payloads in Cookie headers, especially WordPress logged-in cookie names.
• If suspicious activity is found, preserve logs and image relevant web and database artifacts before cleanup.
• Review WordPress administrator accounts, recently created users, modified plugin/theme files, and unusual database changes.
• Rotate WordPress administrator passwords and consider forced password resets if user table extraction is suspected.
• Add or tune WAF detections for SQL keywords and time-based SQL injection functions in Cookie headers.
• Monitor for credential stuffing or login attempts against accounts whose usernames or email addresses may have been exposed.