CVE-2023-6567

What it actually does

This vulnerability is an unauthenticated time-based SQL injection in the LearnPress WordPress plugin through the user-controlled order_by parameter in versions up to and including 4.2.5.7. Because the parameter is insufficiently escaped and not safely prepared before being inserted into a SQL query, an attacker can manipulate the database query logic. Time-based SQL injection allows an attacker to infer database contents by observing response delays, and in practical exploitation may enable extraction of WordPress user data, password hashes, email addresses, course/enrollment records, configuration values, session-related data, or other sensitive information stored in the WordPress database. Depending on database privileges and site configuration, the issue may also support data tampering or application disruption.

Why it matters to the business

A compromised LearnPress site can expose learner, instructor, administrator, and course-related data, potentially creating privacy, regulatory, fraud, and reputational consequences. Because exploitation is unauthenticated, network-accessible WordPress sites using vulnerable LearnPress versions can be attacked without a valid account. The high CVSS score, weaponized exploit maturity, and elevated EPSS score indicate meaningful real-world exploitation likelihood, so internet-facing sites should be treated as high-priority remediation targets. The supplied Linux kernel package fixed-version data appears unrelated to the described WordPress plugin SQL injection and should not be relied on as remediation for this issue without confirming a separate advisory.

How an attack unfolds

An attacker first identifies a WordPress site using the LearnPress plugin, often by checking public plugin assets, page markup, REST/AJAX behavior, or known LearnPress URL patterns. The attacker then sends crafted HTTP requests containing a malicious order_by parameter to a LearnPress-controlled endpoint or page that builds a database query from that parameter. By injecting SQL expressions that intentionally delay the database response, such as time-delay functions, the attacker confirms the injection point without needing authentication. After confirmation, the attacker repeatedly varies the injected condition and measures response times to infer database values one bit or character at a time. This can be automated to enumerate table names, extract user records, recover password hashes, or identify administrative accounts. If the attacker obtains usable credentials or cracks password hashes, the campaign may progress to WordPress administrator access, plugin/theme modification, web shell placement, spam/SEO abuse, payment or learner-data theft, or full site takeover.

How to fix it

Upgrade the LearnPress WordPress plugin to a vendor-fixed version newer than 4.2.5.7 as soon as possible. If an immediate upgrade is not possible, temporarily disable LearnPress or restrict access to affected LearnPress functionality until the plugin can be updated. Apply WordPress core, theme, and plugin updates to reduce chained-compromise risk. Ensure the WordPress database account follows least privilege and does not have unnecessary administrative permissions. Add temporary WAF or reverse-proxy rules to block suspicious order_by parameter values containing SQL metacharacters, comments, time-delay functions, UNION queries, or references to information_schema. Review and remove any unauthorized WordPress administrator users, unknown plugins, modified theme files, or unexpected PHP files after remediation. Do not treat the listed Debian/Ubuntu/Linux kernel fixed versions as fixing this LearnPress vulnerability unless validated against an authoritative advisory for a different issue.

How to confirm the fix worked

Confirm the installed LearnPress plugin is upgraded beyond 4.2.5.7 across all WordPress deployments and that no cached or copied vulnerable plugin code remains accessible. Use wp-cli, WordPress admin plugin inventory, filesystem checks, or software composition scanning to verify the active plugin version. Re-test affected LearnPress pages and endpoints with malformed order_by values and ensure they are rejected or normalized rather than changing query behavior or causing measurable delay. Review WAF/CDN/access logs after the upgrade to confirm exploit attempts are blocked or no longer produce delayed responses. If exploitation was suspected, validate recovery by checking for unauthorized users, modified files, suspicious plugins, unexpected scheduled tasks, and database integrity before returning the site to normal operation.

Typical attack path

1. Scan the internet or targeted domains for WordPress sites using LearnPress assets or LearnPress-specific behavior.
2. Identify pages or endpoints that accept the vulnerable order_by parameter.
3. Send benign and malformed order_by values to observe SQL errors, behavioral differences, or timing changes.
4. Submit time-delay SQL payloads and compare response latency to confirm blind SQL injection.
5. Automate conditional time-based queries to enumerate database schema and extract sensitive values.
6. Use extracted data, such as password hashes, emails, salts, or configuration values, to support account takeover or further compromise.
7. If administrative access is obtained, modify WordPress plugins/themes, upload malicious code, create backdoor accounts, or exfiltrate additional data.
8. Cover tracks by deleting logs, blending requests with normal traffic, or throttling extraction to avoid detection.

How to detect it

Look for evidence in HTTP access logs, WordPress application logs, WAF/CDN logs, reverse-proxy logs, database slow-query logs, and endpoint file-integrity telemetry. Focus on unauthenticated requests to WordPress or LearnPress pages containing the order_by parameter with SQL syntax, encoded SQL metacharacters, time-delay functions, comments, UNION queries, or references to system database tables. Time-based SQL injection often appears as many repeated requests with small parameter changes and unusually long response times, frequently returning otherwise normal HTTP status codes. Correlate spikes in slow database queries with web requests containing order_by. Review WordPress audit logs for new administrator users, password resets, plugin/theme edits, plugin uploads, and suspicious logins after the first observed probing. On the host, look for recently modified PHP files under WordPress plugin, theme, uploads, mu-plugins, and cache directories. If database logs are available, search for SLEEP, BENCHMARK, information_schema, conditional expressions, and unusual SELECT statements originating from the WordPress database user.

• order_by=
• order_by%3D
• order_by%5B
• SLEEP(
• sleep%28
• BENCHMARK(
• benchmark%28
• INFORMATION_SCHEMA
• information_schema
• UNION SELECT
• union%20select
• UNION%2f%2a
• --+
• %2d%2d%2b
• %23
• /*
• %2f%2a
• */
• %2a%2f
• EXTRACTVALUE(
• extractvalue%28
• UPDATEXML(
• updatexml%28
• IF(
• if%28
• CASE WHEN
• case%20when
• /wp-content/plugins/learnpress/
• /wp-admin/admin-ajax.php
• /wp-json/
• wp_learnpress
• wp_users
• wp_usermeta

What your security team should do

• Prioritize internet-facing WordPress sites using LearnPress because exploitation is unauthenticated, weaponized, and has a high EPSS score.
• Inventory all WordPress installations and identify LearnPress versions at or below 4.2.5.7.
• Upgrade LearnPress to a fixed release newer than 4.2.5.7 or disable the plugin until an upgrade is complete.
• Deploy temporary WAF detections for SQL injection patterns in the order_by parameter while patching is underway.
• Search historical access logs, CDN logs, WAF logs, and application logs for time-based SQL injection attempts against LearnPress endpoints.
• Reset passwords for WordPress administrators and other privileged users if exploitation is suspected, especially where password hashes may have been exposed.
• Review WordPress administrator accounts, plugin/theme changes, uploaded PHP files, scheduled tasks, and database user privileges for persistence.
• Preserve relevant logs before rotation if suspicious activity is found, because time-based extraction may occur slowly over many requests.
• Validate that remediation is plugin-specific; investigate the unrelated Linux fixed-version metadata separately rather than assuming it addresses this issue.