The WeePie Cookie

CVE-2026-4304 is an unauthenticated SQL injection in the premium WordPress plugin WeePie Cookie Allow via the consent parameter. Affected versions are all releases up to and including 3.4.11, and the vendor changelog shows the fix landed in 3.4.12. In plain terms, an attacker who can reach a site using this plugin may be able to make the application run attacker-controlled database queries and pull sensitive data out of the WordPress database.

The vendor's HIGH 7.5 rating is technically fair in a vacuum because the bug is remote, low-complexity, and requires no authentication. In real enterprise fleets, though, severity comes down because this is a specific premium plugin, not WordPress core, not a ubiquitous internet service, and there is no KEV listing, no strong exploitation evidence, and a very low EPSS signal in the intel you supplied. That makes it a real web-risk for exposed sites, but not an all-hands emergency across a 10,000-host estate.

Why this verdict

• Downgrade for narrow population: this requires a public WordPress site running this exact premium plugin, which is a major reachability filter versus vendor-baseline CVSS.
• No exploit pressure: your supplied intel shows EPSS 0.00089 and the CVE is not in KEV, with no public campaign evidence found in the reviewed sources.
• Confidentiality-only impact: the published scoring does not include integrity or availability loss, and there is no direct RCE in the CVE as described.

Why not higher?

If this were WordPress core, a massively installed free plugin, KEV-listed, or already showing botnet-scale opportunistic exploitation, it would stay HIGH. It does not clear that bar from the evidence available. The biggest brake is that the attacker needs a site running a specific niche component before the bug matters at all.

Why not lower?

This is still unauthenticated remote SQL injection on an internet-facing web application component. If you do run affected sites, the path to database disclosure is real and the follow-on risk from dumped WordPress user data is non-trivial. That keeps it above LOW or IGNORE.

1. Inventory the plugin — Identify every WordPress instance running WeePie Cookie Allow and flag versions <= 3.4.11. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but do the inventory immediately so exposed web properties do not hide in the long tail.
2. Harden SQLi filtering — Enable or verify WAF/WordPress firewall rules that block generic SQL injection probes against public sites. This is a containment measure for exposed sites while you move through the normal remediation window; it reduces drive-by mass scanning success but should not be treated as a substitute for upgrading.
3. Reduce plugin exposure — Where possible, remove unused premium plugins and minimize anonymous access to nonessential dynamic routes. For a MEDIUM issue there is no noisgate mitigation deadline, but reducing unnecessary public attack surface now pays down the whole WordPress risk stack.
4. Watch for follow-on logins — After any suspected probing, monitor wp-login.php, XML-RPC, admin sessions, and password reset flows for reuse of dumped identities. SQLi often becomes a credential and phishing problem before it becomes a persistence problem.

Run this on the target WordPress host or on a mounted webroot from an auditor workstation with read access to the plugin files; no root is required unless file permissions are locked down. Invoke it as bash check_weepie_cve_2026_4304.sh /var/www/html/wp-content/plugins or point it directly at the plugin directory such as bash check_weepie_cve_2026_4304.sh /var/www/html/wp-content/plugins/weePie-cookie-allow.

#!/usr/bin/env bash
# check_weepie_cve_2026_4304.sh
# Detects whether WeePie Cookie Allow is vulnerable to CVE-2026-4304 based on local plugin version.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage error

set -u

TARGET="${1:-}"
FIXED_VERSION="3.4.12"
VULN_MAX="3.4.11"

usage() {
  echo "Usage: $0 <wp-content/plugins path | plugin directory path>"
}

verlte() {
  # returns success if $1 <= $2 using version sort
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

find_plugin_file() {
  local base="$1"
  local candidate=""

  if [ -f "$base/wp-cookie-allow.php" ]; then
    echo "$base/wp-cookie-allow.php"
    return 0
  fi

  if [ -d "$base" ]; then
    candidate=$(find "$base" -maxdepth 3 -type f \( -iname 'wp-cookie-allow.php' -o -iname '*cookie*allow*.php' \) 2>/dev/null | head -n1)
    if [ -n "$candidate" ]; then
      echo "$candidate"
      return 0
    fi
  fi

  return 1
}

extract_version() {
  local file="$1"
  awk 'BEGIN{IGNORECASE=1} /^[[:space:]]*Version:[[:space:]]*/ {sub(/^[[:space:]]*Version:[[:space:]]*/, ""); print; exit}' "$file" | tr -d '\r'
}

if [ -z "$TARGET" ]; then
  usage
  echo "UNKNOWN - missing path argument"
  exit 3
fi

if [ ! -e "$TARGET" ]; then
  echo "UNKNOWN - path does not exist: $TARGET"
  exit 2
fi

PLUGIN_FILE=""
if [ -d "$TARGET" ]; then
  # If caller passed wp-content/plugins, try common subdirectory names first.
  for d in "$TARGET/weePie-cookie-allow" "$TARGET/weepie-cookie-allow" "$TARGET/wp-cookie-allow" "$TARGET/cookie-allow"; do
    if [ -d "$d" ]; then
      PLUGIN_FILE=$(find_plugin_file "$d" || true)
      [ -n "$PLUGIN_FILE" ] && break
    fi
  done

  # Fallback: search under provided directory.
  if [ -z "$PLUGIN_FILE" ]; then
    PLUGIN_FILE=$(find_plugin_file "$TARGET" || true)
  fi
elif [ -f "$TARGET" ]; then
  PLUGIN_FILE="$TARGET"
fi

if [ -z "$PLUGIN_FILE" ] || [ ! -f "$PLUGIN_FILE" ]; then
  echo "UNKNOWN - could not locate WeePie Cookie Allow plugin main PHP file"
  exit 2
fi

VERSION=$(extract_version "$PLUGIN_FILE")
if [ -z "$VERSION" ]; then
  echo "UNKNOWN - found plugin file but could not parse version: $PLUGIN_FILE"
  exit 2
fi

if verlte "$VERSION" "$VULN_MAX"; then
  echo "VULNERABLE - WeePie Cookie Allow version $VERSION (fixed in $FIXED_VERSION)"
  exit 1
fi

if verlte "$FIXED_VERSION" "$VERSION" || [ "$VERSION" = "$FIXED_VERSION" ]; then
  echo "PATCHED - WeePie Cookie Allow version $VERSION"
  exit 0
fi

# Safety fallback for unusual version strings.
echo "UNKNOWN - parsed version $VERSION but comparison was inconclusive"
exit 2

Sources

1. Freshy advisory summary for CVE-2026-4304
2. Wordfence vulnerability listing for WeePie Cookie Allow
3. Wordfence SQL injection protection listing
4. Patchstack entry for WeePie Cookie Allow SQL injection
5. Vendor changelog showing fix in 3.4.12
6. Codecanyon product page with deployment signal
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS project