Heap-buffer-overflow in ntop ntopng mDNS dissection can cause denial of service

A heap-buffer-overflow vulnerability has been identified in ntopng 6.2 in the Flow::dissectMDNS function.

The base CNA record leaves the affected product as n/a, but enriched affected data and the maintainer issue identify ntop ntopng 6.2 as affected.

• Upstream: ntopng 6.2 is affected. The available evidence does not establish the status of other upstream releases.
• CBL Mariner 2.0: Microsoft CSAF VEX lists cbl2 ntopng 0:5.2.1-3.cbl2, cbl2 ntopng 5.2.1-4, and cbl2 ntopng 0:5.2.1-4.cbl2 as affected components.
• Azure Linux 3.0: Microsoft CSAF VEX lists azl3 ntopng 0:5.2.1-5.azl3, azl3 ntopng 0:5.2.1-6.azl3, and azl3 ntopng 0:5.2.1-7.azl3 as affected components.
• No upstream fixed release is established by the record or inspected issue. The downstream package entries are separate packaging branches and do not establish the status of every other release.

The flaw is in the mDNS flow dissection path handled by Flow::dissectMDNS. The project issue places the function in Flow.cpp at line 6516 and states that crafted input can trigger the defect when the fuzz_dissect_packet binary is run with the OSS-Fuzz configuration. AddressSanitizer reported a 42-byte read immediately after a 544-byte heap region, with frames involving strncpy and Flow::dissectMDNS. The call path continues through NetworkInterface packet-processing functions, showing that the fault occurs during packet dissection. The available evidence establishes a heap out-of-bounds read and crash condition, but does not establish the exact production input boundary in every deployment or whether every traffic-ingestion path reaches the same code path.

The supplied assessment classifies reachability as local, requires no privileges, and requires no user interaction; complexity is assessed as low. The public project issue documents a reproducer based on crafted input and an AddressSanitizer report. The record marks public exploit evidence as present, but the inspected sources do not identify a weaponized exploit, campaign, victim, or breach. Remote exploitation over a network is not established by the available evidence.

The demonstrated technical outcome is a heap out-of-bounds read that can crash ntopng and interrupt packet processing. The record does not establish sensitive-data disclosure, data modification, privilege escalation, or code execution; the stated impact is concentrated on availability. The available assessment does not indicate a change in security scope, so there is no evidence that the flaw by itself crosses another security boundary. Organisational consequences could include loss of monitoring service, missing observations during a crash, and a need for restart or failover where the deployment supports those mechanisms.

The flaw can crash ntopng while it is processing packets, interrupting the service and creating gaps in monitoring or analysis that depend on it. The established impact is primarily to availability; the record does not identify disclosure of data or modification of data integrity. The local access condition makes direct Internet exposure unestablished, but it does not remove risk on hosts or packet-processing pipelines that can supply untrusted input. The public reproducer increases the importance of inventory and controlled validation for exposed deployments.

1. Identify and remove or replace ntopng 6.2 and the listed affected downstream packages before they continue processing untrusted input.
2. Apply a vendor-provided correction when ntop or the relevant distributor publishes an advisory and confirmed fixed release. No exact upstream fixed release is established by the inspected evidence.
3. For the listed CBL Mariner and Azure Linux packages, the Microsoft CSAF VEX data records none_available and does not provide a replacement build in the inspected remediation data.
4. If an update is not yet available, use precautionary operational controls such as isolating the service and limiting untrusted packet or packet-capture sources that can reach ntopng. This is general risk reduction, not a maintainer-confirmed mitigation.
5. After updating, recheck package inventory and perform isolated validation to confirm that the running binary is not one of the affected builds.

1. Inventory all ntopng installations and downstream packages, recording the upstream version, distribution, and exact package build.
2. Prioritize review of ntopng 6.2 and the CBL Mariner and Azure Linux builds listed in the affected scope.
3. Review process-crash or restart telemetry for ntopng during packet processing. This is an operational warning sign, not a confirmed IOC.
4. In an isolated test environment, compare behavior with the maintainer's reproducer and look for AddressSanitizer reports containing heap-buffer-overflow and Flow::dissectMDNS.
5. Identify systems that allow untrusted packet or packet-capture data to reach ntopng. Absence of crash logs does not prove that a system is safe.