This is a side door left unlocked on a small office, not a master key to the building
CVE-2025-22302 is a missing authorization flaw in the WordPress plugin WP Wand (ai-content-generation) affecting versions through 1.2.5 and fixed in 1.2.6. Public advisories describe missing capability checks on several plugin functions, meaning an unauthenticated remote attacker can hit plugin functionality they should not be allowed to use. In practical terms, that usually means abusing AI-content actions, generating or altering content-related workflow, or driving unwanted API consumption on sites that expose the plugin.
The vendor's 5.3/MEDIUM rating is defensible in a vacuum because the bug is network-reachable and requires no auth, but it still overstates enterprise urgency. The real-world brakes are strong: the plugin only shows 1,000+ active installs, the impact is scored integrity-low only with no confidentiality or availability impact, and there is no KEV listing, no public exploitation signal, and a very low EPSS. For a team managing 10,000 hosts, this is not where you spend your scarce emergency patching energy.
4 steps from start to impact.
Find a public WordPress site running WP Wand
ai-content-generation plugin installed. The attack only matters if the site is both internet-reachable and running WP Wand <= 1.2.5.- Target WordPress site is exposed to the internet
- WP Wand plugin is installed
- Installed version is 1.2.5 or older
- WordPress.org reports only 1,000+ active installs, so reachable population is small
- Many enterprises do not expose niche AI-content plugins on business-critical estates
- Reliable internet-wide fingerprinting for exact plugin version is poor
Call the unprotected plugin action
- The vulnerable function is reachable over HTTP
- No additional auth, nonce, or role check blocks the request
- WordPress security plugins, WAF rules, or custom hardening may block noisy AJAX abuse
- Some plugin actions may still require valid workflow context or expected parameters
admin-ajax.php or plugin-specific requests. Generic DAST may flag broken access control, but coverage is inconsistent without authenticated or plugin-aware testing.Abuse AI-content functionality
- The targeted function performs a state-changing action
- The site owner has configured the plugin with usable settings or API-backed features
- Blast radius is constrained to what the plugin function can do
- No evidence in the advisories of RCE, database dump, or admin account creation
Operational impact stays local to the site
- The site matters enough for content abuse to have business impact
- Impact is bounded to the affected WordPress site or tenant
- No known in-the-wild chaining to broader infrastructure compromise
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in authoritative sources reviewed; not present in CISA KEV. |
|---|---|
| Proof-of-concept availability | No widely circulated public PoC located for this exact CVE. Public writeups describe the bug as missing capability checks on several functions, which makes private reproduction straightforward for an attacker with basic web testing skills. |
| EPSS | 0.00135 from the user-provided intel block — extremely low exploit-likelihood signal relative to routinely abused CVEs. |
| KEV status | Not KEV-listed. CISA's KEV catalog is the authoritative source for known exploitation tracking, and this CVE does not appear there. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N — that means easy remote reachability but only low integrity impact and no confidentiality/availability hit. |
| Affected versions | WP Wand / ai-content-generation <= 1.2.5. |
| Fixed version | 1.2.6. WordPress.org changelog for 1.2.6 says security related issues were fixed. |
| Exposure population | WordPress.org shows only 1,000+ active installations. *Inference:* that is a small reachable population by enterprise prioritization standards, and there is no reliable Shodan/Censys-style exact version census for this plugin. |
| Disclosure timeline | CVE record was published on 2025-01-07; Wordfence lists public publication on 2025-01-06. The difference is normal source timing drift, not a red flag. |
| Researcher / reporter | Dhabaleshwar Das via the Patchstack Bug Bounty Program / Patchstack Alliance. |
noisgate verdict.
The decisive factor is population and blast-radius friction: this is an unauthenticated web bug in a small-footprint WordPress plugin with only low integrity impact. Even though exploitation is technically easy, the affected population is narrow and the outcome is plugin-level abuse rather than a broad enterprise compromise primitive.
Why this verdict
- Downward: narrow reachable population — WordPress.org reports only 1,000+ active installs, so this is not a mass-exposure enterprise mainline like a core CMS or edge appliance flaw.
- Downward: post-exploitation value is limited — the CVSS impact is integrity-low only, with no indication of credential theft, data exfiltration, RCE, or durable host compromise.
- Downward: no exploit heat — no KEV, no public exploitation evidence, and EPSS 0.00135 all argue against emergency treatment.
- Upward: unauthenticated remote path — the attack does not require login, user interaction, or prior foothold, so it cannot be ignored outright.
Why not higher?
If this flaw enabled admin creation, arbitrary file write, secrets exposure, or code execution, the unauthenticated remote nature would push it sharply upward. But the available evidence points to plugin-function abuse with low integrity impact, and that is materially less dangerous than a true takeover bug.
Why not lower?
This is still a real unauthenticated internet-facing authorization failure, not a theoretical code smell. On a public WordPress site using the vulnerable plugin, an attacker can automate abuse cheaply, so it deserves patching in routine maintenance rather than a documentation-only dismissal.
What to do — in priority order.
- Update or remove the plugin — Move affected sites to WP Wand 1.2.6 or later, or remove the plugin if it is not business-critical. For a LOW verdict there is no SLA — treat as backlog hygiene, but do not leave dead plugins installed indefinitely.
- Restrict public access to WordPress action endpoints — Use WAF or web-server rules to reduce unauthenticated access to
wp-admin/admin-ajax.phpand any plugin-specific endpoints where practical, especially on sites that do not need anonymous interactive features. For LOW, there is no mitigation SLA; apply as part of routine hardening. - Watch for content and billing anomalies — Add checks for unexpected post creation, unexplained content edits, and spikes in outbound AI-provider usage or API billing. This catches the most likely business impact while you schedule remediation in normal maintenance.
- Inventory WordPress plugins centrally — Use WP-CLI, agent-based file inventory, or your CMDB to enumerate
ai-content-generationversions across estates. This is the fastest way to turn a fuzzy internet bug into a precise host-level remediation list.
- MFA on WordPress admin logins does not fix this because the flaw is described as unauthenticated missing authorization.
- Network IDS signatures alone are weak here because normal-looking HTTP requests to WordPress AJAX handlers can blend into legitimate traffic.
- Relying on generic perimeter vulnerability scanners is insufficient; many will miss plugin slug/version and broken-access-control logic without WordPress-aware checks.
Crowdsourced verification payload.
Run this on the target WordPress host or on a mounted backup of the site filesystem. Invoke it as sudo bash check_cve_2025_22302_wpwand.sh /var/www/html and give it read access to the WordPress directory; root is only needed if your web content is otherwise unreadable.
#!/usr/bin/env bash
# check_cve_2025_22302_wpwand.sh
# Detects whether WP Wand (ai-content-generation) is vulnerable to CVE-2025-22302.
# Usage: bash check_cve_2025_22302_wpwand.sh /path/to/wordpress
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
TARGET="${1:-}"
PLUGIN_DIR=""
VERSION=""
if [[ -z "$TARGET" ]]; then
echo "UNKNOWN - usage: $0 /path/to/wordpress"
exit 2
fi
if [[ ! -d "$TARGET" ]]; then
echo "UNKNOWN - target path does not exist: $TARGET"
exit 2
fi
PLUGIN_DIR="$TARGET/wp-content/plugins/ai-content-generation"
if [[ ! -d "$PLUGIN_DIR" ]]; then
echo "UNKNOWN - plugin directory not found: $PLUGIN_DIR"
exit 2
fi
version_le() {
# returns 0 if $1 <= $2
local a="$1" b="$2"
[[ "$a" == "$b" ]] && return 0
local first
first=$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)
[[ "$first" == "$a" ]]
}
# 1) Try readme.txt stable tag / version markers
if [[ -f "$PLUGIN_DIR/readme.txt" ]]; then
VERSION=$(grep -Eim1 '^(Stable tag|Version):' "$PLUGIN_DIR/readme.txt" | sed -E 's/^[^:]+:[[:space:]]*//I' | tr -d '\r')
fi
# 2) Try plugin PHP headers if readme parsing failed
if [[ -z "$VERSION" ]]; then
while IFS= read -r -d '' phpfile; do
candidate=$(grep -Eim1 '^\s*Version:\s*' "$phpfile" | sed -E 's/^\s*Version:\s*//I' | tr -d '\r')
if [[ -n "$candidate" ]]; then
VERSION="$candidate"
break
fi
done < <(find "$PLUGIN_DIR" -maxdepth 2 -type f -name '*.php' -print0 2>/dev/null)
fi
# 3) Sanitize version string
VERSION=$(echo "$VERSION" | grep -Eo '[0-9]+(\.[0-9]+){1,3}' | head -n1 || true)
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN - could not determine installed WP Wand version"
exit 2
fi
if version_le "$VERSION" "1.2.5"; then
echo "VULNERABLE - WP Wand version $VERSION is <= 1.2.5"
exit 1
fi
if version_le "1.2.6" "$VERSION" || [[ "$VERSION" == "1.2.6" ]]; then
echo "PATCHED - WP Wand version $VERSION is >= 1.2.6"
exit 0
fi
# Fallback; should be unreachable for normal semantic versions
echo "UNKNOWN - parsed version $VERSION but comparison was inconclusive"
exit 2
If you remember one thing.
ai-content-generation and update any instance at <=1.2.5 during normal plugin maintenance. Because this is a LOW reassessment, there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene — in plain terms, no mitigation SLA; treat it as backlog hygiene and roll the vendor fix into the next routine WordPress update cycle, or remove the plugin outright where unused. If a business-critical public site uses WP Wand and anonymous content abuse would hurt the brand, add temporary WAF restrictions to WordPress action endpoints while you schedule the patch.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.