More than 100,000 WordPress-powered e-learning platforms have a critical remote code execution vulnerability that lets anyone with a free student account take control of the underlying server. The flaw, tracked as CVE-2026-78175, sits in Tutor LMS, a learning management system used by universities, corporate training departments, independent course creators, and membership sites. The CVSS score of 8.8 is high, but the more troubling detail is how little an attacker needs: on any Tutor LMS installation with open student registration, which is the default configuration for most deployments, a valid email address and about sixty seconds are enough to create the subscriber-level account required to trigger the full exploit chain.
Wordfence’s Argus automated research agent identified the vulnerability on August 23, 2026, and the company’s threat intelligence team validated the finding the same day. Wordfence disclosed the details in a report shared with Cyber Security News, and the plugin’s developers shipped a patch in version 4.0.8 on September 10, 2026. The nine days between the patch release and this public disclosure is a meaningful exposure window: unpatched sites remain open to scanning and targeted attacks during that stretch.
Why Tutor LMS installations are exposed
E-learning platforms are built to accept registrations from large numbers of unauthenticated visitors, unlike a standard WordPress blog or brochure site. Students sign up to enroll in courses, instructors register to publish content, and customers create accounts to buy premium material. Because open registration is fundamental to how the plugin works, the “authentication” needed to exploit CVE-2026-78175 amounts to no authentication at all.
Tutor LMS handles course delivery, quizzes, certificates, instructor payouts, and student progress tracking across its install base. Many of these sites store personal information, payment data, proprietary course content, and, for corporate deployments, internal training material. A successful compromise can reach well beyond a defaced homepage into an organization’s entire educational or corporate knowledge base.
The vulnerability targets the plugin’s withdrawal-account feature, which instructors use to configure how they receive payouts. It’s a routine administrative function that happens to process financial details and accept complex structured input from users, and that combination of sensitive data, structured input, and weak access control is what makes the exploit chain below possible.
How the exploit works
The chain behind CVE-2026-78175 runs from PHP object injection to arbitrary file write to remote code execution. It’s worth walking through step by step, both to understand what the patch fixes and to recognize the same pattern in other plugins.
1. Broken access control
The vulnerable AJAX endpoint is registered under the handler name tutor_save_withdraw_account. WordPress’s AJAX handlers process asynchronous browser requests and are accessible to any authenticated user whose session carries a valid nonce, a one-time token WordPress generates to prevent cross-site request forgery. The Tutor LMS developers checked for the nonce but never added a capability or role check. WordPress normally uses current_user_can() to make sure only users with an appropriate role, such as administrator, editor, author, or instructor, can reach sensitive operations. Without that check, a subscriber, the lowest role and the one automatically assigned to new registrants, can call the withdrawal-account handler with full effect.
Getting the nonce is trivial. A logged-in subscriber just loads any page where the token appears in the DOM or a localized JavaScript variable. No social engineering and no interaction with an administrator is required; the token is handed to every authenticated visitor by default.
2. PHP object injection through unsafe deserialization
Once an attacker can reach the handler, they submit crafted input through the withdrawal form fields. Tutor LMS stores withdrawal account data in WordPress user meta and deserializes it using maybe_unserialize() or an equivalent function, without validating the structure or class of the resulting object.
When the attacker submits a serialized PHP object referencing unexpected classes and properties, deserialization instantiates that object inside the application. That’s the core of PHP object injection: the attacker chooses which class gets created and what properties it holds. This class of bug has driven some of the more damaging WordPress plugin takeovers in recent years.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →3. Triggering the gadget chain
Object injection alone doesn’t run code. It needs a “gadget chain,” a sequence of class methods that produce a useful side effect when triggered during object construction, destruction, string conversion, or property access. In this case, the chain runs through a library bundled with Tutor LMS. When the crafted object is deserialized and processed, either by sending the malicious request twice or by having the corrupted withdrawal data read on a later page load, the library’s file-writing function runs with parameters the attacker controls.
The attacker sets both the file path and its content. The library writes it with the web server’s file-system permissions, with no check on whether the path stays inside an expected directory, no restriction on file extension, and no content sanitization.
4. Remote code execution
From there the attack is simple. The attacker writes a PHP script, typically a web shell, into /wp-content/uploads/, which is web-accessible by default under standard Apache and Nginx configurations. A request to the uploaded file’s URL runs the code. At that point the attacker has command execution as the web server user (commonly www-data on Linux), which is enough to read database credentials from configuration files, install backdoors, exfiltrate data, pivot to other hosts on the network, or add the server to a botnet.
Timeline
Wordfence’s Argus agent flagged the vulnerability on August 23, 2026, and the team validated it the same day, following coordinated disclosure with the plugin’s developers. A protective firewall rule went out to premium Wordfence users on August 25, 2026, with free-tier availability scheduled for September 24, 2026. Tutor LMS 4.0.8 shipped on September 10, 2026.
As of this article’s publication, there are no confirmed reports of active exploitation. Researchers caution that this doesn’t mean sites are safe: the vulnerability’s low authentication bar, well-understood exploit class, public CVE, and large install base make it an attractive target for automated scanning. Mass exploitation of WordPress plugin flaws has historically picked up in the gap between disclosure and widespread patching, sometimes within hours of a CVE going public.
What the patch fixes
Tutor LMS 4.0.8 addresses the vulnerability with several layered changes rather than a single fix, which suggests the developers treated the root cause rather than patching around the symptom.
The update adds an instructor-only capability check on the tutor_save_withdraw_account handler, so only users with the tutor_instructor role or higher can reach it, which removes subscriber-level access entirely. It removes the unsafe deserialization step from the data pipeline, so withdrawal data no longer passes through functions that instantiate arbitrary objects from stored strings. It adds strict validation of withdrawal methods, accepting only recognized payment method identifiers. And it restricts accepted field names to an explicit allowlist instead of accepting arbitrary keys from user input, which closes off a whole category of injection attacks built on unexpected parameter names.
What site administrators should do now
Version 4.0.8 fixes the vulnerability, and there’s no configuration workaround that removes the risk without updating.
Update now. Go to the Plugins screen in your WordPress dashboard and update Tutor LMS to 4.0.8 or later. If you manage multiple sites through MainWP, ManageWP, or WP-CLI, push the update across your fleet today rather than waiting for a maintenance window.
Check your registration settings. If your platform serves a closed group, such as employees or enrolled students with institutional credentials, turn off public registration under Settings → General and provision accounts manually or through an invitation flow instead. Fewer easily created accounts means less exposure if another vulnerability turns up later.
Review user accounts. Look for subscriber-role accounts created in the weeks before the patch with no course enrollment, no profile completion, and no activity beyond registration. Remove inactive or suspicious accounts, and check for any elevated-role accounts you don’t recognize.
Check your uploads directory. Look in /wp-content/uploads/ and its subdirectories for PHP files, files with double extensions like image.jpg.php, or files with modification timestamps that don’t line up with legitimate media uploads. Any PHP file in an uploads directory on a properly configured WordPress site is worth investigating as a possible web shell.
Check admin accounts and server logs. Confirm no unauthorized administrator or editor accounts exist. Look through access logs for POST requests to admin-ajax.php with the tutor_save_withdraw_account action from IPs or user agents that don’t match known instructors, and for GET requests to unusual uploads paths afterward, which would suggest an attacker testing a planted shell.
Update WordPress core. This bug lives in a plugin, but outdated core adds attack surface of its own. The most recent core release fixed eleven additional vulnerabilities.
Turn on a WAF rule if you have one. If you use Wordfence, Sucuri, Cloudflare, or another WAF, confirm the CVE-2026-78175 rule is active (Wordfence’s premium rule shipped August 25; free-tier availability is scheduled for September 24). Treat a WAF rule as a detection and blocking layer, not a substitute for updating the plugin, since signatures can be bypassed and don’t fix the underlying code.
Secure your backups. Make sure backups aren’t stored in web-accessible locations. An attacker who gets server access through this vulnerability could reach backup archives containing full database dumps, so store backups off-site, encrypt them at rest, and restrict access to backup management interfaces.
PHP object injection in WordPress plugins, more broadly
This isn’t an isolated case. PHP object injection through unsafe deserialization has shown up repeatedly in WordPress plugins for more than a decade. The underlying tension is architectural: plugins often need to store complex structured data, and PHP’s native serialize()/unserialize() functions are the easiest way to do it. But calling unserialize() on untrusted data triggers object instantiation and magic method calls without any developer oversight, which is inherently risky.
WordPress core’s maybe_serialize() and maybe_unserialize() helpers handle the case where data may or may not already be serialized, but they don’t prevent class instantiation. A plugin that stores user-supplied data in serialized form and later deserializes it without validating the resulting object remains vulnerable. OWASP has long listed insecure deserialization among its top web application risks, and much of the PHP community now favors JSON storage or schema-validated serialization instead.
For plugin developers, the takeaway is straightforward: don’t deserialize data that user input could influence without strict type validation, use JSON for structured data where you can, add capability checks to every AJAX handler and REST endpoint, validate field names and values against an explicit schema, and block PHP execution in the uploads directory at the web server level.
What this means for e-learning platforms
Online learning platforms have become fairly central infrastructure for schools, corporate training programs, and independent creators, and they often handle data subject to FERPA, GDPR, and other compliance rules. A remote code execution vulnerability affecting more than 100,000 active installations is a compliance concern and a potential breach trigger, not just a technical annoyance.
Platforms that process payments, store assessment records, host proprietary course content, or manage instructor payouts carry the most risk here. Code execution through CVE-2026-78175 could let an attacker read wp-config.php for database credentials, dump the database, install a backdoor that survives plugin updates, or use the server to move laterally into other infrastructure.
If you run Tutor LMS in production, it’s a reasonable prompt to review your broader security posture: check whether your hosting environment limits the web server user’s write access to only the directories it needs, confirm PHP execution is disabled in upload paths, look for other installed plugins that accept serialized user input, and make sure your incident response plan covers WordPress compromise specifically, including indicators of compromise, forensic preservation, and any notification obligations under applicable data protection law.
Bottom line
CVE-2026-78175 combines a missing access control check with PHP object injection and arbitrary file write, and it’s made worse by the fact that open registration is the default, not an edge case, for Tutor LMS deployments. The 4.0.8 patch addresses the issue at several layers, but it only helps if administrators apply it. The nine-day gap between the patch and this disclosure is exactly the window attackers tend to exploit.
If you run Tutor LMS, update to 4.0.8 now. If you manage sites at scale, confirm your update automation actually covers this plugin.
