← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2025-22302 · CWE-862 · Disclosed 2025-01-07

Missing Authorization vulnerability in WP Grids WP Wand ai-content-generation

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

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.

"Internet-reachable, yes—but tiny install base, low-impact abuse, and no exploit heat keep this in backlog territory."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a public WordPress site running WP Wand

An attacker uses WPScan, passive fingerprinting, or manual enumeration to identify a WordPress site with the ai-content-generation plugin installed. The attack only matters if the site is both internet-reachable and running WP Wand <= 1.2.5.
Conditions required:
  • Target WordPress site is exposed to the internet
  • WP Wand plugin is installed
  • Installed version is 1.2.5 or older
Where this breaks in practice:
  • 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
Detection/coverage: Version-based detection is available from Wordfence/WPScan. External scanners may miss it unless they can fingerprint the plugin slug and version.
STEP 02

Call the unprotected plugin action

Using curl, Burp Repeater, or commodity web exploit tooling, the attacker sends requests to the vulnerable plugin endpoint or AJAX handler. Public descriptions say the root cause is a missing capability check on several functions, so the request can execute without the normal WordPress authorization barrier.
Conditions required:
  • The vulnerable function is reachable over HTTP
  • No additional auth, nonce, or role check blocks the request
Where this breaks in practice:
  • 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
Detection/coverage: Web logs can show suspicious admin-ajax.php or plugin-specific requests. Generic DAST may flag broken access control, but coverage is inconsistent without authenticated or plugin-aware testing.
STEP 03

Abuse AI-content functionality

If the request succeeds, the attacker can use the plugin's exposed functionality rather than taking over the whole server. Based on the CVSS and advisory language, the likely outcomes are unauthorized content actions or misuse of the plugin's content-generation features, not full code execution.
Conditions required:
  • The targeted function performs a state-changing action
  • The site owner has configured the plugin with usable settings or API-backed features
Where this breaks in practice:
  • Blast radius is constrained to what the plugin function can do
  • No evidence in the advisories of RCE, database dump, or admin account creation
Detection/coverage: Look for unexpected post creation, content edits, abnormal outbound AI API usage, or plugin-generated artifacts. EDR on the host is unlikely to help unless the abuse cascades into file changes.
STEP 04

Operational impact stays local to the site

The end state is typically spam, unauthorized content generation, brand damage, or API-cost burn on the affected WordPress instance. That is annoying and sometimes business-relevant, but it is not the kind of cross-estate foothold expansion that justifies emergency enterprise patch windows.
Conditions required:
  • The site matters enough for content abuse to have business impact
Where this breaks in practice:
  • Impact is bounded to the affected WordPress site or tenant
  • No known in-the-wild chaining to broader infrastructure compromise
Detection/coverage: Content integrity monitoring, WordPress audit logs, and API billing alerts are more useful than classic network IDS for this step.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in authoritative sources reviewed; not present in CISA KEV.
Proof-of-concept availabilityNo 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.
EPSS0.00135 from the user-provided intel block — extremely low exploit-likelihood signal relative to routinely abused CVEs.
KEV statusNot KEV-listed. CISA's KEV catalog is the authoritative source for known exploitation tracking, and this CVE does not appear there.
CVSS vectorCVSS: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 versionsWP Wand / ai-content-generation <= 1.2.5.
Fixed version1.2.6. WordPress.org changelog for 1.2.6 says security related issues were fixed.
Exposure populationWordPress.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 timelineCVE 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 / reporterDhabaleshwar Das via the Patchstack Bug Bounty Program / Patchstack Alliance.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

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.

MEDIUM Severity reassessment
HIGH Affected version and fixed version mapping
MEDIUM Real-world exposure assessment

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

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. Restrict public access to WordPress action endpoints — Use WAF or web-server rules to reduce unauthenticated access to wp-admin/admin-ajax.php and 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.
  3. 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.
  4. Inventory WordPress plugins centrally — Use WP-CLI, agent-based file inventory, or your CMDB to enumerate ai-content-generation versions across estates. This is the fastest way to turn a fuzzy internet bug into a precise host-level remediation list.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: inventory every WordPress host for 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

  1. OpenCVE record for CVE-2025-22302
  2. WordPress.org plugin page for WP Wand
  3. WordPress.org advanced view for WP Wand
  4. Wordfence vulnerability entry for CVE-2025-22302
  5. Wordfence weekly report including CVE-2025-22302
  6. WPScan vulnerability entry
  7. Patchstack advisory
  8. CISA Known Exploited Vulnerabilities Catalog
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.