The Product Configurator for WooCommerce WordPress plugin before 1

The Product Configurator for WooCommerce plugin exposes an AJAX/REST endpoint (pc_get_data) that returns product data without checking either the caller's capability *or* the target post's status. All versions prior to 1.7.3 are affected. That means an unauthenticated visitor can enumerate product IDs and pull back data on posts that WordPress considers draft, pending, private, or future — content that the storefront would never render to a logged-out visitor.

There is no vendor CVSS on record, so this is a first-pass assessment. WPScan tags it at 7.5 High, but that anchoring is generous for a pure information-disclosure bug with no path to code execution, no session takeover, and no PII exposure by default. The leak matters — competitors and pre-launch leak sites will love it — but on the standard confidentiality/integrity/availability axis it is C-only, and the affected data is business-sensitive rather than personal or credential-bearing. MEDIUM is the honest bucket.

Why this verdict

• Unauthenticated + network-reachable: exploitation friction is essentially zero — a single HTTP request against admin-ajax.php. That keeps this out of LOW territory.
• Confidentiality-only impact: the endpoint returns product metadata. No writes, no privilege escalation, no session material. That is the primary reason this does not sit at HIGH.
• Role multiplier — public storefront: the affected component runs on a merchant web tier. Even when the chain lands, blast radius stops at business-sensitive product data. No identity, PKI, hypervisor, backup, CI/CD, or edge-appliance role is in scope, so no CRITICAL/HIGH floor is triggered.
• Installed base is small: niche configurator plugin, not a Woo core module. Population of exposed sites is measured in thousands, not millions — mass-exploitation ROI is modest.
• No KEV, no public PoC repo, EPSS unscored: no evidence of active weaponization at assessment time.

Why not higher?

HIGH would require either a path to code execution / admin compromise, or leakage of credential/PII-class data at scale. This bug delivers neither — it hands out draft product records on a low-install-count plugin. The role multiplier check produces no high-value-role outcome, so the HIGH floor never engages.

Why not lower?

LOW would require either auth prerequisites, a narrow version window, or negligible data value. This is unauthenticated, applies to every version prior to 1.7.3, and the data class (unreleased SKUs, pricing, custom fields) is genuinely useful to competitors and scrapers. That is real business risk, not backlog noise.

1. Block unauthenticated action=pc_get_data at the WAF — Add a Wordfence / Cloudflare / ModSecurity rule that returns 403 for any request to /wp-admin/admin-ajax.php with action=pc_get_data when no valid wp_logged_in cookie is present. Deploy within the MEDIUM window — no formal noisgate mitigation SLA applies, but if the plugin is on a high-traffic storefront, treat as a 7-day task.
2. Deactivate the plugin on sites that do not actively use it — Many merchants installed Product Configurator for a single campaign and never removed it. If it is not driving live SKUs, deactivate and uninstall today — zero business impact, permanent risk retirement.
3. Purge/clean draft product records — Audit wp_posts for post_type=product AND post_status IN ('draft','pending','private','future') and remove or sanitize any records containing embargoed pricing, roadmap notes, or supplier data. Reduces the value of a successful exploit even before patching.
4. Enable enumeration rate-limiting on admin-ajax.php — Cap unauthenticated admin-ajax requests to something like 30/min/IP at the edge. Turns bulk ID sweeps into a detectable, noisy event and slows scraper economics.

Run from an auditor workstation (no privileges required — the whole point is that the endpoint is unauthenticated). Invoke as ./check-cve-2026-11568.sh https://store.example.com. Exits 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN.

#!/usr/bin/env bash
# noisgate verifier — CVE-2026-11568
# Product Configurator for WooCommerce < 1.7.3 :: unauth draft/private product disclosure
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 https://store.example.com" >&2
  exit 2
fi

# 1. Fingerprint plugin version from readme.txt
README_URL="${TARGET%/}/wp-content/plugins/product-configurator-for-woocommerce/readme.txt"
VER=$(curl -fsSL --max-time 10 "$README_URL" 2>/dev/null | awk -F': *' '/^Stable tag/ {print $2; exit}')

if [[ -z "$VER" ]]; then
  echo "UNKNOWN — could not read plugin readme at $README_URL"
  exit 2
fi

echo "detected Product Configurator version: $VER"

# 2. Semver compare against 1.7.3
vercmp() {
  # returns 0 if $1 < $2
  [[ "$1" == "$2" ]] && return 1
  local L=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -1)
  [[ "$L" == "$1" ]]
}

if vercmp "$VER" "1.7.3"; then
  # 3. Confirm behavior — probe pc_get_data unauthenticated
  AJAX_URL="${TARGET%/}/wp-admin/admin-ajax.php"
  RESP=$(curl -fsS --max-time 10 -X POST \
         --data "action=pc_get_data&product_id=1" "$AJAX_URL" 2>/dev/null)
  if [[ -n "$RESP" && "$RESP" != "0" && "$RESP" != "-1" ]]; then
    echo "VULNERABLE — version $VER < 1.7.3 and pc_get_data responded to unauth request"
    exit 1
  fi
  echo "VULNERABLE — version $VER < 1.7.3 (endpoint probe inconclusive; assume exposed)"
  exit 1
fi

echo "PATCHED — version $VER >= 1.7.3"
exit 0

Sources

1. WPScan — Product Configurator for WooCommerce vulnerabilities
2. Patchstack — Product Configurator for WooCommerce
3. WordPress.org plugin page
4. CVE record
5. Wordfence Intelligence — WooCommerce plugin feed
6. CVE Details — WooCommerce ecosystem
7. FIRST EPSS
8. CISA KEV Catalog