FastNetMon: IPv6 Fragment header dereferenced without bounds check in shared packet parser
Affects FastNetMon 1.2.9 and earlier when the sFlow UDP collector is enabled and receives sFlow v5 RAW_PACKET_HEADER records. The checked facts list no fixed version.
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 give no workaround. If it is possible in your setup, limit the affected feature by turning off the sFlow UDP collector or stopping it from receiving sFlow v5 RAW_PACKET_HEADER records.
- 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 product, has a flaw in its shared packet parser where an IPv6 Fragment header is read without first checking that the header's bytes are present. An attacker can reach this remotely without logging in by sending a crafted sFlow v5 packet record that omits those bytes, causing an out-of-bounds memory read that could impact confidentiality and availability.
Read the original description
FastNetMon is a high-performance DDoS detector and sensor. In version 1.2.9 and earlier, parse_raw_packet_to_simple_packet_full() in src/simple_packet_parser_ng.cpp dereferences ipv6_extension_header_fragment_t when IpProtocolNumberIPV6_FRAG is present without first verifying that the eight-byte Fragment header remains. A crafted sFlow v5 RAW_PACKET_HEADER record can remotely reach this shared parser with the Fragment bytes omitted, causing an unauthenticated remote out-of-bounds read. The supplied harness detects the read under AddressSanitizer, but the advisory does not establish a production process crash. 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 give no workaround. If it is possible in your setup, limit the affected feature by turning off the sFlow UDP collector or stopping it from receiving sFlow v5 RAW_PACKET_HEADER records.
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-92693
Is CVE-2026-92693 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?
The shared packet parser reads an IPv6 Fragment header without checking the packet's bounds, so it can read memory past the end of the packet buffer.Source: github.com
Which versions are affected by CVE-2026-92693?
fastnetmon: through 1.2.9.Source: cve.now feed data
Am I affected, and how do I check?
FastNetMon versions up to and including 1.2.9 are listed as affected. The bug is reached through the sFlow UDP collector when it receives sFlow v5 RAW_PACKET_HEADER records, so check whether that collector is enabled in your configuration and which version you run.Source: github.com
How do I fix CVE-2026-92693?
The checked facts name no fixed release, so no upgrade target can be given. Check the vendor's advisory for a fixed version.Source: github.com
What if there's no patch?
The checked facts give no workaround. If it is possible in your setup, limit the affected feature by turning off the sFlow UDP collector or stopping it from receiving sFlow v5 RAW_PACKET_HEADER records.Source: github.com