CVE-2026-48690

Vulnerability

In FastNetMon Community Edition through 1.2.9, the allocate_buffer() function in src/packet_storage.hpp computes memory_size_in_bytes using 32-bit unsigned integer arithmetic: buffer_size_in_packets * (max_captured_packet_size + sizeof(fastnetmon_pcap_pkthdr_t)) + sizeof(fastnetmon_pcap_file_header_t). With max_captured_packet_size=1500 and sizeof(fastnetmon_pcap_pkthdr_t)=16, each packet requires approximately 1516 bytes. If buffer_size_in_packets exceeds about 2,832,542, the multiplication overflows, wrapping to a small allocation size. The buffer_size_in_packets is derived from the ban_details_records_count configuration parameter in fastnetmon.conf, parsed by atoi() without overflow checking [1][3].

Exploitation

An attacker with local access to the FastNetMon configuration file can set ban_details_records_count to a value equal to or greater than 2,832,542. When the application starts, allocate_buffer() performs the overflowed multiplication, allocating a heap buffer significantly smaller than intended. Subsequent calls to write_packet() that store captured packets into this buffer will write beyond the allocated bounds, causing heap corruption [1]. The allocation overflow triggers on startup rather than requiring a specific runtime trigger beyond the configuration change.

Impact

Successful exploitation results in heap-based buffer overflow, leading to heap corruption. Adjacent heap memory can be corrupted when write_packet() writes past the undersized buffer's boundaries. This can likely lead to arbitrary code execution or denial of service, depending on heap layout [1]. No authentication or network access is needed; only the ability to modify the local configuration file is required.

Mitigation

As of the publication date, no vendor fix has been released for CVE-2026-48690; FastNetMon LTD did not respond to Lorikeet Security's disclosure [1]. Users of FastNetMon Community Edition 1.2.9 and earlier should ensure ban_details_records_count is set to a safe value (below 2,832,542). Monitor vendor channels for a patched version. No workaround beyond configuration restriction is currently available [1][2].