CVE-2026-119096: Uncanny Toolkit Login Gate Misses the Account - Floor 3.8.3

CVE-2026-119096 is Wordfence’s name for an authentication bypass in Uncanny Toolkit for LearnDash (uncanny-learndash-toolkit) through 3.8.2. CNA title: Unauthenticated Authentication Bypass via 'email' Parameter. CVE state PUBLISHED. datePublished 2026-10-31T07:46:49.237Z. Finder: Kuba. Vendor notified 2026-10-29T14:14:13Z; disclosed 2026-10-30T19:20:23Z.[1][3]

Wordfence (CNA) scores it 9.8 critical (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). CWE is CWE-287 (Improper Authentication). NVD vulnStatus is Received; the 9.8 is Primary from security@wordfence.com. NVD has not published a separate Coordinator score. cisaExploitAdd is empty on the NVD object we pulled.[2]

Wordfence Intelligence: publicly published 30 Oct 2026, last updated 31 Oct 2026. Remediation on that row: 3.8.3.[3]

The wordpress.org plugin API this morning returned version 3.8.3, active_installs 20000 (the directory’s 20k bucket), last updated 2026-10-29 8:41pm GMT, tested to 7.1.4, requires WP 6.3 / PHP 7.4. Author: Uncanny Owl. Changelog 3.8.3 [2026-10-29] includes: “Front End Login - Manual User Verification could be bypassed for accounts with valid credentials #585.” That is the vendor’s wording for this class of bug. The same changelog also lists a WP 2FA login-completion item (#586); that is not this CVE’s CNA text.[4]

What it is

This is a Front End Login bug in the Toolkit plugin, not WordPress core, not LearnDash core, and not PHP2Shell.[1][3]

Wordfence / CNA text: uo_login_action() has a parser differential. The account-verification gate resolves the submitted email value with the raw string passed to get_user_by(). The later wp_signon() call uses WordPress core’s sanitize_user(), which strips appended junk. The gate lookup then fails and is skipped; wp_signon() still resolves and authenticates the real account. Wordfence’s claimed result: an unauthenticated attacker who already has that account’s credentials can obtain a wordpress_logged_in cookie and defeat the plugin’s account-approval and account-suspension controls. The AJAX nonce is not a barrier: uo_refresh_nonce_action() is hooked on wp_ajax_nopriv_ult-refresh-nonce and returns wp_create_nonce( 'uncannyowl-learndash-toolkit' ) with no login.[1][3]

Public 3.8.2 source matches that write-up, without us sending a login:

uo_login_action() (Wordfence’s cited plant around L3428) requires the toolkit nonce, then reads $_POST['email'] / $_POST['password'].[5]
$credential['user_login'] is $_POST['email'] un-sanitized (L3493-3495).[5]
When uo_frontendloginplus_needs_verifcation is on, the gate does get_user_by( 'email', $credential['user_login'] ) then get_user_by( 'login', … ) on that same raw value (Wordfence L3527). If that lookup misses, the unverified check never runs.[5]
Sign-on is wp_signon( $credential, $secure_cookie ) (Wordfence L3559). Core sanitizes user_login inside authenticate; the plugin did not, on this path.[5]
uo_refresh_nonce_action() (Wordfence L3357) is the nopriv nonce mint.[5]

3.8.3’s comment in that function: “Pass the login to wp_signon() unslashed, as wp-login.php does, and look users up by the same sanitized value wp_authenticate() derives from it.” It sets $sanitized_login = sanitize_user( $user_login ), looks up with that value, and if manual verification is on, adds authenticate → block_unverified_ajax_login at PHP_INT_MAX so the user wp_signon() actually resolves is also checked.[6]

We did not POST a login, mint a nonce, or append junk to an email. Treat “auth bypass” as Wordfence’s published claim, with the 3.8.2 call sites as the part we can read.[3][5]

How serious

A 9.8 with C:H I:H A:H, PR:N, AC:L, UI:N is Wordfence scoring no WordPress session required. That is not “no password.” CNA text is explicit: the attacker needs knowledge of a target account’s credentials. PR:N here means the handler is reachable without being logged in, including via the nopriv nonce endpoint.[1][2][3]

