CVE-2024-8522

What it actually does

CVE-2024-8522 is an unauthenticated SQL injection vulnerability in the LearnPress WordPress LMS plugin affecting versions up to and including 4.2.7. The flaw is in the /wp-json/learnpress/v1/courses REST API endpoint, where the c_only_fields parameter is insufficiently escaped and incorporated into an SQL query without adequate prepared-statement handling. A remote attacker can manipulate this parameter to alter backend SQL queries, potentially extracting sensitive database contents, modifying data, or causing database disruption depending on database permissions and configuration. Because the vulnerable endpoint is exposed through the WordPress REST API and requires no authentication, exploitation can be performed remotely over the network without user interaction.

Why it matters to the business

Organizations using vulnerable LearnPress installations face a high risk of sensitive data exposure, including user records, course data, account metadata, password hashes, email addresses, and other WordPress database contents. Successful exploitation could also undermine site integrity by modifying learning content, user roles, or configuration data, and may disrupt availability if injected queries are used to degrade or damage the database. The CVSS score is critical, EPSS is high at 0.62882, and exploit maturity is listed as weaponized, meaning real-world exploitation is plausible and remediation should be treated as urgent even though the vulnerability is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a WordPress site running the LearnPress plugin and checks whether the public REST API exposes the LearnPress courses endpoint. The attacker then sends crafted HTTP requests to /wp-json/learnpress/v1/courses with malicious SQL syntax embedded in the c_only_fields parameter. Because vulnerable versions do not safely escape or parameterize that value, the injected SQL becomes part of the database query executed by WordPress. The attacker can use boolean-based, error-based, time-based, or UNION-style techniques to confirm injection and enumerate database structure. Once confirmed, the attacker can extract sensitive records from WordPress tables, including user data and plugin-specific learning-management data. Depending on database privileges and environmental hardening, the same flaw may support data modification, account takeover paths through credential/hash theft, creation or alteration of privileged records, or destructive queries intended to affect site availability.

How to fix it

Upgrade the LearnPress WordPress LMS plugin to a version newer than 4.2.7 that contains the vendor’s fix. If an updated safe version is not available through the normal WordPress plugin update channel, disable and remove LearnPress until a patched release can be installed. Restrict access to the vulnerable REST endpoint at the web application firewall, reverse proxy, or WordPress security plugin layer as a temporary mitigation, especially requests to /wp-json/learnpress/v1/courses containing the c_only_fields parameter. Apply least-privilege database permissions for the WordPress database user so that the application account cannot perform unnecessary administrative or destructive operations. Ensure WordPress core, all plugins, and themes are fully updated, and remove unused plugins. Because this flaw can expose password hashes and sensitive user data, consider forced password resets for affected accounts if exploitation is suspected.

How to confirm the fix worked

Confirm the installed LearnPress plugin version is greater than 4.2.7 or that the plugin is disabled/removed. In the WordPress admin console, review the plugin version under Plugins, or inspect the plugin metadata on disk in wp-content/plugins/learnpress/readme.txt or the main plugin file. Validate that unauthenticated requests to /wp-json/learnpress/v1/courses with the c_only_fields parameter no longer result in SQL errors, unusual response differences, or time-delay behavior. Use only safe, non-destructive test payloads in a controlled validation process. Confirm compensating controls block suspicious requests containing SQL metacharacters or SQL keywords in c_only_fields. Review database user privileges to verify the WordPress application account does not have excessive permissions beyond those required for normal site operation.

Typical attack path

1. Identify WordPress sites running the LearnPress LMS plugin.
2. Probe the public WordPress REST API for /wp-json/learnpress/v1/courses.
3. Send test payloads in the c_only_fields query parameter to determine whether SQL syntax is executed.
4. Use boolean, error, time-delay, or UNION-based SQL injection techniques to confirm exploitability.
5. Enumerate database names, table names, columns, and WordPress-specific schema details.
6. Extract sensitive data such as user emails, password hashes, account metadata, course records, and configuration values.
7. Optionally use stolen data to support credential attacks, privilege escalation, account takeover, or further compromise of the WordPress site.
8. Optionally attempt data modification or disruptive database operations if permissions allow.

How to detect it

Review HTTP access logs from web servers, CDNs, WAFs, and reverse proxies for requests to /wp-json/learnpress/v1/courses that include the c_only_fields parameter, especially from unauthenticated clients or unusual geographies, hosting providers, or high-volume scanners. Look for SQL injection payload patterns in the query string such as UNION SELECT, information_schema, sleep(), benchmark(), database(), extractvalue(), updatexml(), quote characters, SQL comments, URL-encoded SQL metacharacters, and time-delay probes. Check WAF logs for SQL injection rule matches involving c_only_fields or the LearnPress REST route. Review WordPress logs and PHP error logs for SQL syntax errors, database errors, or stack traces triggered by the LearnPress courses endpoint. Examine database logs, if enabled, for abnormal SELECTs against wp_users, wp_usermeta, LearnPress tables, information_schema, or repeated failed/erroring queries tied to web requests. Investigate signs of post-exploitation such as new administrator accounts, changed user roles, unexpected plugin or theme files, modified site options, unexplained course/content changes, or unusual authentication activity following suspicious REST API requests. Because weaponized exploitation is reported, absence of WAF blocks alone should not be treated as proof of no compromise; correlate edge logs, origin logs, application logs, and database telemetry over the period since publication.

• /wp-json/learnpress/v1/courses
• c_only_fields=
• /wp-json/learnpress/v1/courses?c_only_fields=
• c_only_fields=*UNION*SELECT*
• c_only_fields=*union*select*
• c_only_fields=*information_schema*
• c_only_fields=*INFORMATION_SCHEMA*
• c_only_fields=*sleep(*
• c_only_fields=*SLEEP(*
• c_only_fields=*benchmark(*
• c_only_fields=*BENCHMARK(*
• c_only_fields=*database()*
• c_only_fields=*user()*
• c_only_fields=*version()*
• c_only_fields=*extractvalue(*
• c_only_fields=*updatexml(*
• c_only_fields=*concat(*
• c_only_fields=*group_concat(*
• c_only_fields=*--*
• c_only_fields=*%2D%2D*
• c_only_fields=*%27*
• c_only_fields=*%22*
• c_only_fields=*%23*
• c_only_fields=*%20or%20*
• c_only_fields=*%20and%20*
• You have an error in your SQL syntax
• WordPress database error
• learnpress/v1/courses
• wp-content/plugins/learnpress/

What your security team should do

• Immediately inventory WordPress sites to identify installations of the LearnPress plugin at version 4.2.7 or earlier.
• Prioritize patching or disabling the plugin because the vulnerability is unauthenticated, remotely exploitable, critical severity, high EPSS, and weaponized.
• Deploy temporary WAF or reverse-proxy rules blocking suspicious c_only_fields parameters on /wp-json/learnpress/v1/courses until all instances are fixed.
• Review web server, CDN, WAF, WordPress, and database logs for exploitation attempts and signs of successful SQL injection.
• If exploitation is suspected, preserve logs and database snapshots before making changes, then conduct incident response triage.
• Rotate WordPress administrator passwords and consider user password resets if database disclosure cannot be ruled out.
• Audit WordPress administrator accounts, newly created users, modified roles, unexpected plugins/themes, and altered site content.
• Harden database permissions for the WordPress application account and remove unused plugins to reduce blast radius.
• Monitor for credential stuffing or account takeover attempts using data potentially extracted from the site.