ntop ntopng missing authorization exposes system backups and credentials

ntopng is a web-based network traffic monitoring application. Prior to 6.7.260718, scripts/lua/rest/v2/get/system/configurations/list_available_backups.lua and scripts/lua/rest/v2/get/system/configurations/download_backup.lua allow any authenticated non-admin user to list and download system-configuration backups without an administrator check. The download path reaches backup_config.export_backup, and prefs_dump_utils.build_prefs_dump_table includes the ntopng.user.* Redis key space in the backup. A downloaded backup can therefore disclose password hashes for local users and, when configured, API tokens, TOTP secrets, and WebAuthn credential data, enabling account compromise through usable or recoverable credentials. This issue is fixed in version 6.7.260718.

• ntop ntopng: affected in versions < 6.7.260718. • The affected scope is the system-configuration backup listing and download functionality for authenticated non-admin users. • The vendor advisory identifies 6.7.260718 as the patched version. Later or parallel release branches are not separately validated by the available facts, so their status should not be inferred from this entry alone.

The flaw is a missing authorization check in two Lua REST GET handlers: scripts/lua/rest/v2/get/system/configurations/list_available_backups.lua and scripts/lua/rest/v2/get/system/configurations/download_backup.lua. These handlers let an authenticated non-admin user list and download system-configuration backups without an administrator or equivalent capability check. The download path calls backup_config.export_backup; the underlying export mechanism uses prefs_dump_utils.build_prefs_dump_table, which includes the ntopng.user.* Redis key space. As a result, a backup can contain local-user password hashes and, when configured, API tokens, TOTP secrets, and WebAuthn credential data. The requester supplies the backup selection used for download, while the required preconditions are an authenticated account and an available backup. The vendor patch adds isAdministratorOrPrintErr() checks to both handlers; the available evidence does not establish additional authorization behavior outside these endpoints.

The vulnerable functionality is reachable through the ntopng web interface and network service. Exploitation requires an authenticated non-admin account, but not administrator privileges; the record indicates low complexity and no interaction from another user. A public proof-of-concept status is recorded, and current advisory metadata classifies the exploitation status as PoC but not automated. The available evidence names no campaign, victim, or observed abuse, so public PoC status should not be read as confirmation of in-the-wild exploitation.

The flaw expands access from a normal authenticated ntopng account to backup data that should be restricted to administrators. Exposed data may include password hashes for multiple local accounts and additional secrets or credentials when configured. If a credential can be used directly or recovered, an attacker may take over the account and potentially obtain administrative control of the application; that outcome depends on the credential type and its practical usability. If a compromised account can change configuration, the integrity and trustworthiness of ntopng monitoring may be affected.

• Credential disclosure: Backups can contain the local-user credential store, including password hashes and, when configured, API tokens, TOTP secrets, and WebAuthn credential data. • Account compromise: Usable or recoverable credentials can let an attacker impersonate users. If an administrator credential or administrative token is recovered or exposed, the attacker may gain substantially broader control of ntopng. • Operational risk: A compromised account could be used to change configuration or reduce confidence in network monitoring. The actual effect depends on which credentials are configured, whether they were exposed, and whether they can be recovered or used. • Scope limitation: The evidence describes disclosure within ntopng. It does not establish disclosure outside the application or identify a specific data-breach event.

1. Upgrade ntopng to the exact version identified as fixed: 6.7.260718. Do not infer coverage for later or parallel release branches without separate confirmation.
2. If an instance was exposed and access to its backups cannot be ruled out, treat credentials in those backups as potentially compromised. Reset local-user passwords, revoke or regenerate API tokens, and assess replacement of TOTP secrets and re-enrollment of WebAuthn credentials according to the identity-management process.
3. Before patching, apply network-level access restrictions to ntopng as a temporary precaution, allowing access only from trusted administrative sources where operationally feasible. The available evidence does not confirm a separate workaround that safely disables the two endpoints.
4. After patching, review existing backups and access records to determine whether credential data may have been downloaded.

1. Inventory ntopng instances and verify their running versions, especially instances within the affected release boundary.
2. Identify available system-configuration backups, their storage locations, and which accounts can list or download them.
3. Review ntopng or reverse-proxy access logs for requests to list_available_backups.lua and download_backup.lua, with particular attention to requests made by non-admin accounts. This is a useful investigative signal, not a vendor-confirmed IOC.
4. Review audit logs, download records, and backup access permissions for the period in which an instance could have been affected. Absence of matching log evidence does not prove that a backup was not accessed.
5. If access by a non-admin user cannot be ruled out, treat credentials contained in the relevant backups as potentially exposed and follow the credential-change or revocation process.