← Back to Feed CACHED · 2026-10-01 18:54:45 · CACHE_KEY CVE-2026-10083
CVE-2026-10083 · CWE-79 · Disclosed 2026-06-29

APCu Manager < 4.5.0 Unauthenticated Stored XSS via Cache Key Pollution

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like leaving a tripwire in a room nobody visits, inside a building most people don't have keys to

CVE-2026-10083 is a stored cross-site scripting (XSS) flaw in the APCu Manager WordPress plugin, versions prior to 4.5.0. The plugin renders APCu object-cache keys on its admin-area Tools page without escaping them. An unauthenticated attacker can poison a cache key — typically by abusing a *second* co-installed plugin that creates WordPress transients from raw user input via an unauthenticated AJAX endpoint — and inject a JavaScript payload (e.g., <svg/onload=alert(1)>) that fires when an administrator navigates to the APCu Manager Tools page. Successful exploitation yields JavaScript execution in the admin's browser session, which can be escalated to full WordPress admin-account takeover, backdoor plugin installation, and site compromise.

The vendor CVSS of 7.5 HIGH (AC:H/PR:N/UI:R) overestimates real-world risk significantly. The score correctly flags the unauthenticated entry point and the admin-session impact, but it cannot express the compounding gate conditions: the plugin has only ~10,000 active installations globally, the PHP APCu extension must be installed and enabled (non-default on most hosting), a persistent object cache must be active, a *separate* plugin must create cache keys from unsanitized unauthenticated input, and the admin must specifically visit the niche APCu Manager page. Each gate dramatically narrows the exploitable population. The impact ceiling is a single WordPress instance — there is no domain, fleet, or supply-chain multiplier. A MEDIUM 4.5 assessment better reflects the real-world exposure.

"Niche WP plugin XSS with 10K installs and a 4-gate chain — downgrade to MEDIUM"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify target running APCu Manager < 4.5.0

The attacker fingerprints the WordPress site to confirm APCu Manager is installed and running a version below 4.5.0. This can be done passively via plugin enumeration tools like WPScan or by probing known plugin asset paths (/wp-content/plugins/apcu-manager/). The attacker must also confirm that the APCu PHP extension is active and the site uses APCu as its persistent object-cache backend.
Conditions required:
  • Target site runs WordPress with APCu Manager < 4.5.0
  • PHP APCu extension installed and enabled on the server
  • APCu configured as the persistent object-cache backend
Where this breaks in practice:
  • Only ~10,000 sites globally run this plugin
  • APCu extension is not installed by default on most shared/managed WordPress hosting
  • Many WordPress sites use Redis or Memcached instead of APCu for object caching
Detection/coverage: WPScan, Wordfence, and Sucuri can enumerate installed plugin versions. No GreyNoise/Shodan tag exists for APCu Manager specifically.
STEP 02

Locate an unauthenticated cache-key injection vector

The attacker needs a *second* co-installed plugin or theme that creates a WordPress transient (which maps to an APCu cache key when APCu is the object-cache backend) from unsanitized user-supplied input via an unauthenticated endpoint. The WPScan PoC demonstrates this using an AJAX action that accepts a roles parameter and writes it directly into a transient name. The attacker must discover such an endpoint on the target site.
Conditions required:
  • A second plugin or theme must exist on the site that writes transients from unauthenticated user input
  • That plugin must expose an AJAX or REST endpoint reachable without authentication
Where this breaks in practice:
  • This co-dependency on a second vulnerable plugin drastically narrows the exploitable population
  • Most well-maintained plugins sanitize transient names
  • Identifying the right endpoint requires reconnaissance or prior knowledge of the site's plugin stack
Detection/coverage: WAFs with WordPress rulesets (Wordfence, Sucuri, Cloudflare WordPress rules) may flag unusual AJAX requests with injection patterns in parameter values.
STEP 03

Poison the APCu cache with a stored XSS payload

The attacker sends a crafted unauthenticated request to the identified AJAX endpoint, embedding a JavaScript payload in the parameter that becomes part of the transient/cache key. For example: roles=APCMXSS"><svg/onload=alert(document.cookie)>. The APCu object cache stores the poisoned key. A nonce may need to be scraped from a public-facing page first, depending on the target endpoint's protections.
Conditions required:
  • Successful identification of the injection endpoint from Step 2
  • Ability to reach the AJAX endpoint from the internet (no IP-based access control)
