This is a hidden master key taped to the outside of the building
CVE-2026-8732 is an unauthenticated administrator-account creation flaw in the premium WordPress plugin WP Maps Pro (wp-google-map-gold). Affected versions are all releases up to and including 6.1.0; the fix landed in 6.1.1 on 2026-05-20. The vulnerable wpgmp_temp_access_ajax path exposes a support-oriented temporary access feature through admin-ajax.php, relies on a frontend-exposed nonce instead of real authorization, then creates a new WordPress user with the administrator role and returns a passwordless magic-login URL.
The vendor's 9.8 CRITICAL rating matches reality. This is not a theoretical post-auth edge case; it is unauthenticated remote, typically reachable anywhere the WordPress site is reachable, and it ends in full application takeover with almost no attacker friction. The only real downward pressure is population size: this is a premium plugin with roughly 15.8K sales, not a core WordPress bug or a 1M-install plugin. Active exploitation wipes out most arguments for downgrading.
4 steps from start to impact.
Pull the exposed nonce from the public site
curl, or Burp Suite, the attacker requests any frontend page and extracts the fc-call-nonce value exposed through the localized wpgmp_local JavaScript object. The plugin treated this nonce like access control, but the nonce is visible to unauthenticated visitors.- Target site runs WP Maps Pro <= 6.1.0
- Attacker can reach the public website over HTTP/S
- Very little; the nonce is intentionally exposed client-side
- If the site is behind strict origin controls or maintenance mode, discovery may slow down but not fundamentally stop exploitation
admin-ajax.php POSTs.Trigger admin creation through admin-ajax.php
/wp-admin/admin-ajax.php using the wpgmp_temp_access_ajax action and check_temp=false. Tools as simple as curl, Burp Repeater, or a one-off Python script are enough; no exploit framework is required.- Valid exposed nonce
- The AJAX action is still registered with
wp_ajax_nopriv_
- A tuned WAF or Wordfence Premium/Care/Response can block this path
- Reverse proxies that rate-limit or challenge automation may reduce mass exploitation but not targeted exploitation
/wp-admin/admin-ajax.php with action names tied to WP Maps Pro, especially from new IPs or user agents that never load normal content.Redeem the returned magic-login URL
fc_user_* account with the administrator role, stores a login token, and returns a magic URL. Visiting that URL invokes WordPress auth cookie creation, immediately landing the attacker in an authenticated admin session.- Step 2 succeeds
- No secondary application control blocks the login-link flow
- Very little; this bypasses normal password and MFA expectations at the WordPress layer
- Security plugins that alert on admin creation may detect after the fact, not before the first login
fc_user_* or unexpected administrator accounts, plus immediate login from a new source IP.Use WordPress admin to persist and monetize
/wp-admin/, the attacker can install a malicious plugin, edit theme files, change site content, add SEO spam, siphon data, or drop a webshell. The practical outcome is full site takeover and easy persistence, not just a transient login.- Successful administrator session
- Filesystem or plugin installation rights available to WordPress
- Locked-down file permissions or disabled plugin/theme editors reduce easy persistence
- EDR on the host, immutable containers, or read-only deployments can contain stage-two abuse
wp-content.The supporting signals.
| In-the-wild status | Yes. Wordfence reported blocking 2,536 attacks in the past 24 hours on its threat-intel record, and its earlier blog said customers were already being protected from exploitation attempts. |
|---|---|
| KEV status | Not listed in the CISA KEV catalog as of 2026-06-03. That lowers compliance urgency for federal-style KEV workflows, but it does not lower operational urgency because exploitation is already observed. |
| PoC / weaponization | Weaponization is effectively public. Wordfence validated the bug and published technical details; opportunistic attackers are already using simple HTTP requests. Even without a famous GitHub repo, this is curl-grade exploitation. |
| EPSS | 0.00074 from EPSS-linked references is very low, which badly understates current risk. For this CVE, live exploitation evidence matters more than the raw EPSS number. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — the vector fits: internet reachable, no auth, no user interaction, and direct full-site impact. |
| Affected versions | WP Maps Pro / wp-google-map-gold <= 6.1.0. |
| Fixed version | 6.1.1. The vendor change added a current_user_can('manage_options') authorization check to the temporary-access AJAX handler. |
| Exposure / population | This is a premium plugin, not WordPress core. Envato lists roughly 15.8K sales and last updated the item on 2026-05-20. So prevalence is materially lower than mass-market free plugins, but every affected site is usually internet-facing by design. |
| Disclosure timeline | Wordfence says the report was submitted 2026-03-24, vendor notification via Envato happened 2026-05-16, firewall protection shipped 2026-05-18, patch 6.1.1 shipped 2026-05-20, and public write-up appeared 2026-05-28. |
| Researcher / reporting | Bug discovered by David Brown and documented by Wordfence/Defiant. |
noisgate verdict.
The decisive factor is unauthenticated internet-reachable admin creation with confirmed exploitation. The only meaningful brake is narrower deployment because WP Maps Pro is a paid plugin, but that is nowhere near enough to drag this out of CRITICAL when a single HTTP workflow yields full administrator control.
Why this verdict
- No attacker foothold required: baseline vendor 9.8 holds because this is unauthenticated remote against a public WordPress endpoint.
- Exploit chain is short and cheap: the nonce is exposed on the frontend, the vulnerable action is reachable through
admin-ajax.php, and the attacker gets an admin user plus magic login URL with commodity tooling. - Active exploitation overrides soft signals: low EPSS and non-KEV status would normally argue for caution, but observed attacks are stronger evidence than either metric.
- Population narrows slightly: this is a commercial plugin with about 15.8K sales, so I shaved the score a tenth below the vendor baseline rather than inflating it.
Why not higher?
There is no broader platform escape here: the blast radius is the individual WordPress site or tenant running this plugin, not every WordPress deployment everywhere. The premium-plugin footprint is meaningfully smaller than a core or mega-install plugin flaw, so a perfect 10.0 would overstate ecosystem-wide exposure.
Why not lower?
A downgrade would require real friction like authentication, internal-only reachability, role requirements, or hard environmental prerequisites. This bug has none of those in the common case, and attackers are already exploiting it in the wild.
What to do — in priority order.
- Block exploit traffic now — Deploy a WAF or WordPress-layer rule that inspects POSTs to
/wp-admin/admin-ajax.phpfor the WP Maps Pro temporary-access action and blocks them immediately, within hours because active exploitation overrides the normal CRITICAL mitigation clock. - Hunt for rogue administrators — Review WordPress users for unexpected admin accounts, especially
fc_user_*patterns or anything tied to[email protected], and correlate with admin logins and plugin installs immediately, within hours. This matters because patching alone does not remove already-created attacker accounts. - Constrain stage-two persistence — Disable in-dashboard plugin/theme editing where feasible, lock file permissions on
wp-content, and alert on new PHP files or plugin installs immediately, within hours to blunt the post-compromise blast radius if an attacker already landed. - Prefer protected WordPress edge controls — If you already run Wordfence Premium/Care/Response or equivalent virtual patching, verify the protection is active immediately, within hours; this is a useful bridge while patching, not a replacement for it.
- MFA on normal WordPress admin logins does not reliably save you here, because the vulnerable flow creates a magic-login path outside the expected credential flow.
- Relying on nonce secrecy does not help; the nonce is exposed to unauthenticated visitors by the plugin itself.
- Hiding
/wp-login.phpdoes not materially reduce risk because exploitation happens throughadmin-ajax.phpand a generated login URL.
Crowdsourced verification payload.
Run this on the target WordPress host as a user that can read the web root; root is only needed if file permissions are tight. Invoke it with the WordPress path, for example: bash ./check_wp_maps_pro.sh /var/www/html. It inspects the plugin directory, extracts the installed version if possible, and checks for the authorization fix.
#!/usr/bin/env bash
# check_wp_maps_pro.sh
# Detects whether WP Maps Pro (wp-google-map-gold) is vulnerable to CVE-2026-8732.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
if [ "$#" -ne 1 ]; then
echo "Usage: $0 /path/to/wordpress"
echo "UNKNOWN"
exit 2
fi
WP_ROOT="$1"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/wp-google-map-gold"
if [ ! -d "$PLUGIN_DIR" ]; then
echo "UNKNOWN - plugin directory not found: $PLUGIN_DIR"
echo "UNKNOWN"
exit 2
fi
find_main_php() {
local dir="$1"
local f
while IFS= read -r -d '' f; do
if grep -Eiq '^[[:space:]]*Plugin Name:[[:space:]]*WP Maps Pro' "$f" 2>/dev/null; then
echo "$f"
return 0
fi
done < <(find "$dir" -maxdepth 2 -type f -name '*.php' -print0 2>/dev/null)
# Fallbacks for common filenames
for f in "$dir/wp-google-map-gold.php" "$dir/wp-google-map-pro.php" "$dir/index.php"; do
if [ -f "$f" ]; then
echo "$f"
return 0
fi
done
# Last resort: first PHP file
find "$dir" -maxdepth 2 -type f -name '*.php' 2>/dev/null | head -n 1
}
version_lte() {
# returns 0 if $1 <= $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}
MAIN_PHP="$(find_main_php "$PLUGIN_DIR")"
VERSION=""
if [ -n "$MAIN_PHP" ] && [ -f "$MAIN_PHP" ]; then
VERSION="$(grep -Eim1 '^[[:space:]]*Version:[[:space:]]*' "$MAIN_PHP" | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')"
fi
# Look for the patch condition added by vendor.
HAS_FIX=0
if grep -RqsE "current_user_can\s*\(\s*['\"]manage_options['\"]\s*\)" "$PLUGIN_DIR"; then
HAS_FIX=1
fi
if [ -n "$VERSION" ]; then
echo "Detected version: $VERSION"
else
echo "Detected version: unknown"
fi
echo "Authorization fix present: $HAS_FIX"
if [ "$HAS_FIX" -eq 1 ]; then
echo "PATCHED"
exit 0
fi
if [ -n "$VERSION" ]; then
if version_lte "$VERSION" "6.1.0"; then
echo "VULNERABLE"
exit 1
else
echo "PATCHED"
exit 0
fi
fi
echo "UNKNOWN - could not determine version and fix string not found"
echo "UNKNOWN"
exit 2
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.