This is a master key left behind the front desk, not a burglar kicking in the front door
CVE-2026-6456 affects the WordPress Account Switcher plugin in all versions through 1.0.2. The vulnerable flow sits in the plugin's rememberLogin REST endpoint: it accepts an attacker-controlled secret, compares it loosely, and fails open when the target user's asSecret metadata is empty. Combined with REST routes exposed via permissive callbacks, a Subscriber-level user can mint an authenticated session for another user, including an Administrator.
The vendor-style 8.8/HIGH score is technically fair for *impact on a vulnerable host*, but it overstates *enterprise patch priority*. The big friction is attacker position: this is not unauthenticated internet-to-admin. It requires an existing low-privilege WordPress foothold, and the plugin itself appears niche, was closed on WordPress.org on 2026-05-14, and shows Active installations: N/A. That pushes this down from 'drop everything' to 'fix where present, especially on self-registration sites.'
4 steps from start to impact.
Find a site running the plugin with WPScan or passive fingerprinting
account-switcher, usually by reading plugin paths, static assets, or plugin metadata. On a single target this is trivial manual recon; at scale it is less reliable because WordPress plugin fingerprinting is messy and often blocked by caching or WAFs.- Target is a WordPress site
- The
account-switcherplugin is installed at version 1.0.2 or earlier
- Plugin has Active installations: N/A on WordPress.org, suggesting a small reachable population
- Many enterprises do not expose plugin paths cleanly to unauthenticated users
- WordPress.org closed the plugin on 2026-05-14, limiting new uptake
Get a low-privilege account with native registration or stolen creds
- Attacker has valid WordPress credentials for a Subscriber-or-higher account
- The affected site actually uses low-privilege user accounts
- This is post-initial-access for most enterprise WordPress estates
- Many corporate brochure sites have no public registration and very few subscriber accounts
- MFA, SSO, and identity controls may stop the attacker before they ever get the required foothold
Abuse the rememberLogin REST route with curl or Burp Repeater
secret value while targeting a user whose asSecret metadata is empty. Per the NVD description, the route's loose comparison and missing non-empty validation let the check pass, and the plugin calls wp_set_auth_cookie() for the target user.- Target user has no
asSecretvalue set from the plugin's remember-me logic - REST route remains exposed and reachable
- Attacker can identify or guess a target admin user
- The exploit depends on a specific state condition: the target user's secret must be unset/empty
- Some environments may disable or heavily monitor
wp-jsonaccess - The attacker still needs a valid target account to impersonate
Land as admin and pivot through native WordPress controls
- Impersonated account has administrative privileges
- No downstream hardening blocks post-login admin actions
- Blast radius is usually limited to the affected WordPress instance and whatever secrets it stores
- Strong change monitoring may catch new plugins, code edits, or user creation quickly
The supporting signals.
| In-the-wild status | No evidence of active exploitation located in reviewed sources; not listed in CISA KEV. |
|---|---|
| Public exploit / PoC | No public GitHub/Metasploit PoC found in review. That said, the NVD description is detailed enough that a working exploit is straightforward to recreate with curl or Burp. |
| EPSS | 0.00045 (~0.045% probability over 30 days, per user-provided intel). That is very low and consistent with niche-plugin, auth-required abuse. |
| KEV status | No; reviewed against the current CISA KEV catalog. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H is accurate about host impact, but PR:L is the whole story here: it assumes the attacker already crossed the identity boundary. |
| Affected versions | All versions up to and including 1.0.2. |
| Fixed version | No official patched version published in Patchstack at the time reviewed. |
| Exposure / population | WordPress.org shows the plugin was closed on 2026-05-14 and lists Active installations: N/A. A third-party catalog reports only 593 total downloads, which points to a small real-world footprint. |
| Disclosure timeline | NVD shows the CVE was published 2026-05-19 and last modified 2026-05-20; Patchstack's page was published 2026-05-21. |
| Researcher / source CNA | The vulnerability is attributed to Ren Voza; NVD lists Wordfence as the source. |
noisgate verdict.
The decisive downward pressure is attacker position: exploitation requires an already-authenticated Subscriber session, so this is usually a post-initial-access privilege escalation, not an internet-front-door compromise. The second major limiter is population size: the plugin appears niche, closed on WordPress.org, and does not show a broad exposed install base.
Why this verdict
- Down from 8.8 because
PR:Lis not a footnote — the attacker must already have a WordPress account or stolen low-privilege credentials, which means this usually sits *after* initial access. - Down again because the exposed population is narrow — WordPress.org shows the plugin is closed and
Active installations: N/A, so this is not a broad internet-wide fire. - Still MEDIUM, not LOW, because compromise is decisive once conditions are met — a single subscriber on an affected site can become full admin, which is a complete trust-boundary break for that application.
Why not higher?
If this were unauthenticated or broadly deployed, it would stay HIGH or higher because the end state is full administrator compromise. But requiring an authenticated foothold and a niche plugin sharply reduces both reachable population and attacker convenience.
Why not lower?
This is not harmless edge-case logic abuse. On a site where the plugin exists and subscribers are common, the path from low privilege to full admin is short, reliable, and operationally meaningful.
What to do — in priority order.
- Disable or remove the plugin — If
account-switcheris present, this is the cleanest containment because no official patched version was published in reviewed sources. For a MEDIUM verdict there is no noisgate mitigation SLA, but on public-registration or membership sites you should still remove it in the next normal change window instead of waiting for a vendor fix that may never ship. - Block the plugin REST route — Add a reverse-proxy or WAF rule to deny requests to the plugin's
wp-jsonroutes tied to Account Switcher. This does not replace remediation, but it is a practical stopgap when the business refuses to remove the plugin; for this MEDIUM item there is no mandatory mitigation deadline, so use the next safe web-tier deploy. - Turn off self-registration where possible — The exploit chain needs a Subscriber foothold. If the site does not truly need public user creation, disabling native registration removes the easiest path to the required attacker position; make this part of the same remediation effort within the 365-day window.
- Audit and prune low-privilege accounts — Reset stale subscriber credentials, disable dormant accounts, and review identity sources feeding WordPress. This shrinks the only prerequisite that really matters here: valid low-privilege login access.
- Enable WordPress audit logging — Log admin logins, role changes, plugin installs, theme edits, and unusual REST access so you can catch successful abuse quickly. For a MEDIUM finding this is hardening, not a formal mitigation SLA item, but it should be bundled with your normal WordPress control baseline.
- MFA on admin accounts doesn't stop session minting after compromise of a Subscriber account if the plugin directly sets an auth cookie for the target user.
- A generic vulnerability scanner won't reliably find exploitation or even all exposed sites, because WordPress plugin fingerprinting is inconsistent and the bug is business-logic-specific.
- Hiding
/wp-adminor moving the login page doesn't fix the vulnerable REST flow underwp-json.
Crowdsourced verification payload.
Run this on the target WordPress host or from your config-management agent with read access to the web root; no root is required. Invoke it as bash verify-cve-2026-6456.sh /var/www/html and it will inspect wp-content/plugins/account-switcher, extract the installed version if possible, and print VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env bash
# verify-cve-2026-6456.sh
# Detects likely exposure to CVE-2026-6456 in the WordPress Account Switcher plugin.
# Exit codes:
# 0 = PATCHED / not installed
# 1 = VULNERABLE
# 2 = UNKNOWN / inspection failed
set -u
TARGET_ROOT="${1:-}"
PLUGIN_REL="wp-content/plugins/account-switcher"
AFFECTED_MAX="1.0.2"
if [[ -z "$TARGET_ROOT" ]]; then
echo "UNKNOWN - usage: $0 /path/to/wordpress"
exit 2
fi
PLUGIN_DIR="$TARGET_ROOT/$PLUGIN_REL"
REST_FILE="$PLUGIN_DIR/app/RestAPI.php"
BASE_FILE="$PLUGIN_DIR/app/PluginHero/BaseAPI.php"
version_lte() {
# returns 0 if $1 <= $2
local a="$1" b="$2"
[[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)" == "$a" ]]
}
extract_version() {
local dir="$1"
local v=""
if [[ -f "$dir/readme.txt" ]]; then
v=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^Stable tag:/ {print $2; exit}' "$dir/readme.txt" 2>/dev/null)
if [[ -n "$v" ]]; then
echo "$v"
return 0
fi
fi
local phpfile
while IFS= read -r -d '' phpfile; do
v=$(awk -F': *' 'BEGIN{IGNORECASE=1} /^Version:/ {print $2; exit}' "$phpfile" 2>/dev/null)
if [[ -n "$v" ]]; then
echo "$v"
return 0
fi
done < <(find "$dir" -maxdepth 1 -type f -name '*.php' -print0 2>/dev/null)
return 1
}
if [[ ! -d "$PLUGIN_DIR" ]]; then
echo "PATCHED - plugin not installed at $PLUGIN_DIR"
exit 0
fi
VERSION=""
if VERSION=$(extract_version "$PLUGIN_DIR"); then
VERSION="$(echo "$VERSION" | tr -d '[:space:]')"
fi
# Optional sanity checks for known vulnerable file layout.
HAS_LAYOUT=0
if [[ -f "$REST_FILE" && -f "$BASE_FILE" ]]; then
HAS_LAYOUT=1
fi
if [[ -n "$VERSION" ]]; then
if version_lte "$VERSION" "$AFFECTED_MAX"; then
echo "VULNERABLE - Account Switcher version $VERSION installed"
exit 1
else
echo "PATCHED - Account Switcher version $VERSION installed (newer than $AFFECTED_MAX)"
exit 0
fi
fi
if [[ $HAS_LAYOUT -eq 1 ]]; then
echo "UNKNOWN - plugin directory present with expected vulnerable file layout, but version could not be determined"
exit 2
fi
echo "UNKNOWN - plugin directory present, but version and file layout could not be verified"
exit 2
If you remember one thing.
wp-content/plugins/account-switcher and separate sites with public registration / member logins from brochureware. If you find this plugin on a site that issues Subscriber accounts, disable or replace it in the next standard change window because there is no official patch published in reviewed sources; otherwise document absence and move on. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but the noisgate remediation SLA still means you should remove, replace, or vendor-fix the plugin within 365 days, and sooner on any internet-facing membership site because the prerequisite foothold is realistic there.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.