← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-6456 · CWE-287 · Disclosed 2026-05-20

The Account Switcher plugin for WordPress is vulnerable to Privilege Escalation in all versions up to

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.'

"Full admin compromise on an affected site, but only after the attacker already has a low-privileged WordPress account."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a site running the plugin with WPScan or passive fingerprinting

The attacker first identifies WordPress instances running 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.
Conditions required:
  • Target is a WordPress site
  • The account-switcher plugin is installed at version 1.0.2 or earlier
Where this breaks in practice:
  • 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
Detection/coverage: Commodity web scanners can sometimes flag the plugin slug, but internet-scale coverage is weak for specific WordPress plugins. Expect false negatives.
STEP 02

Get a low-privilege account with native registration or stolen creds

The exploit chain only starts after the attacker has at least a Subscriber session. That means self-registration must be enabled, the attacker must compromise a low-privilege user, or they must already be inside a customer/member workflow.
Conditions required:
  • Attacker has valid WordPress credentials for a Subscriber-or-higher account
  • The affected site actually uses low-privilege user accounts
Where this breaks in practice:
  • 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
Detection/coverage: This step is usually visible to IAM, SSO, MFA, and WordPress auth logs rather than vuln scanners.
STEP 03

Abuse the rememberLogin REST route with curl or Burp Repeater

The attacker sends a crafted request to the plugin's REST endpoint with an empty 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.
Conditions required:
  • Target user has no asSecret value set from the plugin's remember-me logic
  • REST route remains exposed and reachable
  • Attacker can identify or guess a target admin user
Where this breaks in practice:
  • 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-json access
  • The attacker still needs a valid target account to impersonate
Detection/coverage: App-layer logs, reverse proxies, or WAFs may record unusual POSTs to plugin REST paths, but generic signatures are unlikely to label this as exploitation.
STEP 04

Land as admin and pivot through native WordPress controls

Once the plugin sets the auth cookie, the attacker is effectively logged in as the impersonated user. If that user is an Administrator, the attacker can install plugins, edit code, add users, reset passwords, or turn the site into a foothold for further credential theft and web-shell persistence.
Conditions required:
  • Impersonated account has administrative privileges
  • No downstream hardening blocks post-login admin actions
Where this breaks in practice:
  • 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
Detection/coverage: EDR on the web host won't see the bug itself, but WordPress audit logs can catch impossible-user switches, admin logins from subscriber-origin sessions, plugin installs, and theme/plugin editor activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation located in reviewed sources; not listed in CISA KEV.
Public exploit / PoCNo 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.
EPSS0.00045 (~0.045% probability over 30 days, per user-provided intel). That is very low and consistent with niche-plugin, auth-required abuse.
KEV statusNo; reviewed against the current CISA KEV catalog.
CVSS vector reality checkCVSS: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 versionsAll versions up to and including 1.0.2.
Fixed versionNo official patched version published in Patchstack at the time reviewed.
Exposure / populationWordPress.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 timelineNVD shows the CVE was published 2026-05-19 and last modified 2026-05-20; Patchstack's page was published 2026-05-21.
Researcher / source CNAThe vulnerability is attributed to Ren Voza; NVD lists Wordfence as the source.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

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.

HIGH Exploit impact on an installed vulnerable host
MEDIUM Exposure prevalence across enterprise fleets

Why this verdict

  • Down from 8.8 because PR:L is 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.

05 · Compensating Control

What to do — in priority order.

  1. Disable or remove the plugin — If account-switcher is 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.
  2. Block the plugin REST route — Add a reverse-proxy or WAF rule to deny requests to the plugin's wp-json routes 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.
  3. 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.
  4. 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.
  5. 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.
What doesn't work
  • 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-admin or moving the login page doesn't fix the vulnerable REST flow under wp-json.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: query the fleet for 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

  1. NVD CVE-2026-6456
  2. Patchstack advisory for Account Switcher <= 1.0.2
  3. WordPress.org plugin page
  4. WordPress.org advanced view
  5. Wordfence vulnerability database search result
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS data statistics
  8. ChoosePlugin package metadata and download count
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.