Scope is unchanged (S:U): the CNA is scoring the WordPress process, not a claimed hypervisor or panel-root breakout.[1][2]

What Wordfence says you get, if the credentials are valid: a session for an account the plugin was supposed to keep unverified (and, in their wording, administrator-suspended). That is a login-policy bypass, not a password oracle and not unauthenticated RCE. On an LMS box that uses Front End Login + manual verification, that policy is the product.[1][3]

Not in CISA KEV as of catalog 2026.10.30 (dateReleased 2026-10-30T17:02:45.3665Z, 1766 entries). Newest dateAdded on that dump: 30 Oct Ivanti Connect Secure - not WordPress. Absence from KEV is not a clean bill of health.[9]

Wordfence Intelligence on this ID does not print an in-the-wild flag on the page we pulled. We did not scan the fleet.[3]

Who is affected

In scope, per the CNA affected block:[1][2]

Product: Uncanny Toolkit for LearnDash (vendor uncannyowl).
Versions: 0 through 3.8.2 (semver lessThanOrEqual 3.8.2). defaultStatus: unaffected.
Trigger Wordfence published: Front End Login AJAX (uo_login_action) with a raw email that fails the verification lookup and still signs on. Inventory the slug and version. Do not argue from “we don’t use Kanban” or “students self-register.”[3][5]

Wordfence’s impact sentence is about unverified / administrator-suspended accounts when manual verification (option uo_frontendloginplus_needs_verifcation) is on. 3.8.2 source we read uses user meta uo_is_verified. We did not independently map “administrator-suspended” onto a second field; report that half as Wordfence wrote it.[1][3][5]

Out of scope unless you have a separate advisory:

