DevKit Pro Auth Bypass (CVE-2026-14378): original_user_id and the revert_switch Trap

When “switch user for testing” becomes full site takeover

DevKit Pro (vendor dplugins) is a commercial WordPress toolkit with a Users Manager feature that lets administrators impersonate other accounts. CVE-2026-14378 (Wordfence CNA, CVSS 3.1 9.8 Critical, CWE-287) turns that convenience into unauthenticated administrator session takeover in all versions ≤ 2.3.0. Vendor fix: ≥ 3.0.0.

The bug is not a leaked password or a weak nonce on wp-login—it is authorization checked against the wrong identity. Public PoC and lab validation: CVE-2026-14378 on pocbit.org. Repository: murrez/CVE-2026-14378.

Root cause in one paragraph

When an admin uses user switching, DevKit stores the prior account in a client cookie original_user_id. If that cookie is present, the plugin prints a “switch back” UI in wp_footer on the front end, including a WordPress nonce for the revert AJAX action.

The revert_switch handler validates manage_options against the user ID in the cookie, not against current_user_can() for whoever actually sent the request. An unauthenticated visitor who forges Cookie: original_user_id=1 can harvest the footer nonce and POST to admin-ajax.php to trigger wp_set_auth_cookie() for the administrator.

Same product, different issue: CVE-2026-14357 (subscriber+ arbitrary theme ZIP)—patch and track both.

Defender checklist

| # | Action | Detail | |---|--------|--------| | 1 | Confirm DevKit Pro version | Exposed readme.txt under custom plugin paths (not wordpress.org) | | 2 | Upgrade to ≥ 3.0.0 | dplugins changelog | | 3 | Until patched, disable Users Manager / user switching | Feature is off by default on many sites—absence of footer nonce may mean disabled, not safe | | 4 | Hunt revert_switch / DPDEV_revert_switch in WAF and access logs | Pair with forged original_user_id cookies | | 5 | Review new admin sessions after suspected exploit | Rotate admin passwords and session tokens |

Cross-read: WordPress plugin vulnerabilities defender guide, authentication bypass — what to check, WordPress security checklist (2026).

Why “check” mode matters

Authorized scanners should run check first: it forges the cookie and looks for switch-back material in the footer without completing takeover. A site on ≤ 2.3.0 with Users Manager disabled may show vulnerable version fingerprints but no exploitable nonce—still upgrade, because an admin can enable switching later.

Soft 404 readme responses (HTTP 200 with HTML) are common; validate Plugin Name: in body, not status code alone.

Patch validation in a lab

1. Disposable WordPress + DevKit ≤ 2.3.0 with Users Manager enabled.
2. Run PoC check, then controlled admin mode on the lab URL only.
3. Upgrade to 3.0.0+; repeat—expect no footer oracle.

See safe PoC lab setup and CVE PoC testing step-by-step.

FAQ

We do not use user switching—is DevKit safe?

Lower immediate risk if the feature stays off, but upgrade anyway. Commercial plugins on membership and agency stacks often get toggled during support work.

Can CDN/cache strip the footer oracle?

Yes—mass scan false negatives happen. Version inventory plus upgrade beats external scanning alone.

Bottom line

CVE-2026-14378 is a textbook “check capability for user A while requester is anonymous” mistake. Treat DevKit Pro like any admin-power plugin: version control, feature flags, and fast vendor updates—not “obscure commercial, low priority.”