Description

ntopng is a web-based network traffic monitoring application. Prior to 6.7.260717, POST /lua/rest/v2/edit/system/edit_blacklist.lua in scripts/lua/rest/v2/edit/system/edit_blacklist.lua lacks an administrator check and calls lists_utils.editList for any authenticated user. The list_name, list_enabled, url, and list_update parameters allow a non-admin user to redirect threat-intelligence downloads to attacker-controlled content, disable blocklists, or prevent scheduled updates. The changes are persisted through Redis and reloaded without a lower-level authorization guard, undermining the integrity and availability of ntopng's threat-intelligence monitoring. This issue is fixed in version 6.7.260717.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-21T17:19:08.590Z",
  "pubdate": "2026-09-21T17:19:08.590Z",
  "executiveSummary": "The vulnerability involves an improper authorization check within the ntopng web interface, specifically affecting the blacklist management functionality. The flaw allows any authenticated user, regardless of their role or administrative privileges, to invoke the edit_blacklist.lua script. This capability permits unauthorized modifications to threat-intelligence configuration settings stored within the Redis backend. The primary impact includes the potential redirection of security intelligence feeds to malicious endpoints, the forced disabling of defensive blocklists, and the disruption of scheduled system updates. Because these configurations are persisted and reloaded by the application without subsequent internal authorization verification, an attacker can effectively compromise the integrity and availability of the system's threat-monitoring infrastructure. The vulnerability is present in versions of ntopng prior to 6.7.260717, posing a significant risk to network visibility and security posture.",
  "technicalDetails": "The root cause of this vulnerability is a missing access control check within the scripts/lua/rest/v2/edit/system/edit_blacklist.lua script. In ntopng, this script is designed to handle configuration updates for threat-intelligence blocklists. However, the application fails to validate that the user initiating the request possesses administrative privileges before proceeding with the operation. Consequently, any authenticated user can successfully execute the handler.\nUpon receiving a POST request to /lua/rest/v2/edit/system/edit_blacklist.lua, the application invokes the lists_utils.editList function. This function processes multiple input parameters, including 'list_name', 'list_enabled', 'url', and 'list_update'. Because there is no guard clause checking the user's role, the application treats these parameters as legitimate configuration changes, applying them to the underlying Redis database where ntopng maintains its persistent application state.\nThe attack flow proceeds as follows: First, the attacker authenticates to the ntopng web interface as a standard user. Second, the attacker crafts a malicious POST request targeting the vulnerable Lua endpoint. By manipulating the 'url' parameter, the attacker can point the application's threat-intelligence download service to an arbitrary, attacker-controlled server. By setting 'list_enabled' to a false state, the attacker can effectively silence specific security alerts or prevent the enforcement of blocklists. Finally, because the application reloads these configuration parameters from Redis without additional privilege-based filtering, the malicious changes take immediate effect.\nThe impact of this exploit is severe, as it facilitates a Man-in-the-Middle (MitM) scenario for threat intelligence feeds. By redirecting the source of blocklist updates, an attacker can influence the application's detection logic, potentially masking malicious traffic or introducing false positive triggers. Furthermore, the ability to disable blocklists or block scheduled updates reduces the overall efficacy of the security monitoring solution. Since the configuration changes are persisted, the impact persists across application restarts. The vulnerability highlights a failure in the 'Defense in Depth' strategy, as the back-end processing logic (lists_utils.editList) implicitly trusts the state data modified by the front-end API without re-validating the authorization context of the change request.\nThis vulnerability is confirmed to be patched in version 6.7.260717, which implements the necessary administrative validation to ensure that only authorized personnel can modify system-wide threat-intelligence configurations."
}