Description

FastNetMon is a high-performance DDoS detector and sensor. In version 1.2.9 and earlier, peer_find_template() in src/netflow_plugin/netflow_collector.cpp and src/netflow_plugin/netflow_v9_collector.cpp returns a pointer into global_netflow9_templates after releasing the cache mutex. On deployments with at least two entries in netflow_ports, concurrent template redefinition and data-flowset processing can let add_update_peer_template() reassign the template and free its records vector while another listener dereferences the escaped pointer. An unauthenticated sender that can reach both NetFlow/IPFIX listener ports can trigger a heap-use-after-free and reliably crash FastNetMon. No fixed release is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-05T23:17:02.817Z",
  "pubdate": "2026-11-05T23:17:02.817Z",
  "executiveSummary": "FastNetMon versions 1.2.9 and earlier are susceptible to a heap-use-after-free vulnerability originating from improper concurrency control within the NetFlow/IPFIX collection process.\nThe vulnerability occurs in the peer_find_template() function, which exposes a dangling pointer into global_netflow9_templates after releasing the associated cache mutex.\nAn unauthenticated attacker capable of sending malicious NetFlow or IPFIX packets to the listener ports can trigger this condition by inducing concurrent template redefinition and data-flowset processing.\nSuccessful exploitation results in memory corruption and a reliable application crash, potentially leading to a denial-of-service state for the DDoS detection sensor.\nThe risk is elevated for deployments configured with two or more entries in netflow_ports, as the race condition requires multi-threaded contention to reassign and free the underlying records vector while the pointer is still being dereferenced by a parallel listener thread.\nAs of the reporting date, no official security patch is available to resolve this concurrency flaw.",
  "technicalDetails": "The vulnerability resides in the NetFlow processing logic, specifically within src/netflow_plugin/netflow_collector.cpp and src/netflow_plugin/netflow_v9_collector.cpp.\nThe root cause is a race condition involving the lifecycle management of templates stored in global_netflow9_templates. The function peer_find_template() performs a lookup for a template entry but incorrectly releases the cache mutex before the calling function finishes utilizing the returned pointer.\nDuring concurrent execution, if add_update_peer_template() is invoked—triggered by an attacker sending specialized NetFlow/IPFIX packets—it may initiate a redefinition of the template. This process involves reassigning the template memory and deallocating the existing records vector.\nBecause the initial thread holds a dangling pointer to this memory (having received it from peer_find_template()), the subsequent dereference of this memory after the deallocation constitutes a heap-use-after-free condition.\nThe attack flow follows these steps: 1) The attacker initiates two or more simultaneous streams targeting different NetFlow listener ports. 2) One stream triggers a lookup in peer_find_template(), which retrieves a pointer and subsequently drops the mutex lock. 3) A second stream simultaneously triggers add_update_peer_template(), forcing a redefinition of the shared template, which calls free() on the records vector currently held by the first thread. 4) The first thread attempts to access the now-freed memory, leading to an immediate segmentation fault or undefined behavior.\nThis vulnerability requires that the target deployment has at least two active listeners in netflow_ports to ensure the necessary thread contention. The impact is significant as it provides a mechanism for an unauthenticated remote attacker to reliably force a crash of the FastNetMon service, effectively bypassing the DDoS detection and monitoring capabilities of the sensor.\nThe vulnerability is present in versions 1.2.9 and earlier. Given the nature of the issue—a race condition within pointer management and synchronization primitives—mitigation requires robust locking mechanisms, such as implementing reference counting for template objects or extending the critical section to ensure the pointer remains valid until all dereferencing operations are complete."
}