Where this breaks in practice:
  • If the target endpoint requires a valid nonce, the attacker must find a page that leaks it — not all endpoints do
  • Some hosting providers restrict AJAX endpoints behind additional authentication or rate limiting
Detection/coverage: WAF signatures for <svg/onload, <img/onerror, and similar XSS vectors in POST parameters should catch most payloads. ModSecurity CRS OWASP rules cover this pattern.
STEP 04

Wait for admin to visit APCu Manager Tools page

The poisoned cache key now sits in APCu memory. The XSS payload only fires when a WordPress administrator navigates to the APCu Manager admin page (typically Tools → APCu Manager or the plugin's analytics dashboard). The plugin renders all cache keys in HTML without escaping, causing the injected <svg/onload=...> to execute in the admin's authenticated browser session.
Conditions required:
  • An administrator must visit the specific APCu Manager page
  • The poisoned cache key must still be in APCu memory (not evicted by TTL or memory pressure)
Where this breaks in practice:
  • APCu Manager is a niche diagnostic tool — admins may visit it rarely (weekly, monthly, or never)
  • APCu cache keys can be evicted by TTL expiry or memory pressure before the admin visits
  • Content Security Policy (CSP) headers with strict script-src will block inline script execution
Detection/coverage: Browser-level XSS auditors (now deprecated in Chromium) offer no protection. CSP violation reports would flag the execution. Wordfence's real-time firewall does not inspect rendered admin pages.
STEP 05

Escalate XSS to admin takeover

With JavaScript executing in the admin's browser session, the attacker can leverage the WordPress REST API or admin-ajax to create a new administrator account, install a malicious plugin containing a webshell, or exfiltrate the admin's session cookies. Standard WordPress XSS-to-RCE chains (e.g., injecting a plugin zip via the Plugin Editor or upload endpoint) are well-documented and can be automated in the payload. The blast radius is limited to the single WordPress instance.
Conditions required:
  • Successful XSS execution from Step 4
  • No additional MFA or re-authentication on sensitive admin actions (WordPress default: none)
Where this breaks in practice:
  • WordPress security plugins like Wordfence, iThemes Security, or Shield may require re-authentication for user creation or plugin installation
  • Some hosting platforms (WP Engine, Pantheon) restrict plugin uploads via the admin UI
Detection/coverage: Wordfence and Sucuri can alert on new admin user creation or plugin installation events. Activity log plugins (WP Activity Log) record these actions.
03 · Compensating Control

1
MEDIUM 4.5→IGNORE 0.0
SEVERITY REDUCED
Update APCu Manager to 4.5.0+ — The definitive fix. Version 4.5.0 escapes cache keys before rendering. Current version is 4.6.1. As a MEDIUM verdict, no noisgate mitigation SLA applies — go straight to the 365-day noisgate remediation SLA. Given the low urgency, bundle this with your next scheduled WordPress plugin update cycle.
2
MEDIUM 4.5→LOW 2.5
SEVERITY REDUCED
Deploy Content Security Policy headers with strict script-src — Add Content-Security-Policy: script-src 'self' (no unsafe-inline) to the WordPress admin area via your reverse proxy or a security plugin. This blocks inline <svg/onload> and similar XSS payloads from executing even if injected. Effective within the 365-day remediation window.
3
MEDIUM 4.5→LOW 2.0
SEVERITY REDUCED
Restrict APCu Manager admin page access via IP allowlist — Use .htaccess, nginx location blocks, or a WordPress security plugin to limit access to the APCu Manager Tools page (/wp-admin/tools.php?page=apcu-manager*) to known admin IPs. This prevents the XSS from firing even if the cache is poisoned, because the admin page is unreachable from attacker-controlled browsers.
4
MEDIUM 4.5→LOW 3.0
SEVERITY REDUCED
Enable a WAF with WordPress XSS rulesets — Wordfence Premium, Sucuri WAF, or Cloudflare WordPress rules will detect and block XSS payloads in AJAX POST parameters (<svg/onload, <img/onerror, javascript: patterns). This breaks the chain at Step 3 (cache poisoning). Deploy within the 365-day remediation window if not already in place.
5
MEDIUM 4.5→IGNORE 0.0
SEVERITY REDUCED
Deactivate APCu Manager if not actively used — If APCu Manager is installed for occasional diagnostics and not critical to operations, deactivate or uninstall it entirely. This eliminates the vulnerable rendering code. Many sites install it once for troubleshooting and forget it.
What doesn't work
  • WordPress admin MFA — MFA protects login but does not prevent XSS from executing in an already-authenticated admin session. The payload runs inside the admin's browser after they have already passed MFA.
  • Rate limiting on AJAX endpoints — The cache poisoning requires only a single request. Rate limiting would not prevent a one-shot injection.
  • Disabling XML-RPC — This vulnerability uses wp-admin AJAX endpoints, not XML-RPC. Disabling XML-RPC has no effect on this attack path.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed. Not listed in CISA KEV. No GreyNoise tags or Shodan honeypot hits referencing this CVE. No campaigns documented by Wordfence, Sucuri, Fastly, or Patchstack as of 2026-10-02.
Proof of conceptAvailable — moderate quality. WPScan advisory e591b3f3 includes a step-by-step PoC (nonce scraping → AJAX cache poisoning → admin page trigger). No standalone GitHub repo named CVE-2026-10083 found. Not indexed on pocindex.io. Researchers: Alessandro Greco (Aleff) and Giovanbattista Ianni (University of Calabria — UNICAL).
EPSS0.00352 (0.35%) — bottom quartile. Indicates extremely low predicted exploitation probability over the next 30 days.
KEV statusNot listed. No CISA KEV entry as of 2026-10-02.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 HIGH. AC:H reflects the multi-gate prerequisites; UI:R captures the admin-page-visit requirement; S:U correctly scopes impact to the vulnerable component (no cross-scope). C/I/A:H is generous for XSS but defensible if admin takeover → webshell is assumed.
Affected versionsAPCu Manager < 4.5.0 on WordPress 6.4+ with PHP 8.2+ and the APCu extension enabled as persistent object-cache backend.
Fixed version4.5.0 (released ~June 2026). Current latest is 4.6.1 (August 18, 2026). No distro backports relevant — this is a WordPress.org-distributed plugin.
Installed base~10,000 active installations per WordPress.org plugin directory. For comparison, major WP plugins (LiteSpeed Cache, Yoast) have 5M+. This is a niche operations/diagnostics tool.
Disclosure timelineReported by Alessandro Greco (Aleff) and Giovanbattista Ianni. WPScan advisory published June 8, 2026. NVD entry published June 29, 2026. Plugin patched in 4.5.0.
Scanning / exposureNo Shodan/Censys/FOFA dork reliably identifies APCu Manager specifically. WordPress plugin enumeration (WPScan --enumerate p) detects the plugin. The plugin's admin page is only accessible to authenticated WordPress administrators — not internet-facing.

Sources.

  1. WPScan Advisory — APCu Manager < 4.5.0 Stored XSS
  2. NVD — CVE-2026-10083
  3. OpenCVE — CVE-2026-10083
  4. WordPress.org — APCu Manager Plugin Page
  5. CyberStrike — CVE-2026-10083 Detail
  6. GitHub — Pierre-Lannoy/wp-apcu-manager
  7. Fastly — Active Exploitation of WP Stored XSS Vulnerabilities
  8. Hol — CVE-2026-10083 Analysis
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (4.5/10)

Why this verdict

  • Tiny installed base: Only ~10,000 active installations globally. The total addressable attack surface is negligible compared to mainstream WordPress plugins with 100K–5M+ installs. An attacker scanning the internet for this specific niche plugin will find very few targets.
  • Multi-prerequisite chain compounds failure probability: The chain requires (1) APCu extension installed, (2) APCu as object-cache backend, (3) a *second* co-installed plugin that writes unsanitized unauthenticated input into transient names, and (4) admin visiting the specific APCu Manager page before cache eviction. Each gate independently eliminates a large fraction of the already-small installed base.
  • XSS, not direct RCE — impact ceiling is one WordPress instance: Even a fully successful chain yields admin-session JavaScript execution on a single site. There is no lateral movement to domain controllers, no fleet-scale impact, and no supply-chain pivot. The blast radius is bounded to the compromised WordPress instance.
  • No exploitation evidence supports deferral: EPSS of 0.35%, no KEV listing, no GreyNoise/Shodan scanning activity, no documented campaigns. The PoC exists in the WPScan advisory but has not been weaponized at scale.
  • Role multiplier: WordPress with APCu Manager is not a high-value-role component. It is not an identity provider, hypervisor, CI/CD system, backup solution, network edge appliance, or domain controller. In (a) low-value roles (dev blogs, personal sites), compromise is inconsequential. In (b) typical roles (business marketing sites), compromise is contained to that site. In (c) the closest high-value role — an enterprise CMS hosting regulated content — the chain still terminates at single-site admin takeover with no domain/fleet/supply-chain escalation. No blast-radius floor applies.

Why not higher?

The vendor's HIGH/7.5 implies broad, readily exploitable risk. In practice, the chain requires four independent preconditions on a plugin with only 10,000 installs. Stored XSS in admin context is serious *if* it fires, but the probability of all gates aligning in a real deployment is very low. WordPress sites are not high-value-role infrastructure, so no blast-radius floor elevates the score. EPSS at 0.35% independently corroborates low real-world risk.

Why not lower?

A working PoC with clear steps exists in the WPScan advisory — exploitation is not theoretical. The injection is unauthenticated (PR:N), which is a meaningful advantage for attackers. Stored XSS → admin takeover is a well-proven escalation path in the WordPress ecosystem, with documented mass-exploitation campaigns against similar bugs in other plugins (CVE-2024-2194, CVE-2023-40000). The AC:H rating already reflects some complexity, but the attack is still network-reachable without credentials, which keeps it above LOW.

06 · Verification

Crowdsourced verification payload.

Run this script on the WordPress host (or any machine with SSH/file access to the WordPress installation directory). Invoke as: bash check_cve_2026_10083.sh /var/www/html/wordpress. Requires read access to the WordPress wp-content/plugins directory. No root needed.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_10083.sh — Detect CVE-2026-10083 (APCu Manager < 4.5.0 Stored XSS)
# Usage: bash check_cve_2026_10083.sh /path/to/wordpress
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/apcu-manager"
MAIN_FILE="$PLUGIN_DIR/apcu-manager.php"
FIXED_MAJOR=4
FIXED_MINOR=5
FIXED_PATCH=0

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "PATCHED — APCu Manager plugin is not installed at $PLUGIN_DIR"
  exit 0
fi

if [ ! -f "$MAIN_FILE" ]; then
  echo "UNKNOWN — Plugin directory exists but main file not found: $MAIN_FILE"
  exit 2
fi

# Extract version from the plugin header
VERSION=$(grep -i '^[[:space:]]*\*[[:space:]]*Version:' "$MAIN_FILE" | head -1 | sed 's/.*Version:[[:space:]]*//' | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not extract version from $MAIN_FILE"
  exit 2
fi

# Parse major.minor.patch
IFS='.' read -r VMAJ VMIN VPAT <<< "$VERSION"
VMAJ=${VMAJ:-0}
VMIN=${VMIN:-0}
VPAT=${VPAT:-0}

echo "Detected APCu Manager version: $VERSION"

if [ "$VMAJ" -gt "$FIXED_MAJOR" ] 2>/dev/null; then
  echo "PATCHED — Version $VERSION >= 4.5.0"
  exit 0
elif [ "$VMAJ" -eq "$FIXED_MAJOR" ] 2>/dev/null; then
  if [ "$VMIN" -gt "$FIXED_MINOR" ] 2>/dev/null; then
    echo "PATCHED — Version $VERSION >= 4.5.0"
    exit 0
  elif [ "$VMIN" -eq "$FIXED_MINOR" ] 2>/dev/null; then
    if [ "$VPAT" -ge "$FIXED_PATCH" ] 2>/dev/null; then
      echo "PATCHED — Version $VERSION >= 4.5.0"
      exit 0
    fi
  fi
fi

echo "VULNERABLE — APCu Manager $VERSION is below 4.5.0 (CVE-2026-10083)"
exit 1