FastNetMon: NetFlow/IPFIX template cache returns unlocked pointers, causing heap-use-after-free on multi-port deployments
Affects FastNetMon 1.2.9 and earlier when more than one NetFlow/IPFIX listener port is configured. The checked facts list no fix.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: The checked facts list no fix and no workaround. Since the bug requires more than one NetFlow/IPFIX listener port, running with a single listener port avoids the stated condition.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 30/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
FastNetMon, a high-performance DDoS detector and sensor, has a flaw in its NetFlow/IPFIX template handling that can be reached remotely, without logging in, on deployments that listen on at least two netflow_ports. An unauthenticated sender that can reach both listener ports can crash the service through a heap-use-after-free, and no fixed release is available yet.
Read the original 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.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach?/20Unknown. No tracked technology or package matched
- Severity7.5/10CVSS 7.5
- No patch5/5No patch listed yet
What would change the score
- Would score about 75 if added to CISA KEV
- Would score about 70 if CISA's SSVC rates exploitation active
- Would score about 35 if advisories confirm default setups are exposed
What to do
Workaround: The checked facts list no fix and no workaround. Since the bug requires more than one NetFlow/IPFIX listener port, running with a single listener port avoids the stated condition.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- pavel-odintsov fastnetmon
through 1.2.9
Evidence 2
- Advisory
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-93424
Is CVE-2026-93424 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
When two NetFlow/IPFIX listener threads share the template cache, the cache returns pointers without a lock. Memory can be freed while still in use, which crashes the FastNetMon process.Source: github.com
Which versions are affected by CVE-2026-93424?
fastnetmon: through 1.2.9.Source: cve.now feed data
Am I affected, and how do I check?
Versions up to and including 1.2.9 are listed. The bug needs more than one NetFlow/IPFIX listener port configured, so check the installed version and the number of listener ports in the FastNetMon configuration.Source: github.com
How do I fix CVE-2026-93424?
The checked facts name no fixed version, so no upgrade target can be given from them. Check the vendor's advisory for a fix before deciding on an upgrade.Source: github.com
What if there's no patch?
The checked facts list no fix and no workaround. Since the bug requires more than one NetFlow/IPFIX listener port, running with a single listener port avoids the stated condition.Source: github.com