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

The AWP Classifieds plugin for WordPress is vulnerable to SQL Injection via the 'regions' parameter array…

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

It’s a storefront search box that accidentally routes customer input straight into the cash-register ledger

CVE-2026-5100 is an *unauthenticated* SQL injection in the WordPress plugin AWP Classifieds. The vulnerable input is the regions parameter *array keys*, which means an attacker does not need a login if they can reach a page that exercises the plugin’s region-filtering logic. The CNA/NVD description says versions up to and including 4.4.5 are affected, but multiple downstream sources and the plugin changelog point to 4.4.6.1 as the first clearly fixed release, so the safe defender assumption is that anything below 4.4.6.1 is exposed.

Vendor severity at 7.5/HIGH is basically fair. The amplifier is obvious: this is pre-auth web exploitation against a typically internet-facing CMS. The downward pressure is also obvious: the plugin has only about 3,000 active installs, there is no KEV listing, the provided EPSS is 0.00199, and the likely impact is database disclosure rather than turnkey server takeover. For a fleet operator, this is a sharp but *niche* edge: patchable, important, and worth real attention, just not a panic-grade ecosystem event.

"Pre-auth SQLi on a public WordPress plugin is serious, but the small install base and no abuse evidence keep it HIGH, not CRITICAL."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Fingerprint a reachable AWP Classifieds site

An attacker first identifies WordPress plus the another-wordpress-classifieds-plugin footprint using standard recon such as Wappalyzer, WhatWeb, browser source inspection, or direct asset probing under /wp-content/plugins/another-wordpress-classifieds-plugin/. They then look for listing or search pages where the plugin’s region selector is exposed or still processed server-side.
Conditions required:
  • Target runs WordPress with AWP Classifieds installed
  • The site is internet-reachable
  • A vulnerable plugin version is present
Where this breaks in practice:
  • The plugin is niche at roughly 3,000 active installs
  • Not every deployment exposes the region workflow publicly
  • Some sites suppress easy plugin fingerprinting
Detection/coverage: External scanners can usually detect WordPress and sometimes the plugin slug, but they often miss whether the vulnerable regions code path is actually reachable.
STEP 02

Trigger the vulnerable regions[] key path

Using Burp Suite or sqlmap, the attacker sends crafted requests that abuse the array keys of regions, not just the values. That matters operationally because many defensive regexes focus on obvious scalar parameters and miss malformed array-key injection patterns.
Conditions required:
  • The request reaches a page/action that consumes regions input
  • No authentication is required for that path
  • The app passes attacker-controlled keys into SQL construction
Where this breaks in practice:
  • A WAF or managed WordPress firewall may block crude payloads
  • The exact request shape may require manual tuning before sqlmap succeeds
  • If the region feature is disabled or not queried, exploitation may fail
Detection/coverage: Signature-based web protections may catch classic SQLi metacharacters, but coverage is inconsistent for nested parameter and array-key abuse.
STEP 03

Extract data from the WordPress database

Once injection is confirmed, sqlmap can pivot into schema discovery and data extraction. The realistic prize is WordPress data: user emails, password hashes, configuration details, ad/listing metadata, and potentially secrets stored in plugin or site tables.
Conditions required:
  • Database responses or timing differences are observable
  • The injected query has sufficient read reach through the app's DB account
Where this breaks in practice:
  • Blind or time-based extraction can be slow and noisy
  • Least-privileged DB accounts reduce blast radius
  • Some hosts front WordPress with rate limiting or bot controls
Detection/coverage: Application logs, WAF telemetry, and unusual repeated requests to classifieds/search endpoints are your best signals; generic endpoint vulnerability scans may only prove version exposure, not successful data access.
STEP 04

Turn database disclosure into follow-on compromise

The attacker may crack leaked password hashes offline, reuse exposed credentials elsewhere, or use admin email/user intel for targeted phishing. This is where a 'read-only' SQLi still becomes an enterprise problem even without direct code execution.
Conditions required:
  • Sensitive data exists in reachable tables
  • The attacker can operationalize the stolen data
Where this breaks in practice:
  • Modern password hashing slows immediate credential recovery
  • Credential reuse is inconsistent across users
  • Impact may stay local to a single WordPress tenant