Sites already on 3.8.3 (API version this morning is 3.8.3).[4]
LearnDash LMS core. This ID is the Toolkit plugin’s Front End Login module.[1]
Uncanny Toolkit Pro as a CNA product. The affected object is the wordpress.org slug. Patch Pro on Uncanny Owl’s own schedule; that is not this CVE’s floor.[1][4]
The WP 2FA changelog line in 3.8.3 (#586). Different sentence, not CVE-2026-119096.[4]

20,000 is wordpress.org active_installs this morning, not a census we ran.[4]

What to do now

Inventory the slug.

# one site
wp plugin get uncanny-learndash-toolkit --field=version --path=/home/USER/public_html
wp plugin list --name=uncanny-learndash-toolkit --fields=name,status,version --path=/home/USER/public_html

# cPanel box, every account (read-only). Bootstrap on 3.8.3 is uncanny-learndash-toolkit.php.
find /home -path '*/wp-content/plugins/uncanny-learndash-toolkit/uncanny-learndash-toolkit.php' 2>/dev/null \
  | while read -r f; do
      ver=$(awk -F': ' '/^[[:space:]]*\*?[[:space:]]*Version:/{print $2; exit}' "$f")
      echo "$ver  $f"
    done

Ship 3.8.3. That is what wordpress.org is serving and what Wordfence lists as the patched version. Do not stay on 3.8.2 because 3.8.2 already had password-reset hardening - that was #557 on 16 Oct, a different bug.[3][4]

wp plugin update uncanny-learndash-toolkit --path=/home/USER/public_html
wp plugin get uncanny-learndash-toolkit --field=version --path=/home/USER/public_html   # want 3.8.3

If you cannot update today: treat Front End Login as an untrusted login surface. Deactivate the plugin, or turn off Front End Login until 3.8.3 is on the box. A WAF rule is not a version bump. The published path is AJAX login + nopriv nonce mint, not wp-login.php.[3]

wp plugin deactivate uncanny-learndash-toolkit --path=/home/USER/public_html

We are not publishing a payload, a junk suffix, or a curl line against admin-ajax.php.

After the bump, look at who is logged in. 3.8.3 does not unwind a session that was already minted. If you have reason to hunt: accounts that were still uo_is_verified=0 (or that staff thought were suspended) with recent wordpress_logged_in activity around 29-31 Oct; unexpected administrators; then rotate WordPress salts and invalidate sessions. Presence of a new admin is a hunt target for any WP incident, not a fingerprint unique to this CVE.
Unsupported / frozen lines. CNA range is 0 through 3.8.2. There is no 3.7.x patched build in the record we pulled. Jump a frozen copy through staging, or remove the plugin.[1][4]

Compromise signs

The published class is unauth AJAX login → claimed verification/suspension bypass, given a password. Hunt for, do not treat as proof:[1][3]

Logins succeeding for accounts staff still show as unverified, especially after 29 Oct.
admin-ajax.php POSTs with action=ult-refresh-nonce followed by the Front End Login action, in nginx/Apache logs. We are not naming a working email suffix.
Plugin still reporting ≤ 3.8.2 after you thought you updated.
New administrators you did not create. That is generic WP incident hygiene, not a unique IOC.

Absence is not proof of cleanliness. We did not publish a Nuclei template and we did not send a probe.

FAQ

Is this PHP2Shell? No. PHP2Shell is CVE-2026-109618 / 109619 in PHP itself. This ID is Uncanny Toolkit’s Front End Login.[1][3]

Do I have to be logged in? CNA / NVD vector is PR:N. Wordfence’s reason: the handler is nopriv, and ult-refresh-nonce mints the nonce. You still need the account password per the same paragraph.[1][2][3]

Is this unauthenticated RCE? No. Wordfence’s claimed end state is a session cookie for an account that should have stayed unverified/suspended. Not a file write, not eval.[1][3]

Does every install with the plugin vulnerable? CNA version range is ≤ 3.8.2. Wordfence’s cited plant is Front End Login’s verification lookup vs wp_signon(). Inventory the version anyway; do not skip 3.8.3 because “we only use the course grid.”[1][5]

Does this give root on the box? Scored scope is unchanged. That is still the WordPress user of that account, not a claimed KVM or panel root.[1][2]

Is LearnDash itself patched by this? No. Patch uncanny-learndash-toolkit. LearnDash core is a different product.[1][4]

Is Pro covered? Not as a CNA product. Patch the .org slug you actually run.[1][4]

Honesty / What we could not verify

We did not exploit this. No AJAX login was sent. No nonce was minted. No junk was appended to an email.
We did not reconstruct a working suffix. Wordfence states a parser differential (get_user_by on raw email vs sanitize_user inside wp_signon). 3.8.2 source shows those two lookups. We did not identify a specific junk character.
Credentials are required. The 9.8 / PR:N score is Wordfence’s. Do not read it as passwordless admin takeover.[1][3]
“Administrator-suspended” is Wordfence’s wording. The 3.8.2 gate we read checks uo_is_verified. We did not map a second suspension field.
20,000 is wordpress.org active_installs this morning, not a census we ran.[4]
Not on CISA KEV as of catalog 2026.10.30 / count 1766.[9]
NVD status Received; 9.8 is Wordfence Primary.[2]
In-the-wild: the Wordfence Intelligence page we pulled does not claim active exploitation.
#586 (WP 2FA) in the 3.8.3 changelog is not this CVE. Do not merge the two fixes in a ticket.[4]

Sources

[1] https://cveawg.mitre.org/api/cve/CVE-2026-119096 - CVE-2026-119096 CNA [2] https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-119096 - NVD CVE-2026-119096 [3] https://www.wordfence.com/threat-intel/vulnerabilities/id/592b61a1-9ac9-4817-b154-1e39e50d8010?source=cve - Wordfence Intelligence [4] https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request%5Bslug%5D=uncanny-learndash-toolkit - wordpress.org plugin API [5] https://plugins.svn.wordpress.org/uncanny-learndash-toolkit/tags/3.8.2/src/classes/frontend-login-plus.php - Front End Login 3.8.2 [6] https://plugins.svn.wordpress.org/uncanny-learndash-toolkit/tags/3.8.3/src/classes/frontend-login-plus.php - Front End Login 3.8.3 (sanitized lookup + authenticate filter) [7] https://plugins.trac.wordpress.org/changeset/3773997/uncanny-learndash-toolkit/trunk/src/classes/frontend-login-plus.php - vendor changeset [8] https://www.cve.org/CVERecord?id=CVE-2026-119096 - CVE.org record [9] https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CISA KEV JSON