CVE-2024-10400

What it actually does

The Tutor LMS WordPress plugin contains an unauthenticated SQL injection vulnerability in the rating_filter parameter in versions up to and including 2.7.6. Because user-controlled input is insufficiently escaped and not safely parameterized before being incorporated into a SQL query, an attacker can alter the intended database query. Practical impact includes extraction of sensitive WordPress database content such as user records, password hashes, email addresses, course/order-related data, plugin data, and other information accessible to the database user. Depending on database permissions and site configuration, attackers may also be able to enumerate schema details and automate data extraction using blind or time-based SQL injection techniques.

Why it matters to the business

A vulnerable public WordPress site running Tutor LMS can expose sensitive learner, administrator, and business data without requiring attacker authentication. Successful exploitation can lead to privacy incidents, credential compromise through stolen password hashes, reputational damage, regulatory notification obligations, and potential follow-on compromise of administrator accounts or other connected systems. The high EPSS score and weaponized exploit maturity indicate a materially elevated likelihood of opportunistic internet-scale scanning and exploitation, even though the vulnerability is not currently listed in CISA KEV.

How an attack unfolds

An attacker identifies a WordPress site using the Tutor LMS plugin and determines that the installed version is 2.7.6 or earlier. The attacker then sends crafted HTTP requests to a Tutor LMS-facing page or endpoint that accepts the rating_filter parameter. By inserting SQL syntax into that parameter, the attacker modifies the backend query generated by the plugin. Initial payloads commonly test for SQL errors, boolean differences, or time delays using functions such as SLEEP() or BENCHMARK(). Once injection is confirmed, the attacker enumerates database metadata, identifies WordPress tables and plugin-specific tables, and extracts sensitive data using UNION-based, error-based, boolean-based, or time-based techniques. Extracted data may then be used for credential cracking, administrator account takeover, phishing, fraud, or resale.

How to fix it

Upgrade Tutor LMS to a version later than 2.7.6 that contains the vendor fix; if an exact fixed version is not available in asset data, install the latest available Tutor LMS release from the official WordPress plugin repository or vendor channel and verify the changelog references the SQL injection fix for this issue. If immediate upgrade is not possible, temporarily disable the Tutor LMS plugin, restrict public access to affected Tutor LMS pages, and deploy web application firewall rules that block SQL injection payloads in the rating_filter parameter. Ensure the WordPress database user follows least privilege and does not have unnecessary administrative database permissions. After patching, rotate credentials for accounts that may have been exposed if exploitation is suspected, especially administrator and privileged user accounts.

How to confirm the fix worked

Confirm the installed Tutor LMS version is newer than 2.7.6 through the WordPress admin plugin page, filesystem plugin metadata, or WP-CLI. Validate that public pages or endpoints using rating_filter no longer produce SQL errors, response-based query manipulation, or time-delay behavior when supplied with benign SQL injection test strings. Review WAF, CDN, reverse proxy, and web server logs to ensure attempted rating_filter injection payloads are blocked or safely handled. Run an authenticated vulnerability scan or plugin inventory across WordPress assets to confirm no remaining installations are at or below version 2.7.6.

Typical attack path

1. Scan the internet for WordPress sites using Tutor LMS.
2. Fingerprint the plugin version or infer exposure based on vulnerable behavior.
3. Send crafted unauthenticated requests containing SQL metacharacters in the rating_filter parameter.
4. Confirm injection using database errors, response differences, or time delays.
5. Enumerate database schema, table names, and column names.
6. Extract sensitive WordPress and Tutor LMS data such as users, password hashes, emails, and course-related records.
7. Use stolen credentials or password hashes for account takeover or broader follow-on attacks.
8. Cover tracks by blending requests into normal web traffic or rotating source IP addresses.

How to detect it

Review HTTP access logs, WAF logs, CDN logs, reverse proxy logs, and WordPress security plugin logs for unauthenticated requests containing the rating_filter parameter with SQL syntax, encoded SQL keywords, comment markers, quote characters, or time-delay functions. Focus on requests to Tutor LMS course, archive, search, or filtering pages that include rating_filter and produce 500 errors, database error messages, unusually long response times, or abnormal response sizes. Look for repeated parameter testing from the same source, sequential boolean probes, UNION SELECT attempts, information_schema enumeration, and time-based probes using SLEEP() or BENCHMARK(). Correlate suspicious requests with database logs, if available, for unexpected SELECT statements against WordPress user tables, schema enumeration queries, or long-running queries. In WordPress application evidence, investigate unexpected administrator logins, new users, password reset activity, plugin/theme modifications, and outbound data transfer following suspicious requests. Because exploitation may be blind and leave no application-level artifact beyond web requests, absence of SQL errors does not rule out compromise.

• rating_filter=
• rating_filter=%27
• rating_filter='
• rating_filter=%22
• rating_filter="
• rating_filter%5B
• UNION SELECT
• union%20select
• UNION%20SELECT
• information_schema
• information_schema.tables
• information_schema.columns
• SLEEP(
• sleep(
• SLEEP%28
• BENCHMARK(
• benchmark(
• BENCHMARK%28
• @@version
• database()
• user()
• concat(
• group_concat(
• --+
• %2D%2D%2B
• #
• %23
• /*
• %2F%2A
• */
• %2A%2F
• wp-content/plugins/tutor/
• wp_tutor
• wp_users
• tutor-lms

What your security team should do

• Prioritize patching all internet-facing WordPress sites running Tutor LMS version 2.7.6 or earlier because exploit code is weaponized and EPSS is high.
• Inventory WordPress installations for Tutor LMS usage, including inactive plugin directories that may still expose files or indicate outdated deployments.
• Upgrade Tutor LMS to the latest vendor release and verify the installed version is greater than 2.7.6.
• Add or tune WAF/SIEM detections for SQL injection attempts targeting the rating_filter parameter.
• Review historical web, WAF, CDN, and application logs for suspicious rating_filter requests since public disclosure and especially recent scanning windows.
• If exploitation is suspected, preserve logs, dump relevant forensic artifacts, and assess whether WordPress user data or password hashes were accessed.
• Force password resets and rotate privileged credentials if database extraction cannot be ruled out.
• Harden WordPress by removing unused plugins, limiting database privileges, enforcing MFA for administrators, and monitoring for new administrator accounts or unexpected plugin/theme modifications.