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.
4 steps from start to impact.
Fingerprint a reachable AWP Classifieds site
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.- Target runs WordPress with AWP Classifieds installed
- The site is internet-reachable
- A vulnerable plugin version is present
- The plugin is niche at roughly 3,000 active installs
- Not every deployment exposes the region workflow publicly
- Some sites suppress easy plugin fingerprinting
regions code path is actually reachable.Trigger the vulnerable regions[] key path
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.- The request reaches a page/action that consumes
regionsinput - No authentication is required for that path
- The app passes attacker-controlled keys into SQL construction
- A WAF or managed WordPress firewall may block crude payloads
- The exact request shape may require manual tuning before
sqlmapsucceeds - If the region feature is disabled or not queried, exploitation may fail
Extract data from the WordPress database
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.- Database responses or timing differences are observable
- The injected query has sufficient read reach through the app's DB account
- 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
Turn database disclosure into follow-on compromise
- Sensitive data exists in reachable tables
- The attacker can operationalize the stolen data
- Modern password hashing slows immediate credential recovery
- Credential reuse is inconsistent across users
- Impact may stay local to a single WordPress tenant
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | 0.00199 (user-provided). That is low and supports a downgrade from 'internet-wide fire drill' thinking. |
| KEV status | Not KEV-listed. No CISA due date pressure, no authoritative sign of confirmed field exploitation. |
| CVSS vector | CVSS: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 versions | CNA/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 versions | Conservative 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 population | WordPress.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 data | No 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 / researcher | Wordfence 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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. - Virtual-patch the
regionsparameter — Deploy a WAF or managed WordPress firewall rule that blocks suspiciousregions[...]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. - 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.
- Review for compromise indicators — Search web logs, WAF logs, and database access anomalies for requests containing nested
regionsparameters, 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.
- MFA on
/wp-admindoes 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.
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.
#!/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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.