Detection/coverage: This phase shifts from web logs to IAM, mail security, and credential monitoring; the original SQLi is often the only clean on-box precursor.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in reviewed primary sources and not in CISA KEV as of the catalog source reviewed. That lowers urgency versus mass-exploited WordPress bugs.
Proof-of-concept availabilityNo mature public PoC repo surfaced in reviewed GitHub/Exploit-DB searches. That said, the bug class is straightforward enough that Burp Suite or sqlmap should be sufficient once the right endpoint is identified.
EPSS0.00199 (user-provided). That is low and supports a downgrade from 'internet-wide fire drill' thinking.
KEV statusNot KEV-listed. No CISA due date pressure, no authoritative sign of confirmed field exploitation.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — easy remote reach, no auth, no user click, but the modeled impact is confidentiality-heavy rather than direct integrity/availability loss.
Affected versionsCNA/NVD description says up to and including 4.4.5. Wordfence plugin overview and WPScan/Patchstack indicate the practical vulnerable range is below 4.4.6.1, so defenders should treat 4.4.6 as suspect and remediate to 4.4.6.1+.
Fixed versionsConservative fix floor is 4.4.6.1 based on WPScan, Patchstack, and the WordPress.org changelog entry showing 'Security Improvements' in 4.4.6.1.
Exposure populationWordPress.org and WPScan both show about 3,000 active installs. That's real exposure, but nowhere near the population you see in plugin mega-incidents.
Scanning / exposure dataNo reliable internet-wide fingerprint data from Shodan/Censys/FOFA appeared in reviewed sources; for this plugin, active-install count is the better exposure proxy. *Inference:* reachable population is materially smaller than generic WordPress counts.
Disclosure timeline / researcherWordfence shows publicly published May 4, 2026 and credits Hunter Jensen (skid). NVD shows published May 4, 2026 and last modified May 5, 2026; Patchstack published its entry on May 5, 2026.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.2/10)

The decisive factor is that this is unauthenticated web exploitation on an internet-facing CMS path, so it remains firmly above MEDIUM. It stops short of CRITICAL because the reachable population is narrow, there is no KEV or public exploitation signal in the reviewed sources, and the direct impact is data extraction rather than reliable server takeover.

HIGH Attack preconditions and exploitability class
MEDIUM Exact vulnerable upper bound because sources disagree between 4.4.5 and 4.4.6.1
MEDIUM Observed real-world exploitation likelihood

Why this verdict

  • Baseline stays high: vendor 7.5 fits the core fact pattern — remote, unauthenticated SQLi against a public web app path.
  • Downward adjustment for exposure population: the plugin is only about 3,000 active installs, so this is not a broad WordPress ecosystem event.
  • Downward adjustment for threat intel: no KEV listing, no reviewed public exploitation evidence, and EPSS 0.00199 argue against elevating to CRITICAL.
  • Downward adjustment for blast radius: the modeled impact is mainly database disclosure on the affected site or tenant, not immediate RCE across the host estate.
  • No bigger downgrade because attacker position is still ideal: this does not require prior compromise, internal access, authentication, or a privileged role.

Why not higher?

CRITICAL needs either a wider exposed population, stronger field-exploitation evidence, or a more direct path to full server compromise. Here, the product is niche, the public threat signals are weak, and the likely first-order impact is data theft from a specific WordPress instance.

Why not lower?

This is still pre-auth web exploitation against software that is commonly deployed on public websites. A low- or medium-severity rating would understate the risk because the attacker does not need credentials, user interaction, or internal foothold to start pulling data.

05 · Compensating Control

What to do — in priority order.

  1. Upgrade to 4.4.6.1 or later — Apply the vendor fix on every site running another-wordpress-classifieds-plugin. For a HIGH verdict, complete this within 30 days if no faster business process applies; given the source mismatch on the upper affected version, do not stop at 4.4.6.
  2. Virtual-patch the regions parameter — Deploy a WAF or managed WordPress firewall rule that blocks suspicious regions[...] key manipulation and common SQLi metacharacters on classifieds/search routes. Use this as immediate exposure reduction and have it in place within 30 days if patching lags.
  3. Restrict public reach to classifieds endpoints — If the business can tolerate it, temporarily geo-fence, IP-allowlist, or disable the vulnerable classifieds/search pages that process region filters. This is especially useful for low-traffic internal or partner-facing sites and should be done within 30 days where patching cannot be immediate.
  4. Review for compromise indicators — Search web logs, WAF logs, and database access anomalies for requests containing nested regions parameters, quote characters, boolean conditions, or timing-probe patterns. Do this now to separate 'just exposed' from 'already touched' before the 30-day remediation window closes.
