ntopng: Remote Code Execution via OS Command Injection in the Vulnerability Scan
Any authenticated ntopng user down to the lowest read-only role injects operating-system commands through the unfiltered scan_ports parameter of the vulnerability-scan API and gains code execution as the service user, and as root on bare-metal installs.
Advisory ID: TP-2026-061
Product: ntopng (open-source network traffic monitoring tool, C++ core with LuaJIT)
Vulnerability type: OS Command Injection (CWE-78)
CVE: CVE-2026-82412
CVSS 3.1: 8.8 (High) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Vendor advisory: GHSA-2c6p-4pfj-qv58
Affected versions: <= 6.7.260716
Fixed in: 6.7.260717
Reported: 4 July 2026
Summary
ntopng is an open-source network traffic monitoring tool. The REST API of its built-in vulnerability scan passes the scan_ports parameter unfiltered into an nmap command line that runs through popen() in a /bin/sh shell. The target argument is strictly validated as an IP or CIDR, but the only filter on scan_ports blocks only spaces and the single quote, so shell metacharacters and ${IFS} pass through. Because the affected endpoints carry no administrator check, any authenticated account down to the lowest read-only role reaches the sink. The result is execution of arbitrary operating-system commands as the ntopng service user, and as root on bare-metal installs.
Root cause
ntopng appends the caller-supplied scan_ports value raw onto the nmap command line (command = command .. " -p " .. ports, scripts/lua/modules/vulnerability_scan/vs_utils.lua:2673) and runs the string through ntop.execCmd with popen() in a shell (src/Utils.cpp:4444). The host argument is checked as an IP or CIDR by is_valid_nmap_target, but scan_ports is not (scripts/lua/modules/vulnerability_scan/vs_utils.lua:2650). The only filter on scan_ports is the validateSingleWord lint, which blocks only spaces and the single quote (scripts/lua/modules/http_lint.lua:2422), so ; $ { } | & and backtick survive and ${IFS} substitutes for the blocked space. Both REST endpoints carry no isAdministrator() check (scripts/lua/rest/v2/add/host/to_scan.lua and scripts/lua/rest/v2/exec/host/schedule_vulnerability_scan.lua), so any authenticated account down to the lowest unprivileged role reaches the sink. The queued scan is executed by the per-minute background job (scripts/callbacks/minute/system/vulnerability_scan.lua), whose process runs as the ntopng service account, and as root on typical bare-metal installs.
Proof of Concept
GET /lua/rest/v2/add/host/to_scan.lua?host=127.0.0.1&scan_type=tcp_portscan&scan_ports=80;touch${IFS}/tmp/pwned; HTTP/1.1
Cookie: <session of an unprivileged user>
# The per-minute job drains the queue; within ~60 s
# /tmp/pwned appears, owned by ntopng (uid 999).
The blocked space is replaced by ${IFS}, ; ends the nmap call and starts the injected command. Both endpoints are GET with no CSRF token, so the attack also works as CSRF against a logged-in user.
Impact
- Execution of arbitrary operating-system commands as the ntopng service user, and as root on bare-metal installs.
- Any authenticated account down to the lowest read-only
unprivilegedrole suffices; no administrator right needed. - GET endpoints with no CSRF token: also triggerable as CSRF-to-RCE against a logged-in user.
- Full compromise of the monitoring host, which routinely sees mirrored network traffic.
References
Is Something Like This in Your Software?
Our team found this vulnerability in the course of its work. Have your applications tested by the same specialists, with a penetration test from turingpoint.
