CVE-2024-1512

What it actually does

The MasterStudy LMS WordPress plugin is vulnerable to unauthenticated union-based SQL injection in the `user` parameter of the `/lms/stm-lms/order/items` REST API route. Because user-supplied input is not properly escaped or parameterized before being incorporated into a SQL query, a remote attacker can alter the intended query logic and use UNION-based payloads to retrieve arbitrary database contents. In a WordPress context, this can expose user records, password hashes, administrator emails, session-related data, plugin data, course/order information, and other sensitive content stored in the same database. Depending on database privileges and configuration, SQL injection may also enable data modification or deletion, though the primary documented impact is sensitive data extraction.

Why it matters to the business

Successful exploitation can lead to theft of learner, instructor, customer, and administrator data from affected WordPress education sites. Compromise of WordPress user data may enable account takeover, credential attacks against other services, privacy incidents, regulatory notification obligations, reputational damage, and operational disruption. The high CVSS score, high EPSS probability, unauthenticated network exploitability, and weaponized exploit maturity make this a high-priority issue for any site running the affected plugin, even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker scans WordPress sites for the MasterStudy LMS plugin and probes the public REST endpoint `/lms/stm-lms/order/items`. The attacker sends crafted HTTP requests containing SQL syntax in the `user` parameter, typically using UNION SELECT techniques to determine the number and type of columns in the original query. After aligning the UNION payload with the query structure, the attacker extracts database values such as WordPress usernames, email addresses, password hashes, roles, plugin records, order data, or other sensitive tables. Because exploitation requires no authentication or user interaction, attacks can be automated at scale. If useful credentials or password hashes are recovered, the attacker may attempt offline cracking, credential stuffing, administrator login, persistence through plugin/theme modification, or further compromise of the hosting environment.

How to fix it

Upgrade the MasterStudy LMS WordPress plugin to a vendor-fixed release newer than 3.2.5, or the latest available version from the official WordPress plugin repository or vendor distribution channel. Because the supplied fixed-version list is empty, treat all versions up to and including 3.2.5 as vulnerable and verify the vendor changelog for the first patched release before redeployment. If immediate upgrade is not possible, disable or remove the plugin until patched. As temporary compensating controls, restrict access to the affected REST route using a WAF or reverse proxy rule, block suspicious requests containing SQL metacharacters or UNION SELECT patterns in the `user` parameter, ensure database accounts used by WordPress have least-privilege permissions, and review whether sensitive data stored in WordPress should be rotated or invalidated after suspected exposure.

How to confirm the fix worked

Confirm the installed MasterStudy LMS plugin version is greater than 3.2.5 and matches a vendor release that explicitly fixes the SQL injection issue. In WordPress, review the plugin version from the admin dashboard, plugin files, WP-CLI, or package inventory. Validate that unauthenticated requests to the affected route no longer allow SQL syntax in the `user` parameter to alter responses. A safe validation should use non-destructive test strings and be performed only in authorized environments. Review WAF, web server, and WordPress REST API logs to confirm that requests to `/lms/stm-lms/order/items` are either blocked, sanitized, or no longer produce abnormal responses. Where possible, run a credentialed vulnerability scanner or WordPress security scanner that checks plugin versions and known vulnerable endpoints.

Typical attack path

1. Identify WordPress sites running the MasterStudy LMS plugin or probe common WordPress REST API routes.
2. Send unauthenticated requests to `/wp-json/lms/stm-lms/order/items` or related REST paths using the `user` parameter.
3. Inject SQL syntax into the `user` parameter to test for query manipulation and database error or timing/content differences.
4. Use UNION-based payloads to determine the query column count and compatible data types.
5. Extract sensitive database contents such as WordPress users, emails, password hashes, roles, LMS orders, or course-related records.
6. Use recovered data for credential cracking, phishing, account takeover, or additional intrusion attempts.
7. If administrator access is obtained, install malicious plugins, modify themes, create persistence, or exfiltrate additional data.

How to detect it

Review HTTP access logs, CDN logs, WAF events, WordPress security plugin logs, and application logs for unauthenticated requests to the MasterStudy LMS REST order-items endpoint containing SQL injection syntax in the `user` parameter. Focus on requests to `/wp-json/lms/stm-lms/order/items` or `/lms/stm-lms/order/items` with payloads containing `UNION`, `SELECT`, SQL comments, quote characters, encoded SQL keywords, column-count probing, or references to WordPress database tables such as `wp_users` and `wp_usermeta`. Investigate repeated 200, 400, 500, or unusually large responses from this endpoint, as extraction may produce abnormal response sizes. Correlate suspicious requests with subsequent WordPress login attempts, password reset requests, new administrator account creation, plugin installation, theme editor activity, or unexpected file modifications. On the host, review WordPress audit logs, web server logs, PHP error logs, database slow/query logs if enabled, and filesystem changes under WordPress plugin, theme, and upload directories. If logs show successful-looking SQL injection probes or data extraction patterns, perform incident response under the assumption that database contents may have been exposed.

• /wp-json/lms/stm-lms/order/items
• /lms/stm-lms/order/items
• user=
• user=%27
• user='
• user=%22
• user="
• user=0 UNION SELECT
• user=1 UNION SELECT
• user=-1 UNION SELECT
• UNION SELECT
• UNION ALL SELECT
• union%20select
• union+select
• UNION/**/SELECT
• ORDER BY
• order%20by
• information_schema
• information_schema.tables
• information_schema.columns
• wp_users
• wp_usermeta
• user_login
• user_pass
• group_concat
• concat(
• concat%28
• database()
• database%28%29
• version()
• version%28%29
• @@version
• -- -
• #
• %23
• /*
• */
• SLEEP(
• sleep%28
• BENCHMARK(
• benchmark%28

What your security team should do

• Immediately inventory externally reachable WordPress sites for the MasterStudy LMS plugin and identify versions up to and including 3.2.5.
• Upgrade affected installations to a vendor-fixed release newer than 3.2.5 or the latest available plugin version; disable the plugin where timely patching is not possible.
• Add WAF or reverse proxy controls to block unauthenticated SQL injection attempts against `/wp-json/lms/stm-lms/order/items` and the `user` parameter.
• Search historical web, WAF, CDN, and application logs for exploitation attempts, especially UNION SELECT payloads targeting the LMS order items route.
• If exploitation is suspected, assume database disclosure is possible: rotate WordPress administrator passwords, invalidate active sessions, review user accounts, and assess whether password hashes or personal data were exposed.
• Check for post-exploitation activity such as newly created administrator users, unexpected plugins, modified theme files, web shells, or outbound data transfer.
• Ensure WordPress database users follow least privilege and do not have unnecessary administrative database permissions.
• Increase monitoring for credential stuffing or administrator login attempts following any suspected data exposure.