CVE-2026-92694 · Other
NO FIX YET
FastNetMon's IPv6 top-talkers screen thread reads a shared map without its lock while another thread inserts into it, causing undefined behavior under load. A crash is plausible, but a reliable denial of service has not been shown.
first public Jul 20, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Only deployments running FastNetMon 1.2.9 or earlier that monitor IPv6 networks listed in networks_list, and where the IPv6 top-talkers screen is drawn under load. The sources say no fixed release exists yet at review time. Deployments without IPv6 monitoring are not exposed by this race.
Not affected if newer-version, no-ipv6-networks
Who cares ddos-detection, fastnetmon, ipv6
1.2.9 and earlier are affected.networks_list includes any IPv6 range, since the race needs one to be monitored.No fix yet, per the sources.
FastNetMon is a high-performance DDoS detector and sensor. In version 1.2.9 and earlier, FastNetMon's IPv6 top-talkers screen-draw thread in draw_table_ipv6() in src/fastnetmon_logic.cpp iterates ipv6_host_counters.average_speed_map without holding counter_map_mutex while recalculate_speed() inserts new keys and may rehash the same map. The race requires networks_list to include the targeted IPv6 range. It causes confirmed undefined behavior under load; a process crash is plausible but was not observed, so reliable denial of service has not been established. No fixed release is available as of this review.
This page as .md · .json · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
. Posts quoted belong to their authors.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.