Like giving every museum visitor the keys to the exhibit teardown cart
CVE-2026-86091 is a missing-authorization flaw in ntopng's REST API, specifically the pools bulk-delete endpoint. Any user who can log in — regardless of role — can issue POST requests that permanently remove all host pools and their associated member bindings. Host pools are the primary mechanism ntopng uses to group hosts by policy, so deleting them wipes traffic classification and per-pool alerting rules. Versions prior to 6.7.260717 are affected; the fix adds proper privilege checks to the endpoint.
The vendor rates this HIGH at 7.1, which is reasonable if you imagine the endpoint exposed to the internet with many low-privilege users. In reality, ntopng is an internal network monitoring appliance. Authenticated access is already a prerequisite, and the blast radius is limited to configuration data — no secrets leak, no code execution, no lateral movement. Pool configs are recoverable from backups or re-creation. The vendor severity overstates the real-world risk for most enterprise deployments by roughly one full tier.
3 steps from start to impact.
Obtain valid ntopng credentials
- Valid ntopng user account (any role)
- Network reachability to the ntopng web UI (typically TCP/3000)
- ntopng is rarely internet-facing; almost always bound to a management VLAN or localhost
- Account provisioning is manual — most instances have <10 users
- MFA is not natively supported but reverse-proxy MFA would block this
Craft bulk-delete POST request
curl or any HTTP client works. The endpoint accepts the request without verifying the caller's administrative privileges.- Active authenticated session or API token
- Knowledge of the REST v2 endpoint path (documented in ntopng API docs)
- Endpoint path is public knowledge but requires reading ntopng API documentation
- API tokens are randomly generated and scoped per-user
All host pools and member bindings destroyed
- Successful completion of step 2
- Impact is limited to configuration — no data exfiltration, no code execution
- Pools can be recreated manually or restored from config backup
- ntopng continues to function; it just loses pool-based segmentation
The supporting signals.
| In-the-wild exploitation | No known exploitation. Not listed on CISA KEV. No reports of active campaigns. |
|---|---|
| Proof of concept | No public PoC repository identified. Exploitation is trivial — a single authenticated curl POST — so weaponization is near-zero effort. |
| EPSS score | 0.00286 (~bottom 15th percentile). Extremely low predicted exploitation probability. |
| KEV status | Not listed. No CISA KEV entry as of 2026-09-06. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L — Network-accessible but requires low-privilege auth. No confidentiality impact; integrity is the primary concern. |
| Affected versions | All ntopng versions before 6.7.260717. Community and Enterprise editions both affected. |
| Fixed version | 6.7.260717 (released July 2026). Adds authorization checks to the pools bulk-delete endpoint. |
| Exposure data | ntopng instances are rarely internet-facing. Shodan/Censys queries for ntopng typically return <2,000 globally exposed instances, most on non-standard ports. The vast majority run behind management VLANs. |
| Disclosure date | 2026-09-04 (NVD); some sources list 2026-09-05. |
| Related CVEs | CVE-2026-86090 (same pattern on notification handler endpoints) and CVE-2026-84989 (tag management endpoints) — same root cause, same fix version. |
noisgate verdict.
The single most decisive factor is the limited blast radius: the vulnerability destroys pool configuration data on an internal monitoring tool with no path to code execution, credential theft, or lateral movement. Pools are recoverable, and the prerequisite of authenticated access on a typically non-internet-facing appliance compounds the narrowing.
Why this verdict
- Authentication gate: PR:L means the attacker must already hold valid credentials on the ntopng instance. ntopng does not support self-registration; accounts are manually provisioned by admins, so the user population per instance is tiny (typically <10).
- Network exposure: ntopng is an internal network monitoring tool. Fewer than 2,000 instances are internet-reachable globally per Shodan data. In enterprise deployments, it is bound to management VLANs or loopback, behind VPN or reverse-proxy with additional auth layers.
- Impact ceiling: The attack deletes configuration (host pools and bindings). There is zero confidentiality impact, no code execution, and no lateral-movement capability. Pool configs can be restored from backup or manually recreated in minutes.
- Role multiplier: ntopng occupies the network-visibility/monitoring tier, adjacent to the SIEM/detection-plane category. If an attacker deletes pools, they degrade segmentation-based alerting, which could theoretically cover tracks. However: (a) ntopng continues capturing traffic — only pool-based classification is lost, not raw flow data; (b) the attacker already needs authenticated access, implying a prior compromise stage; (c) restoring pools is a low-effort recovery. The detection-plane disruption angle does not escalate this to HIGH because the disruption is partial, recoverable, and requires prior auth. The high-value role floor does not apply because the blast radius is configuration-only, not fleet/domain/supply-chain scale.
- No exploitation evidence: EPSS is 0.00286, no KEV listing, no known campaigns, no public PoC repos. The vuln class (missing authz on a delete endpoint) is common and well-understood but not actively targeted in ntopng specifically.
Why not higher?
To warrant HIGH, the vulnerability would need to enable code execution, credential theft, or meaningful lateral movement — or the affected component would need to be canonically in a high-value fleet role (DC, hypervisor, PAM). ntopng pool deletion is a recoverable configuration disruption on an internal monitoring tool with a tiny authenticated user base. The detection-plane angle is mitigated by the fact that raw flow capture continues unaffected.
Why not lower?
The integrity impact is real: a single API call can wipe all pool configs across the instance, which degrades monitoring segmentation and could assist an attacker in covering lateral movement. The attack complexity is genuinely low once authenticated, and the related CVEs (86090, 84989) suggest a pattern of missing authz across the API surface, increasing the chance an attacker chains multiple config-wipe endpoints for broader disruption.
What to do — in priority order.
- Restrict ntopng web UI access to admin-only networks — Bind ntopng to a management VLAN or localhost and front it with a VPN or reverse proxy that enforces MFA. This eliminates the PR:L prerequisite for any external or general-network attacker. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.
- Audit and minimize ntopng user accounts — Remove or disable any non-essential user accounts. ntopng accounts are manually provisioned; ensure only NOC/security staff who need dashboard access have credentials. Fewer accounts = smaller attack surface.
- Back up ntopng pool configurations — Export pool and member-binding configs on a regular schedule (daily cron). If pools are deleted, restoration takes minutes rather than hours of manual re-creation.
- Monitor ntopng REST API logs for DELETE/bulk operations — Forward ntopng access logs to your SIEM and alert on any POST to the pools bulk-delete endpoint. This provides detection-in-depth even if the authz bypass is exploited.
- WAF rules blocking DELETE methods — the endpoint uses POST, not DELETE, so HTTP-method-based WAF rules will not catch it.
- ntopng role-based access controls (pre-patch) — the entire point of the CVE is that the RBAC check is missing on this endpoint; configuring roles does not help until you patch.
- Network segmentation of monitored hosts — segmenting the hosts ntopng monitors does not protect the ntopng management plane itself; the attack targets the admin UI, not monitored traffic.
Crowdsourced verification payload.
Run this script on the ntopng host (or any machine that can reach the ntopng web UI) as any user. Invoke with: bash check_cve_2026_86091.sh. No special privileges required — it just checks the installed ntopng version.
#!/usr/bin/env bash\n# check_cve_2026_86091.sh\n# Checks whether the local ntopng version is vulnerable to CVE-2026-86091\n# (missing authorization on pools bulk-delete endpoint).\n# Fixed in 6.7.260717.\n# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN\n\nFIXED_VERSION=\"260717\"\n\nif ! command -v ntopng &>/dev/null; then\n echo \"UNKNOWN: ntopng binary not found in PATH.\"\n exit 2\nfi\n\nRAW_VERSION=$(ntopng --version 2>&1 | head -1)\necho \"Detected ntopng version string: $RAW_VERSION\"\n\n# Extract the build number (last numeric segment after a dot, e.g. 6.7.260717 -> 260717)\nBUILD=$(echo \"$RAW_VERSION\" | grep -oP '\\d+\\.\\d+\\.(\\d+)' | grep -oP '\\d+$')\n\nif [ -z \"$BUILD\" ]; then\n echo \"UNKNOWN: Could not parse build number from version string.\"\n exit 2\nfi\n\necho \"Parsed build number: $BUILD\"\necho \"Fixed build number: $FIXED_VERSION\"\n\nif [ \"$BUILD\" -ge \"$FIXED_VERSION\" ] 2>/dev/null; then\n echo \"PATCHED: ntopng build $BUILD >= $FIXED_VERSION. CVE-2026-86091 is fixed.\"\n exit 0\nelse\n echo \"VULNERABLE: ntopng build $BUILD < $FIXED_VERSION. CVE-2026-86091 applies.\"\n exit 1\nfiIf you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.