ntopng before 6.7.260717 fails to perform authorization checks in the delete endpoints and recipients REST…

CVE-2026-86090 is a missing-authorization flaw in ntopng's REST v2 API, specifically in the POST /lua/rest/v2/delete/endpoints.lua and POST /lua/rest/v2/delete/recipients.lua handlers. Any authenticated user — even one with the lowest privilege tier — can call these endpoints to irreversibly delete all configured notification endpoints and recipients. The result: ntopng continues monitoring traffic, but every alert it would normally fire goes nowhere. All versions before 6.7.260717 are affected.

The vendor scored this HIGH at 7.1, and on paper the CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H) is fair *if* you treat ntopng as internet-facing and as the sole alerting system. In practice, neither is usually true. ntopng is overwhelmingly deployed on internal management VLANs, requires valid credentials to reach the API, delivers no code execution or data exfiltration, and sits alongside EDR, SIEM, and IDS/IPS in any mature enterprise stack. The real-world severity is closer to MEDIUM once you factor in attacker position, recoverability (re-creating notification configs is manual but straightforward), and the limited blast radius of silencing one supplementary monitor.

Why this verdict

• Authentication barrier: PR:L means a valid ntopng account is required. ntopng user populations are small (NOC/SOC staff); this is not a self-registration SaaS app. Credential acquisition is a prerequisite that gates the entire chain.
• Internal-only exposure: ntopng is a network traffic analyzer that binds to port 3000 on management interfaces. Virtually no enterprise exposes it to the internet. The attacker must already be on the internal network or VPN — meaning this is a post-initial-access bug, not an entry point.
• No code execution or data breach: The impact ceiling is deletion of notification configs. There is zero confidentiality impact (C:N), no shell, no privilege escalation on the host. The CVSS Availability:High rating reflects alerting disruption, not service destruction — ntopng itself keeps running.
• Recoverable impact: Deleted notification endpoints and recipients can be manually re-created by an admin. There is no persistent backdoor, no data corruption, no cryptographic material compromise.
• Role multiplier: ntopng occupies a *supplementary network visibility* role, not a primary SIEM/detection-plane role. In the high-value-role catalog, the detection plane entry names Splunk, Elastic SIEM, Sentinel, and QRadar — ntopng is a traffic analyzer that may feed these systems but is not itself the authoritative alert/detection platform. Even if ntopng's alerts are silenced, EDR, IDS/IPS, and SIEM continue independently. The blast radius is limited to one monitoring tool's notification pipeline, not the enterprise detection stack. This does NOT trigger the detection-plane floor.

Why not higher?

To warrant HIGH, we would need either unauthenticated access, code execution, or a scenario where ntopng is the sole detection system *and* internet-facing. None of these apply. The authenticated-only, internal-network, config-deletion-only profile places this firmly below the HIGH threshold. No KEV listing, no active exploitation, and an EPSS in the bottom quartile further confirm that real-world risk does not justify HIGH.

Why not lower?

Despite the friction, the exploitation is trivially easy once authenticated (a single POST request), the impact is operationally meaningful (complete alert silencing), and ntopng *is* part of the security monitoring stack even if supplementary. A disgruntled or compromised low-privilege operator could weaponize this in seconds. LOW would understate the operational disruption potential.

1. Restrict REST v2 delete paths at the reverse proxy / API gateway — Add an ACL or WAF rule that blocks POST requests to /lua/rest/v2/delete/endpoints.lua and /lua/rest/v2/delete/recipients.lua for all sessions except those from designated admin IPs. This is the fastest compensating control and should be deployed within the MEDIUM remediation window.
2. Enable ntopng access logging and SIEM ingestion — Ensure ntopng's HTTP access logs are forwarded to your SIEM. Create a detection rule for any POST to /rest/v2/delete/ paths. This provides after-the-fact detection if the path-block isn't feasible.
3. Reduce ntopng user population and enforce least privilege — Audit ntopng local and LDAP-linked accounts. Remove any accounts that don't require interactive access. Where possible, restrict non-admin users to read-only interfaces.
4. Place ntopng behind MFA-enforced reverse proxy — ntopng doesn't natively support MFA. Fronting it with an SSO/MFA reverse proxy (e.g., Authelia, Keycloak, Azure AD App Proxy) raises the credential-acquisition bar significantly.

Run this on the ntopng host or any machine that can reach the ntopng web UI. Requires curl and jq. Example: bash check_cve_2026_86090.sh https://ntopng.internal:3000 admin your_password. No root required — it only reads the version endpoint.

#!/usr/bin/env bash
# check_cve_2026_86090.sh — Detect ntopng versions vulnerable to CVE-2026-86090
# Usage: bash check_cve_2026_86090.sh <NTOPNG_BASE_URL> <USERNAME> <PASSWORD>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

BASE_URL="${1:?Usage: $0 <base_url> <user> <pass>}"
USER="${2:?}"
PASS="${3:?}"

# Authenticate and grab session cookie
COOKIE_JAR=$(mktemp)
trap "rm -f $COOKIE_JAR" EXIT

curl -sk -c "$COOKIE_JAR" -d "username=${USER}&password=${PASS}" \
  "${BASE_URL}/authorize.html" -o /dev/null

# Fetch ntopng version via REST API
VERSION_JSON=$(curl -sk -b "$COOKIE_JAR" "${BASE_URL}/lua/rest/v2/get/ntopng/info.lua" 2>/dev/null || true)

if [ -z "$VERSION_JSON" ]; then
  echo "UNKNOWN — could not retrieve version from ${BASE_URL}"
  exit 2
fi

VERSION=$(echo "$VERSION_JSON" | jq -r '.rsp.version // empty' 2>/dev/null || true)

if [ -z "$VERSION" ]; then
  # Fallback: try parsing from the login page
  VERSION=$(curl -sk "${BASE_URL}" | grep -oP 'v\.\K[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse ntopng version"
  exit 2
fi

echo "Detected ntopng version: ${VERSION}"

# Fixed version: 6.7.260717
# Compare: major.minor.patch
IFS='.' read -r MAJ MIN PATCH <<< "$VERSION"

FIX_MAJ=6
FIX_MIN=7
FIX_PATCH=260717

if [ "$MAJ" -gt "$FIX_MAJ" ] 2>/dev/null; then
  echo "PATCHED — version ${VERSION} is above the fix."
  exit 0
elif [ "$MAJ" -eq "$FIX_MAJ" ] && [ "$MIN" -gt "$FIX_MIN" ] 2>/dev/null; then
  echo "PATCHED — version ${VERSION} is above the fix."
  exit 0
elif [ "$MAJ" -eq "$FIX_MAJ" ] && [ "$MIN" -eq "$FIX_MIN" ] && [ "$PATCH" -ge "$FIX_PATCH" ] 2>/dev/null; then
  echo "PATCHED — version ${VERSION} includes the fix (>= 6.7.260717)."
  exit 0
else
  echo "VULNERABLE — version ${VERSION} is below the fixed version 6.7.260717."
  exit 1
fi

Sources

1. THREATINT CVE-2026-86090 Detail
2. OffSeq Threat Radar — CVE-2026-86090
3. VulDB — CVE-2026-86090
4. TheHackerWire — CVE-2026-86090
5. GitHub — ntopng repository
6. ntop.org — Official Site
7. GitHub Patch Commit 7d830f3