What doesn't work
  • MFA on /wp-admin does not help because the flaw is unauthenticated.
  • EDR alone is weak coverage here because the initial abuse is application-layer SQLi, not a host-execution event.
  • Hiding WordPress version banners or changing login URLs does not remove the vulnerable public code path.
06 · Verification

Crowdsourced verification payload.

Run this on the target WordPress host or in the container/VM that holds the site files. Invoke it as bash verify-awp-classifieds-cve-2026-5100.sh /var/www/html or point it directly at the plugin directory; it only needs read access to the plugin files, not root.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# verify-awp-classifieds-cve-2026-5100.sh
# Checks whether the installed AWP Classifieds plugin version is vulnerable to CVE-2026-5100.
# Conservative logic: treat versions < 4.4.6.1 as VULNERABLE due to source disagreement.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-.}"
PLUGIN_DIR=""
PLUGIN_MAIN=""
VERSION=""

find_plugin_dir() {
  local base="$1"
  if [ -d "$base/wp-content/plugins/another-wordpress-classifieds-plugin" ]; then
    echo "$base/wp-content/plugins/another-wordpress-classifieds-plugin"
    return 0
  fi
  if [ -d "$base/another-wordpress-classifieds-plugin" ]; then
    echo "$base/another-wordpress-classifieds-plugin"
    return 0
  fi
  if [ -d "$base" ] && [ -f "$base/awpcp.php" ]; then
    echo "$base"
    return 0
  fi
  return 1
}

version_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

extract_version() {
  local dir="$1"
  local main="$dir/awpcp.php"
  local readme="$dir/readme.txt"
  local v=""

  if [ -f "$main" ]; then
    v=$(grep -Eim1 '^[[:space:]]*Version:[[:space:]]*[0-9]+([.][0-9A-Za-z-]+)*' "$main" | sed -E 's/^[[:space:]]*Version:[[:space:]]*//I' | tr -d '\r')
    if [ -n "$v" ]; then
      echo "$v"
      return 0
    fi
  fi

  if [ -f "$readme" ]; then
    v=$(grep -Eim1 '^[[:space:]]*Stable tag:[[:space:]]*[0-9]+([.][0-9A-Za-z-]+)*' "$readme" | sed -E 's/^[[:space:]]*Stable tag:[[:space:]]*//I' | tr -d '\r')
    if [ -n "$v" ]; then
      echo "$v"
      return 0
    fi
  fi

  return 1
}

if ! PLUGIN_DIR=$(find_plugin_dir "$TARGET"); then
  echo "UNKNOWN - AWP Classifieds plugin directory not found from target: $TARGET"
  exit 2
fi

PLUGIN_MAIN="$PLUGIN_DIR/awpcp.php"

if ! VERSION=$(extract_version "$PLUGIN_DIR"); then
  echo "UNKNOWN - Could not determine installed plugin version in: $PLUGIN_DIR"
  exit 2
fi

PATCH_FLOOR="4.4.6.1"

if version_lt "$VERSION" "$PATCH_FLOOR"; then
  echo "VULNERABLE - AWP Classifieds version $VERSION is below patched floor $PATCH_FLOOR (CVE-2026-5100)"
  exit 1
else
  echo "PATCHED - AWP Classifieds version $VERSION is at or above $PATCH_FLOOR"
  exit 0
fi
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: identify every WordPress site with another-wordpress-classifieds-plugin, assume anything below 4.4.6.1 is exposed, and either patch or put a WAF/route block in front of the classifieds region-filter path. For this HIGH verdict, the noisgate mitigation SLA is within 30 days for compensating controls if patching is delayed, and the noisgate remediation SLA is within 180 days for the actual vendor fix; in practice, because this is pre-auth SQLi on public web software, mature teams should finish the patch well before the outer 180-day window.

Sources

  1. NVD CVE-2026-5100
  2. Wordfence vulnerability entry
  3. Wordfence plugin overview
  4. WordPress.org plugin page and changelog
  5. Patchstack advisory
  6. WPScan plugin vulnerability listing
  7. FIRST EPSS API documentation
  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.