Tutor LMS CVE-2026-78175: Update to 4.0.8 to Block Subscriber-Level RCE
Tutor LMS 4.0.7 and earlier contain a high-severity PHP object-injection vulnerability that can allow an authenticated attacker with Subscriber-level access to execute code on the WordPress server. The flaw, CVE-2026-78175, carries a CVSS 3.1 score of 8.8 and is fixed in Tutor LMS 4.0.8, released September 10, 2026.
The authentication requirement can be a low barrier on learning sites. Tutor LMS is designed for student enrollment, and Wordfence reports that most installations enable open registration by default. A visitor who can self-register as a student can therefore obtain the low-privilege account needed to reach the vulnerable code path. The affected path also requires Tutor LMS's monetization functionality.
Wordfence disclosed the issue publicly on September 17 after its Argus research system identified the vulnerability on August 23 and the Wordfence Threat Intelligence team validated it. Wordfence says Tutor LMS is active on more than 100,000 WordPress sites. Administrators running affected versions should update to 4.0.8 or later.
Tutor LMS CVE-2026-78175 at a glance
| Item | Detail |
|---|---|
| CVE | CVE-2026-78175 |
| Severity | High, CVSS 3.1 8.8 |
| Affected versions | Tutor LMS 4.0.7 and earlier |
| Fixed version | Tutor LMS 4.0.8 |
| Required privilege | Subscriber or higher |
| User interaction | None |
| Main impact | PHP object injection leading to remote code execution |
| Important exposure condition | Monetization functionality enabled; open registration can let a visitor obtain the required account |
| Patch release | September 10, 2026 |
The primary advisory is Wordfence's CVE-2026-78175 technical analysis. The current Tutor LMS WordPress.org listing describes the plugin's monetization, withdrawal and registration capabilities.
How the vulnerability reaches remote code execution
The vulnerable code sits in the tutor_save_withdraw_account AJAX handler used for withdrawal-account settings. Wordfence found that the handler is registered for authenticated requests and checks a nonce, but affected versions lack a capability or role check restricting the function to instructors.
A logged-in Subscriber can obtain the required Tutor LMS nonce from the front end. On a site that permits open student registration, an outside visitor can first create a low-privilege account and then reach the same handler.
The code processes attacker-controlled withdrawal data with esc_sql() before storing it through WordPress user metadata. WordPress's placeholder handling for percent characters can change the stored byte length after PHP has serialized the data. That creates a mismatch between a serialized string's declared length and its actual stored length.
When the metadata is read and passed through PHP deserialization, the parser can over-read into attacker-controlled data. Wordfence demonstrated that the resulting object injection can load Tutor LMS's bundled PayPal Composer dependencies and instantiate Guzzle's FileCookieJar class. Its destructor can then write attacker-controlled content to a chosen file path, including a PHP file under a web-accessible uploads directory. Requesting that file completes the remote-code-execution chain under the web server account.
The corrupted metadata can be deserialized on a second crafted request, so exploitation does not require an instructor to visit the affected account after the payload has been stored.
What Tutor LMS 4.0.8 changes
Version 4.0.8 addresses several parts of the chain. The patched withdrawal-account handler checks that the current user is an instructor before processing settings. It also removes the problematic esc_sql() use from this storage path and applies field-appropriate sanitization after wp_unslash().
The patch additionally changes field handling from attacker-supplied array keys to the withdrawal method's declared form fields and validates the selected withdrawal method before processing its data. These changes close the low-privilege entry point and the serialization/key-injection primitives used in the demonstrated chain.
For administrators, the version boundary is straightforward: 4.0.8 or later is the remediation target. Updating the plugin is preferable to relying on registration restrictions alone because existing Subscriber accounts can satisfy the vulnerability's privilege requirement on an affected installation.
What administrators should check
Start by inventorying every WordPress installation that runs Tutor LMS and record its plugin version. Upgrade any installation on 4.0.7 or earlier to 4.0.8 or a later supported release.
Sites that cannot update immediately should reduce the reachable attack surface by reviewing whether public student registration and the affected monetization/withdrawal functionality are required. Those controls can raise the exploitation barrier, but the plugin update provides the code-level fix.
Administrators that operated an affected version should also review recent account creation, unexpected changes to Tutor LMS withdrawal settings, suspicious PHP files or other unusual files under wp-content/uploads, unexpected administrator accounts, and relevant web-server/PHP logs. These checks are particularly useful for sites with open student registration and monetization enabled.
Wordfence says Premium, Care and Response customers received its firewall rule on August 25, 2026. The same rule is scheduled for the free Wordfence tier on September 24, 2026. A WAF rule adds protection, while upgrading Tutor LMS removes the vulnerable application path.
Exploitation status and practical priority
The reviewed Wordfence disclosure documents the exploit chain and patch but does not report confirmed exploitation in the wild. CVE-2026-78175 also requires a low-privilege authenticated account and the relevant Tutor LMS monetization path, so exposure depends on site configuration.
The combination of remote code execution, a Subscriber-level privilege requirement and common open-registration deployments makes 4.0.8 a high-priority update for Tutor LMS operators. Sites that allow public student registration should treat the account requirement as a limited barrier and patch the plugin rather than depending on registration controls as the long-term mitigation.