CVE-2026-5100 · AWP Classifieds for WordPress unauthenticated SQL injection via…

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 · Compensating Control

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

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

04 · Intelligence Metadata

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.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.2/10)

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.

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