CVE-2026-119096: Uncanny Toolkit for LearnDash Auth Bypass

A critical vulnerability, tracked as CVE-2026-119096, affects the Uncanny Toolkit for LearnDash plugin for WordPress in versions up to and including 3.8.2. It is an authentication bypass in the plugin's front-end login handling, and it carries a CVSS score of 9.8 (critical).

If you run a LearnDash site with this toolkit, especially one that uses account approval or account suspension, you should review it now. The details below are limited to what the published advisories state. At the time of writing, no fixed version and no exploitation in the wild have been confirmed in the sources we reviewed.

What happened

The vulnerability was published on October 31, 2026 in the National Vulnerability Database and the GitHub Advisory Database as GHSA-c7cc-xqvj-xcq2. The record describes an authentication bypass reachable through the email parameter of the plugin's uo_login_action() function. It is classified as CWE-287, Improper Authentication.

The practical effect, according to the advisory, is that an unauthenticated attacker can log in to accounts that the plugin is supposed to block: accounts that are still unverified, or accounts an administrator has suspended. The attacker obtains a valid wordpress_logged_in session cookie, which is the normal WordPress login session.

Technical details in plain terms

The advisory describes a parser-differential flaw. Two parts of the code interpret the same submitted email value differently:

• The plugin's account-verification gate looks up the user using the raw, unsanitized string via get_user_by().
• The later wp_signon() call relies on WordPress core's internal sanitize_user(), which strips appended junk characters before resolving the account.

If an attacker appends extra characters to the value, the gate's lookup finds no matching user and the check is skipped. The login step then cleans the value, resolves the real account and authenticates it. In short, the security check and the login action disagree about which account is being talked about, and the check loses.

This is a common weakness pattern: validating one version of an input and then acting on a differently normalized version. The general fix is to normalize input once, early, and use that same value for both the check and the action.

The advisory also says the nonce needed to reach the handler can be obtained in the same request from an unauthenticated endpoint named ult-refresh-nonce. That means the nonce offers no meaningful barrier for an outsider. We are not publishing request details, and the advisory's CVSS vector (network, low complexity, no privileges, no user interaction) reflects how little is required.

Who is exposed

Exposure depends on how you use the plugin. The highest-risk sites are those that rely on the toolkit's front-end login together with:

• Manual or email-based account approval, where new users should not get in until verified.
• Suspending accounts of learners, members or staff as a control, for example after non-payment, abuse or offboarding.
• Course content, member data or paid material that suspended or unapproved users should not reach.

Because the attacker needs valid credentials, the realistic cases are suspended users who still know their own password, people who registered but were never approved, and anyone holding credentials obtained from a leak or reuse. The lower the privileges of such accounts, the lower the direct impact, but a suspended administrator or instructor account could matter much more. The CVSS rating assumes high impact across confidentiality, integrity and availability.

How to check your exposure

1. In the WordPress admin, open Plugins and look for Uncanny Toolkit for LearnDash (the plugin directory slug is uncanny-learndash-toolkit). Note the installed version. Version 3.8.2 or lower is in the affected range.
2. Check whether the front-end login module of the toolkit is enabled and whether your login page uses it. If you do not use it, record that, but still plan to update or remove the plugin.
3. List suspended and unapproved accounts under Users. These are the accounts whose controls this flaw can defeat.
4. Review recent logins for those accounts in any activity log you keep, looking for successful sign-ins that should have been blocked.
5. Check your web server access logs for unusual repeated POST requests to your login page or to the nonce refresh endpoint, from the same addresses.

For ongoing tracking of plugin issues, see Webforta's list of known vulnerabilities per WordPress plugin and the guide on whether your WordPress plugin is vulnerable.

What to do now

The research we reviewed does not list patched versions. The GitHub advisory shows both affected and patched versions as unknown, and no package is attached to it. The references do include a WordPress.org plugin repository changeset for the login class on trunk, but the sources do not say that this changeset is a released fix, so do not assume it is. Check the plugin's official changelog and the Wordfence vulnerability entry for the current fixed version.

1. Update the plugin as soon as the vendor publishes a release newer than 3.8.2 that states it addresses this issue. Take a backup first and test on staging if you can.
2. Until you can confirm a fixed version, consider disabling the toolkit's front-end login module, or deactivating the plugin if you can live without it, and fall back to the standard WordPress login.
3. Do not rely on the plugin's suspension for urgent cases. For anyone who must lose access, change the account's password, change its role to the lowest available one or delete it, and end its sessions.
4. Reset passwords for suspended and unapproved accounts, so known credentials stop working.
5. If you see sign-ins that should have been blocked, treat it as a possible compromise: review what the account touched, check for new admin users, and follow our guide on what to do when a website is hacked.
6. Enable two-factor authentication for administrators and instructors where possible, and limit login attempts.

A website firewall can add a layer of filtering in front of login endpoints, but it is not a substitute for updating. Our overview of what a WAF is explains what to expect from one.

Detection and monitoring afterwards

• Keep a log of successful logins, including the user, time and IP address, and alert on logins by accounts marked suspended.
• Watch for new administrator accounts and role changes.
• Monitor for unexpected changes to plugin files and for new plugins you did not install.
• Subscribe to plugin vulnerability feeds so you hear about fixes and any exploitation reports quickly. This article will be out of date once a fix is released.

You can also run a free malware scan for visible signs of compromise, keeping in mind that an outside scan cannot see everything that happens inside a logged-in session.

What is still unconfirmed

We will treat this as a serious but conditional risk until a fixed release and any exploitation reports are confirmed.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

• CVE-2026-119096 - GitHub Advisory Database (github.com)
• CVE-2026-119096: The Uncanny Toolkit for LearnDash plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 3.8.2 via the `email`… (nvd.nist.gov, 31 October 2026)

Tags: WordPress, LearnDash, CVE-2026-119096, Authentication bypass, Plugin vulnerability