WP Learn Manager Flaw: Unpatched WordPress Plugin Vulnerability
By WP Vanguard Team
On July 7, 2026, researchers disclosed CVE-2026-12153, a missing authorization flaw in WP Learn Manager affecting every version up to and including 1.1.8. The CVSS score is 9.8, critical, unauthenticated, network-exploitable. There's no patched version. There won't be one either: WordPress.org closed the plugin's listing on June 30, 2026, a week before the CVE became public, citing a security issue.
That closure date matters more than it looks. A closed plugin stops appearing in the WordPress.org directory and stops offering updates through the normal dashboard flow. It does not get removed from any site that already has it installed. If you installed WP Learn Manager last year, the vulnerable code is still sitting in your wp-content/plugins/ folder right now, waiting for an update that will never arrive, because there's nowhere left for one to come from.
What makes this flaw unusual isn't the severity score. Plenty of plugin bugs hit 9.8. It's the capability an attacker gets: not a file upload, not a password reset, not a database dump. The flaw lets an unauthenticated visitor tell the site to install and activate any plugin from the official WordPress.org repository. That's a strange thing to hand out for free, and it's more dangerous than it first sounds.
How the flaw works
The vulnerable code lives behind the jslearnmanager_ajax AJAX action. WordPress's AJAX system routes requests through admin-ajax.php, and plugins register handlers for specific actions using hooks like wp_ajax_{action} for logged-in users and wp_ajax_nopriv_{action} for anyone, logged in or not. WP Learn Manager registered a handler for jslearnmanager_ajax that branches on a sub-action parameter to decide what to do, and one of those branches calls into WordPress's plugin installer.
The problem is what's missing before that call happens. A correctly built handler checks the current user's capability, typically install_plugins, before touching the installer API. WP Learn Manager's handler doesn't verify that the requester is authorized to install anything at all. It just does the install. Because the action was also wired to wp_ajax_nopriv_jslearnmanager_ajax, that missing check is reachable by a request with no session, no cookie, and no login.
Once the request reaches the installer, WordPress does exactly what it's designed to do: it pulls the requested plugin slug from the official repository, downloads it, and can activate it. There's no malware signature to catch here, because nothing malicious gets uploaded. The payload is a real, signed, legitimately hosted WordPress plugin. Antivirus and file-integrity scanners built to flag unexpected PHP files won't blink, because the files match exactly what's published on WordPress.org.
Who is affected
Every site running WP Learn Manager 1.1.8 or earlier is affected, with no configuration required to be exploitable. The attack vector is network, the access level required is none, and user interaction is not needed, which is what pushes the CVSS score to 9.8. There's no setting that turns this off and no role restriction that narrows it, because the check that should have gated the request was never written in the first place.
The install target isn't limited to a fixed list. An attacker can request any plugin available in the WordPress.org repository, install it, and in many configurations activate it in the same request. That turns the vulnerability into a menu rather than a single exploit.
When there's no patch, what an attacker actually does
Think about what's sitting in the WordPress.org repository already. File manager plugins that let you browse, edit, and upload files through the WordPress admin. Code snippet runners built to execute arbitrary PHP from a text box. User management plugins that can create new administrator accounts. Database export and backup tools that will happily zip up your entire wp_options and wp_users tables and hand them back as a download link.
None of that is malware. Every one of those plugins does exactly what it says on its listing page, and thousands of legitimate site owners install them on purpose every day. That's precisely why this vulnerability class is worth taking seriously: the attacker doesn't need to smuggle in a web shell disguised as a cache plugin, the way a lot of the incidents covered in our piece on how WordPress sites get hacked play out. They can request a plugin whose entire, documented purpose is remote file access or code execution, let WordPress's own installer fetch and verify it, and then use it as designed.
This is also not an isolated case. Several other critical WordPress plugin CVEs disclosed in July and August 2026 shipped with no fixed version at the time of disclosure. Type Hub, up to and including version 2.0.6, carries CVE-2026-66665, an unauthenticated arbitrary file upload scored at 10.0. Frontend Admin by DynamiApps, up to and including 3.29.10, carries CVE-2026-66662, an unauthenticated privilege escalation scored at 9.8. Login Social, up to and including 1.0.4, carries CVE-2026-16261, a high-severity flaw (7.5) where the plugin issues authentication sessions from unverified third-party sign-in data. None of the three had a fixed version listed when their advisories went out.
That's the pattern worth internalizing: "wait for the patch" is not a universal remediation strategy. Sometimes there isn't going to be one, because the developer is unresponsive, the plugin has been abandoned, or WordPress.org has already pulled the listing. When that happens, the only remediation left is removing the vulnerable code from the site.
Deactivate or delete: the decision that actually matters
WordPress site owners facing a no-patch CVE tend to reach for deactivation first, because it feels reversible and low-risk. It's worth being precise about what deactivating a plugin actually does. When you deactivate a plugin, WordPress stops loading its main file on every request, which means its hooks, including add_action('wp_ajax_nopriv_jslearnmanager_ajax', ...), never get registered. The AJAX endpoint genuinely disappears. A deactivated copy of WP Learn Manager is not reachable through the flaw described above; that part is a solid, verifiable fact, not a hedge.
So why not just deactivate and move on? Two reasons. First, the vulnerable PHP is still sitting on disk, and reactivation is one careless click away: a plugin management sweep, a staging-to-production sync that re-enables everything, a new team member restoring from an old backup, or an automated "reactivate all" script during a migration. Any of those puts the endpoint back. Second, treating "deactivated" as equivalent to "removed" trains a team to leave dead code around indefinitely, and that habit catches up with you eventually even when this specific flaw isn't the one that gets exploited.
For a plugin with no patch and no vendor able to ship one, delete it. Not deactivate, delete. Go to Plugins, deactivate WP Learn Manager if it's active, then use the Delete link to remove the plugin files entirely. If the site depends on functionality WP Learn Manager provided, that dependency needs to move to a maintained alternative before or immediately after removal, but keeping known-vulnerable code installed "just in case" isn't a real safety net.
How do you decide whether a plugin is abandoned rather than just quiet? Check the plugin's page on WordPress.org for a "closed" banner, like the one now sitting on WP Learn Manager's listing. Check the changelog for a gap of a year or more with no releases. Check whether the support forum has unanswered threads stretching back months. None of those alone is proof, but stacked together they tell you whether waiting for a fix is a real plan or wishful thinking.
What to do now
Confirm your installed version. If you're running WP Learn Manager 1.1.8 or any earlier release, treat the site as exposed regardless of whether you've noticed anything unusual. Deactivate the plugin immediately to close the jslearnmanager_ajax endpoint, then delete the plugin files rather than leaving them deactivated on disk.
Because the attack path is installing a real plugin, the indicators of compromise to check aren't malware signatures, they're inventory questions. Go to Plugins > Installed Plugins and look for anything you don't recognize, particularly file manager, code execution, or user management plugins your team didn't add. Check the active_plugins option in wp_options for entries that don't match what you expect to be running.
Review the Users screen for administrator accounts you didn't create, since a file manager or code runner installed through this flaw gives an attacker everything needed to add one. If your host logs requests to admin-ajax.php, search for action=jslearnmanager_ajax in the access logs around the time you suspect exposure; a hit there is close to definitive evidence of an attempted or successful exploit. Our guide on the signs a WordPress site has been hacked covers the broader indicators worth checking beyond this specific flaw.
If you find an unfamiliar plugin that was installed and activated without anyone on your team doing it deliberately, don't just delete it and move on. Assume it was used for something before you found it, and follow through: rotate WordPress and database credentials, check for new admin users, and review recently modified files for anything added around the same timestamp. WP Vanguard's scanner flags exactly this kind of unexplained plugin activity alongside known CVEs like this one. For the general hardening steps every WordPress site should have regardless of this specific CVE, our WordPress security checklist covers the baseline.
References
Related reading
Check Your WordPress Site Security
Free scan, no login required. Find vulnerabilities before attackers do.
Scan Your Site FreeGet weekly WordPress security tips
Vulnerability alerts, plugin updates, and security guides. No spam. Unsubscribe any time.