The Avada

The Avada (Fusion) Builder plugin's fusion_get_post_custom_field() helper accepts a post_custom_field parameter from the Dynamic Data feature and returns the requested meta value without checking whether the key begins with an underscore. In WordPress, an underscore prefix is the canonical marker for *protected* post meta — used by ecommerce plugins, license managers, and custom workflows to store internal state like SKUs, payment tokens, hidden order data, or plugin scratch fields. All versions ≤ 3.15.1 are affected; the vendor shipped the fix in 3.15.2, which validates the requested key against is_protected_meta() before returning the value.

The vendor MEDIUM (4.3) label is honest. The CVSS vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N correctly captures a network-reachable, authenticated, confidentiality-only leak with no integrity or availability impact. If anything, in a hardened WordPress install where open Subscriber registration is disabled, the real-world reachable population is smaller than the vector implies — pushing this into LOW territory for most enterprise footprints. It is not a system-compromise bug; it is a reconnaissance primitive.

Why this verdict

• Authenticated precondition compresses reachable population — Subscriber capability is required; enterprise-hosted Avada sites overwhelmingly disable public registration or gate it behind CAPTCHA + email verification, cutting the attacker-accessible population dramatically.
• Confidentiality-only, bounded blast radius — the vector is C:L / I:N / A:N. No write, no code execution, no session forgery. Worst plausible outcome is exposure of order emails, license keys, or plugin scratch fields — a privacy incident on a single site, not fleet compromise.
• Role multiplier: low-value role (marketing/CMS tier) — Avada is a *frontend page-builder theme*. Its canonical deployment is marketing/brochure sites, WooCommerce storefronts, and campaign microsites — not an identity provider, hypervisor, PAM, CI/CD, or backup plane. The chain does NOT reach domain/fleet/supply-chain scale in any realistic deployment role, so no HIGH/CRITICAL floor is triggered.
• Role multiplier: typical role (WooCommerce storefront) — the worst-case data leak is customer email / order metadata. Impact is a GDPR-reportable privacy incident scoped to one site's customer list, not multi-tenant compromise. Still bounded within LOW/MEDIUM.
• No wormable, no auth-bypass, no chain to admin — the bug cannot be pivoted into WP admin without a separate privilege-escalation vulnerability. EPSS 0.00269 and no KEV listing corroborate the low weaponization interest.

Why not higher?

MEDIUM would be defensible if Avada sites broadly enabled open registration or if the leak included credentials/tokens usable against WP admin — neither generalizes. The bug cannot write, escalate, or execute; upgrading to HIGH would ignore the confidentiality-only vector and the absence of any exploitation signal.

Why not lower?

IGNORE is wrong because a real information-disclosure primitive exists with a public PoC, and WooCommerce-backed Avada storefronts genuinely store customer PII in post meta. It deserves scheduled patching, not silent acceptance.

1. Disable open user registration site-wide — In *Settings → General*, uncheck Anyone can register. This removes the authenticated precondition for opportunistic attackers. No mitigation SLA applies at LOW severity, but this is a five-second change worth making today on any Avada site that doesn't need self-service accounts.
2. Deploy the Wordfence / Patchstack virtual patch rule for CVE-2026-1541 — Both vendors shipped WAF signatures in late April 2026 that block post_custom_field values starting with _. Apply within your normal WAF rule-update cadence — no mitigation SLA at LOW, but it costs nothing if you already run one of these WAFs.
3. Audit protected post meta for sensitive content — Run wp db query "SELECT DISTINCT meta_key FROM wp_postmeta WHERE meta_key LIKE '\_%'" and identify keys carrying PII, license keys, or tokens. Where feasible, move secrets out of post meta into a dedicated encrypted store. This is defense-in-depth beyond CVE-2026-1541.
4. Upgrade Fusion Builder to ≥ 3.15.2 during the next scheduled CMS window — This is the definitive remediation. Push via your normal WordPress plugin-update process; regression risk is minimal (the patch is a single is_protected_meta() guard). Target the noisgate remediation SLA of ≤ 365 days for LOW verdicts.

Run this from an auditor workstation with curl and jq installed. It probes the Fusion Builder plugin readme for its declared version — no auth required, no exploit sent. Invoke as ./check-cve-2026-1541.sh https://target-site.example.com. No elevated privileges needed.

#!/usr/bin/env bash
# check-cve-2026-1541.sh — Avada Fusion Builder version check for CVE-2026-1541
# Exit: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u

if [ $# -lt 1 ]; then
  echo "usage: $0 <https://target-site>" >&2
  exit 2
fi

TARGET="${1%/}"
FIXED="3.15.2"
UA="noisgate-cve-2026-1541-check/1.0"

# Candidate readme locations shipped by Fusion Builder
PATHS=(
  "/wp-content/plugins/fusion-builder/readme.txt"
  "/wp-content/plugins/fusion-builder/fusion-builder.php"
)

version=""
for p in "${PATHS[@]}"; do
  body=$(curl -sk -A "$UA" --max-time 10 "${TARGET}${p}" || true)
  # readme.txt: 'Stable tag: 3.15.1'   plugin header: 'Version: 3.15.1'
  v=$(printf '%s\n' "$body" | grep -Ei '^(Stable tag|Version)[[:space:]]*:' | head -1 | awk -F: '{print $2}' | tr -d ' \r')
  if [ -n "$v" ]; then version="$v"; break; fi
done

if [ -z "$version" ]; then
  echo "UNKNOWN — Fusion Builder readme not reachable at ${TARGET}"
  exit 2
fi

# semver-ish compare
lower=$(printf '%s\n%s\n' "$version" "$FIXED" | sort -V | head -1)
if [ "$version" = "$FIXED" ] || [ "$lower" = "$FIXED" ]; then
  echo "PATCHED — Fusion Builder ${version} (>= ${FIXED})"
  exit 0
else
  echo "VULNERABLE — Fusion Builder ${version} (< ${FIXED}) — CVE-2026-1541"
  exit 1
fi

Sources

1. GitHub Advisory GHSA-j7wx-2ff4-pc88
2. CVEFeed — CVE-2026-1541 technical detail
3. WP-Firewall writeup and hardening guidance
4. Managed-WP CVE-2026-1541 analysis
5. SentinelOne vulnerability database entry
6. Tenable CVE-2026-1541
7. OffSeq threat radar entry
8. CIRCL Vulnerability-Lookup