FastNetMon: sFlow header_size field trusted as parser capture length causes remote out-of-bounds read
FastNetMon versions 1.2.9 and earlier are affected when the sFlow collector processes sFlow v5 UDP packets. No fixed version is listed in the checked facts.
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 workaround. Because the issue depends on sFlow v5 UDP input, turning off the sFlow collector or limiting it to trusted sources removes that exposure.
- 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 DDoS detection and sensor tool, can be crashed and partially read from over the network, without logging in, by sending a crafted sFlow packet. The flaw can cause an out-of-bounds memory read that crashes the process and may leak limited adjacent memory through parsed flow fields, 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, process_sflow_flow_sample() in src/sflow_plugin/sflow_collector.cpp passes the attacker-controlled sflow_raw_protocol_header_t.header_size to parse_raw_packet_to_simple_packet_full() as its trusted captured length without comparing it with the bytes remaining in the record. An inflated header_size creates a false end pointer beyond the received sFlow v5 UDP buffer, defeating the nested parser's bounds checks and causing an unauthenticated remote out-of-bounds read and process crash, with possible limited exposure of adjacent bytes through parsed flow fields. 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
- Severity8.2/10CVSS 8.2
- 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 workaround. Because the issue depends on sFlow v5 UDP input, turning off the sFlow collector or limiting it to trusted sources removes that exposure.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- pavel-odintsov fastnetmon
through 1.2.9
Evidence 5
- Advisory
- Repository
- Repository
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-92698
Is CVE-2026-92698 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?
A single crafted sFlow v5 UDP packet makes the FastNetMon sFlow collector read memory beyond the intended buffer. This crashes the collector and may leak a limited amount of adjacent memory through parsed flow fields.Source: github.com
Which versions are affected by CVE-2026-92698?
fastnetmon: through 1.2.9.Source: cve.now feed data
Am I affected, and how do I check?
FastNetMon 1.2.9 and earlier are affected when the sFlow collector processes sFlow v5 UDP packets. To check, look at the installed FastNetMon version and whether sFlow collection is enabled.Source: github.com
How do I fix CVE-2026-92698?
The checked facts do not name a fixed version. Check the vendor's advisory for an upgrade target later than 1.2.9.Source: github.com
What if there's no patch?
The checked facts list no workaround. Because the issue depends on sFlow v5 UDP input, turning off the sFlow collector or limiting it to trusted sources removes that exposure.Source: github.com