Critical Auth Bypass in DevKit Pro Lets Unauthenticated Attackers Take Over WordPress Admin Accounts

Executive Summary

A critical authentication bypass vulnerability (CVE-2026-14378) has been disclosed in the DevKit Pro plugin for WordPress, a commercial developer-toolkit plugin sold directly by dplugins (not distributed via the WordPress.org repository). The flaw carries a CVSS score of 9.8 and allows a completely unauthenticated attacker to take over any WordPress account on an affected site, including administrator accounts.

CVSS Score: 9.8 (Critical)

The vulnerability lives in DevKit Pro's "switch user" feature, a convenience tool that lets an administrator temporarily act as another account. When that feature is used, the plugin stores the original administrator's ID in a cookie named original_user_id and renders a "switch back" form — including a valid nonce — in the site footer on every page load, for every visitor, whenever that cookie is present. Because the plugin's revert_switch handler validates the request's privilege level against the user referenced by the attacker-controlled cookie rather than against the actual requester, anyone who sets the cookie themselves can walk away with a fully authenticated administrator session. No credentials, no social engineering, and no user interaction are required.

The issue affects all versions up to and including 2.3.0. It was reserved on 2026-07-01 and published on 2026-10-02, with Wordfence acting as the CVE assigner (CWE-287, Improper Authentication).

Vulnerability Overview

Affected Versions

Note on the fix: DevKit Pro is sold directly through the vendor's own site rather than hosted on WordPress.org, and the public vendor changelog does not explicitly tie a numbered release to this CVE. Third-party trackers disagree on the exact patched release — some cite 2.3.1, others cite 3.0.0 — so this advisory does not assert a specific fixed version. Site owners should update DevKit Pro to the latest available version from the vendor and confirm directly with dplugins that the installed build addresses CVE-2026-14378, rather than relying on a version number alone.

Because DevKit Pro is not listed on the WordPress.org plugin repository, no public "active installations" count is available for this plugin, unlike WordPress.org-hosted plugins.

How It Worked

1. A trusted cookie that isn't trustworthy

DevKit Pro's "switch user" feature is designed for administrators who want to temporarily view the site as another account. When an admin switches, the plugin writes that admin's original user ID into a cookie called original_user_id so a later "switch back" action knows who to restore.

2. The switch-back form renders for anyone

The plugin renders a "switch back" HTML form — including a server-generated nonce — in wp_footer on every page whenever the original_user_id cookie is present. Critically, the plugin never checks whether the current visitor is actually the administrator who started a switch session; it only checks whether the cookie exists.

3. revert_switch trusts the cookie, not the requester

The handler behind this feature, revert_switch, calls an internal verify_nonce_and_capability() routine. That routine checks the manage_options capability against the user identified by the original_user_id cookie — rather than calling current_user_can() against the actual, currently-authenticated requester. A valid nonce plus a forged cookie is all it takes to pass the check.

4. Full admin session, zero credentials

An unauthenticated attacker can:

1. Set Cookie: original_user_id=1 (or any known/guessed administrator user ID) in their browser or HTTP client.
2. Request any public page on the target site and parse the footer for the rendered "switch back" form and its nonce.
3. Submit that nonce in a POST request to the revert_switch AJAX action (e.g. via admin-ajax.php).
4. The handler calls wp_set_auth_cookie() using the administrator's ID from the forged cookie, issuing the attacker a fully authenticated administrator session cookie.

From that point, the attacker has complete control of the WordPress site — plugin/theme installation, content modification, user management, and database access via the admin dashboard.

Impact Assessment

Recommendations

For Site Administrators

1. Update DevKit Pro immediately to the latest version available from the vendor (dplugins) and verify with the vendor that the installed build resolves CVE-2026-14378 — do not rely on a specific version number from secondary sources.
2. If an update cannot be verified or applied immediately, deactivate DevKit Pro until the fix is confirmed, especially on sites where the "switch user" feature is in active use.
3. Audit administrator accounts for any unrecognized or newly created users, and review recent plugin/theme installs for unauthorized changes.
4. Rotate WordPress authentication salts/keys (wp config shuffle-salts via WP-CLI, or regenerate via wp-config.php) to invalidate any sessions an attacker may already hold.
5. Review web server and WAF logs for requests setting an original_user_id cookie combined with POSTs to revert_switch-style AJAX actions.

For Security Teams

1. Deploy detection rules at the WAF level for requests that set an original_user_id cookie on anonymous sessions, particularly followed by action=revert_switch POST requests.
2. Treat any site running DevKit Pro as high priority for patch verification, given the public availability of proof-of-concept/scanner tooling.
3. Monitor for indicators of compromise consistent with administrator takeover: new admin users, modified wp-config.php, newly installed plugins/themes, or unexpected file changes in wp-content/.
4. Track vendor communication from dplugins for an authoritative confirmation of the patched release, since public reporting on the exact fixed version is inconsistent.

For General Users

1. If you manage or contribute to a WordPress site, ask your administrator to confirm whether DevKit Pro is installed and whether it has been updated.
2. Change your WordPress password and enable multi-factor authentication where supported, as a defense-in-depth measure against session-based account takeover.

Key Takeaways

1. CVE-2026-14378 is a CVSS 9.8 critical authentication bypass in the DevKit Pro WordPress plugin, affecting all versions ≤ 2.3.0.
2. The root cause is a privilege check performed against an attacker-controlled cookie (original_user_id) instead of the actual authenticated requester.
3. Exploitation requires no credentials and no user interaction — only a forged cookie value and a nonce harvested from a public page.
4. Successful exploitation grants the attacker a fully authenticated administrator session, equivalent to complete site compromise.
5. No specific fixed version is confirmed across primary sources at the time of writing; administrators should update to the latest available DevKit Pro release and verify the fix directly with the vendor.
6. Public proof-of-concept and scanner code already exists, raising the risk of opportunistic mass exploitation — treat patch verification as urgent.

Sources

• NVD — CVE-2026-14378
• Wordfence Threat Intelligence — CVE-2026-14378
• OffSeq Threat Radar — CVE-2026-14378
• DEV Community — WordPress Auth Bypass Cluster: 4x CVSS 9.8 Full Site Takeover via Plugin Flaws
• GitHub — murrez/CVE-2026-14378 (PoC)
• dplugins — DevKit Changelog