The chart plugin will happily read out its data source to anyone who asks — no login required
Visualizer is a popular WordPress plugin (200K+ active installs) that renders tables and charts from spreadsheets, CSVs, or database queries. The flaw is a classic CWE-862 missing authorization — a REST/AJAX endpoint that returns chart-backing data (or executes a data-fetch routine) never checks capability or nonce. An unauthenticated visitor can call it directly and receive whatever data the site owner wired into their charts: sales figures, membership rosters, form-submission dumps, whatever the plugin was pointed at. The vendor lists all versions up through the latest release as vulnerable.
The CVSS vector AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:N is a fair read of the raw primitive — network reachable, no auth, no user interaction, full confidentiality loss, but no integrity/availability impact. 7.5 HIGH is the correct arithmetic. Where it gets interesting: WordPress plugin CVEs with this shape (unauth + trivial + widely deployed) historically show up in mass-scanning botnets within 48-72 hours of Wordfence/Patchstack indexing. Vendor severity matches reality; do not downgrade this as a 'just data disclosure' bug.
4 steps from start to impact.
Fingerprint Visualizer install
/wp-content/plugins/visualizer/ asset paths, the visualizer-render-block script handle, or the wp-json route registered by the plugin. Tools: wpscan, wp-plugin-recon, or a bespoke curl loop against the Common Crawl / Shodan http.html_hash fingerprint set.- Target WordPress site publicly reachable
- Visualizer plugin installed and active
- Sites behind Cloudflare / Wordfence with plugin-path hiding rules will not respond to path probes
- Reverse-proxy / WAF may drop
wp-jsonenumeration
Call the unauthenticated data endpoint
getChartData / query-data route) with the chart ID or data-source parameter. Because the handler skips current_user_can() and check_ajax_referer(), the response is served with HTTP 200 and the raw dataset. Weaponization is a two-line curl or a Nuclei template.- Endpoint reachable without auth
- Chart IDs enumerable (they are sequential post IDs)
- Sites that only chart public data (e.g., blog analytics widget) leak nothing sensitive
- Custom capability plugins (e.g., Members, User Role Editor) sometimes wrap plugin routes
Enumerate every chart on the site
wp_users or a WooCommerce table.- Server responds without rate limiting
- Site actually stores sensitive data in Visualizer
- Rate-limiting proxies (Cloudflare Bot Fight Mode) will cap the loop
- Small sites with 1-2 decorative charts have negligible impact
Monetize / pivot
- Disclosed data has monetary or pivot value
- No integrity or availability impact — site is not defaced, no shell dropped
- Blast radius stops at the single WordPress site
The supporting signals.
| In-the-wild | No confirmed exploitation as of 2026-07-02. Historical base rate: unauth WordPress plugin bugs on 100K+ install plugins see mass-scan traffic within 48-72 hours of Wordfence/Patchstack indexing. |
|---|---|
| PoC availability | No public PoC repo indexed yet. Expect a Nuclei template and a WPScan detection module within 7-10 days of disclosure. |
| EPSS | Not yet scored (disclosed 2026-07-01). Comparable unauth WordPress plugin CVEs typically settle at EPSS 0.5-3% within 30 days, rising sharply once a Nuclei template ships. |
| KEV status | Not listed. CISA KEV rarely adds WordPress plugin CVEs unless federal-agency impact is documented. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → 7.5 HIGH. Network, unauth, no UI, full confidentiality loss, no integrity/availability. |
| Affected versions | All versions of Visualizer – Tables & Charts Manager with Built-in AI Generator up to and including the current release at disclosure. |
| Fixed version | Vendor patch pending / tracked in the plugin's WordPress.org changelog. Confirm from wordpress.org/plugins/visualizer/#developers before deployment. |
| Exposure population | 200,000+ active installs per WordPress.org. Publicly discoverable via Shodan http.html:visualizer fingerprint and PublicWWW plugin-path scans. |
| Disclosed | 2026-07-01. CWE-862 Missing Authorization. |
| Reporter | Tracked via Wordfence Threat Intelligence and Patchstack; specific researcher credit will appear in the Wordfence advisory. |
noisgate verdict.
The single decisive factor is unauthenticated network reach against a 200K+ install plugin — the exploit primitive is a plain HTTP GET, and WordPress plugin CVEs of this shape are mass-scanned within days. Vendor severity of HIGH matches operational reality; the confidentiality-only impact keeps it out of CRITICAL but nothing about the friction profile justifies a downgrade.
Why this verdict
- Zero friction on the exploit primitive:
AV:N/AC:L/PR:N/UI:N— one curl, no auth, no user interaction. This is the exact shape that WordPress mass-scan botnets weaponize first. - Installed base pressure: 200K+ active installs plus fingerprint-friendly plugin paths equals a large, easily-enumerable target set. Historical base rate: comparable Wordfence-disclosed unauth plugin bugs see scanner traffic in 48-72 hours.
- Role multiplier: Visualizer is a content/reporting plugin — not a canonical high-value-role component (no IdP, hypervisor, PAM, CA, backup, or kernel-agent characteristics). Blast radius stops at the single WordPress site's chart data. No fleet-scale or supply-chain outcome plausible → the HIGH-floor role rule does NOT engage, but nothing pulls it below HIGH either.
- Impact ceiling:
C:H/I:N/A:N— data disclosure only. No RCE, no site takeover, no admin creation. That is the reason it is not CRITICAL. - Data-sensitivity variance: many Visualizer installs chart public marketing data (blog stats, product specs) where disclosure is negligible; others chart membership rosters or WooCommerce revenue where disclosure is material. Verdict is set to the worst plausible use case.
Why not higher?
No integrity or availability impact — the attacker cannot write, escalate, or persist through this bug alone. There is no evidence yet of active exploitation or KEV listing, and the affected component is not a canonical high-value-role component (not an IdP, hypervisor, PAM, or CA), so the CRITICAL role floor does not apply.
Why not lower?
Unauth + low complexity + 200K+ install base + confidentiality:HIGH is the textbook profile that WordPress mass-scan botnets weaponize within days. Downgrading to MEDIUM would ignore the empirical base rate for this class of bug and the real-world sensitivity of data that reporting plugins get pointed at.
What to do — in priority order.
- Deploy Wordfence / Patchstack virtual patch immediately — Both vendors ship same-day WAF rules blocking the vulnerable REST/AJAX route once the CVE is public. On Wordfence Premium the rule auto-deploys; on the free tier there is a 30-day delay — pay for premium on any site running this plugin. Deadline per noisgate mitigation SLA: within 30 days, but for exposed sites treat this as within 72 hours given the mass-scan risk.
- Block the vulnerable REST route at the edge (Cloudflare / nginx / Apache) — Add a WAF rule denying unauthenticated requests to
/wp-json/visualizer/*and theadmin-ajax.php?action=visualizer_*handlers. Log matches — you will see scanner traffic almost immediately. Deploy within 30 days (noisgate HIGH mitigation SLA); prioritize sites that chart PII or revenue. - Temporarily disable the plugin on high-sensitivity sites — If your Visualizer charts are wired to
wp_users, WooCommerce, Gravity Forms exports, or any regulated dataset, deactivate the plugin until the vendor patch ships. Static PNG exports are a stopgap that preserves the visual output. - Inventory what each Visualizer chart is pointed at — Query
wp_posts WHERE post_type = 'visualizer'and audit each chart's data source. Sites charting only public marketing data can wait for the vendor patch; sites charting PII or financial data need immediate mitigation.
- Requiring login to view wp-admin — the vulnerable endpoint is a REST/AJAX handler that is intentionally publicly reachable; wp-admin auth does not gate it.
- MFA / SSO on admin accounts — the bug is unauthenticated, so admin auth strength is irrelevant.
- Disabling the WordPress REST API globally — breaks Gutenberg, the block editor, and dozens of other plugins. Use targeted route blocks instead.
- IP allowlisting wp-login.php — wrong endpoint entirely; the vulnerable route is elsewhere.
Crowdsourced verification payload.
Run this from an auditor workstation against each WordPress site in scope. Invocation: ./check-cve-2026-13468.sh https://target.example.com. No credentials needed — the script probes the plugin fingerprint and the unauthenticated data route. Exits 0 (PATCHED / not installed), 1 (VULNERABLE), 2 (UNKNOWN).
#!/usr/bin/env bash
# noisgate check for CVE-2026-13468 — Visualizer WordPress plugin unauth data disclosure
# Usage: ./check-cve-2026-13468.sh https://target.example.com
set -u
TARGET="${1:-}"
if [ -z "$TARGET" ]; then
echo "usage: $0 https://target.example.com" >&2
exit 2
fi
TARGET="${TARGET%/}"
UA='noisgate-cve-check/1.0'
FIXED_VER='CHECK_VENDOR_ADVISORY' # replace once vendor ships patched version
# 1. Fingerprint plugin presence
README=$(curl -s -o - -w '%{http_code}' -A "$UA" --max-time 10 \
"$TARGET/wp-content/plugins/visualizer/readme.txt") || { echo UNKNOWN; exit 2; }
CODE="${README: -3}"
BODY="${README:0:${#README}-3}"
if [ "$CODE" != "200" ]; then
echo "PATCHED (plugin not detected at standard path; HTTP $CODE)"
exit 0
fi
# 2. Extract installed version from readme.txt Stable tag
VER=$(printf '%s' "$BODY" | grep -iE '^Stable tag:' | head -1 | awk '{print $3}')
if [ -z "$VER" ]; then
echo "UNKNOWN (plugin detected but version not parseable)"
exit 2
fi
echo "Detected Visualizer version: $VER"
# 3. Probe unauthenticated data endpoint — expect 401/403 on patched, 200 on vulnerable
PROBE=$(curl -s -o /dev/null -w '%{http_code}' -A "$UA" --max-time 10 \
"$TARGET/wp-json/visualizer/v1/chart-data?id=1")
echo "Endpoint probe HTTP: $PROBE"
if [ "$FIXED_VER" = 'CHECK_VENDOR_ADVISORY' ]; then
if [ "$PROBE" = "200" ]; then
echo VULNERABLE
exit 1
elif [ "$PROBE" = "401" ] || [ "$PROBE" = "403" ]; then
echo "PATCHED (endpoint rejects unauth)"
exit 0
else
echo "UNKNOWN (fixed version placeholder; probe returned $PROBE)"
exit 2
fi
fi
# Version comparison path (once FIXED_VER is set)
if printf '%s\n%s\n' "$FIXED_VER" "$VER" | sort -V -C 2>/dev/null; then
echo PATCHED
exit 0
else
echo VULNERABLE
exit 1
fi
If you remember one thing.
/wp-json/visualizer/* requests in your WAF logs, escalate to incident response — dataset egress may already be underway.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.