Skip to main content

FastNetMon Community CVE-2026-48682

| EUVDEUVD-2026-34021 MEDIUM
Access of Resource Using Incompatible Type (Type Confusion) (CWE-843)
2026-06-02 mitre GHSA-p5cp-vqjq-6cj7
5.9
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.9 MEDIUM
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

3
Analysis Generated
Jun 04, 2026 - 14:23 vuln.today
CVSS changed
Jun 04, 2026 - 14:22 NVD
5.9 (MEDIUM)
CVE Published
Jun 02, 2026 - 00:00 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

FastNetMon Community Edition through 1.2.9 contains an out-of-bounds read in the IPv4 packet parser. In src/simple_packet_parser_ng.cpp, after validating that the packet contains at least sizeof(ipv4_header_t) bytes (20 bytes), the code advances the local_pointer by '4 * ipv4_header->get_ihl()' (line 164) without validating that (a) IHL >= 5 (the minimum valid value per RFC 791), or (b) 4 * IHL bytes are actually available in the packet. The IHL field is 4 bits, allowing values 0-15, so the advance can be 0-60 bytes. An IHL value of 15 with only 20 bytes validated causes a 40-byte over-read. An IHL of 0-4 causes the pointer to not advance past the IP header, resulting in the TCP/UDP header being parsed from IP header data (type confusion). This vulnerability is reachable via any packet capture interface.

AnalysisAI

Out-of-bounds read in FastNetMon Community Edition through 1.2.9 allows unauthenticated remote attackers to disclose memory contents by sending crafted IPv4 packets with a manipulated IHL field to any monitored network interface. The parser in src/simple_packet_parser_ng.cpp validates only a 20-byte minimum buffer before blindly advancing a pointer by 4 * IHL bytes, enabling a 40-byte over-read (IHL=15) or type confusion where TCP/UDP structures are parsed from raw IP header bytes (IHL 0-4). No public exploit identified at time of analysis; EPSS (0.02%, 4th percentile) and SSVC (exploitation: none, automatable: no) both signal low near-term exploitation probability.

Technical ContextAI

FastNetMon is a high-performance DDoS detection tool that captures and parses raw network packets across monitored interfaces. The vulnerability resides in src/simple_packet_parser_ng.cpp at approximately line 164, within the IPv4 packet parsing path. Per RFC 791, the IHL (Internet Header Length) field is a 4-bit value representing the number of 32-bit words in the IPv4 header; valid values are 5-15 (20-60 bytes). The code correctly validates that the packet contains at least sizeof(ipv4_header_t) = 20 bytes, but then advances a local pointer by 4 * ipv4_header->get_ihl() without checking (a) IHL >= 5 as required by RFC 791, or (b) that 4 * IHL bytes are actually available beyond the validated region. CWE-843 (Access of Resource Using Incompatible Type) accurately characterizes both attack paths: an IHL of 0-4 causes the pointer to remain within or behind the IP header, so the subsequent TCP/UDP structure overlay is applied to IP header bytes - a classic type confusion - while an IHL of 15 advances the pointer 60 bytes into a buffer with only 20 bytes validated, producing a 40-byte out-of-bounds read. Both conditions are reachable through any packet capture interface FastNetMon is bound to.

RemediationAI

No vendor-released patch with a confirmed fix version has been identified at time of analysis - the GitHub repository reference in CVE data points to the project root and source file, not a fix commit or tagged release. Operators should monitor https://github.com/pavel-odintsov/fastnetmon for a patched release and apply it as soon as available. As a compensating control, restrict FastNetMon's capture interfaces to trusted internal segments (e.g., SPAN ports from core switches) rather than internet-facing links, which limits attacker ability to deliver crafted packets to the monitored path; trade-off is reduced visibility into perimeter traffic. Deploying a BPF (Berkeley Packet Filter) pre-filter to drop packets with IHL < 5 before FastNetMon processes them is a targeted and low-overhead workaround: for example, ip[0] & 0x0f < 5 in libpcap syntax would discard RFC-non-compliant headers. This filter blocks only malformed headers and should have negligible impact on legitimate traffic. See the researcher disclosure at https://lorikeetsecurity.com/blog/fastnetmon-cve-2026-48682-ipv4-parser-oob and NVD entry at https://nvd.nist.gov/vuln/detail/CVE-2026-48682 for additional context.

Share

CVE-2026-48682 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy