CVE-2026-57222: Suricata ippair: hash collision can cause incorrect state reuse across IPv4 and IPv6
Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to 7.0.17 and 8.0.6, crafted IPv4 and IPv6 address pairs can collide in the IPPair hash because src/ippair.c did not compare the IP address family before reusing IPPair-backed state. This can apply state from one IP family to another for xbits track ippair, FTP data expectations, and, on the 7.0 release line, thresholding, detectionfilter, and ratefilter rules using track byboth, causing incorrect detection state. This issue is fixed in versions 8.0.6 and 7.0.17.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Suricatato a version that resolves this vulnerability.Fixed in 8.0.6 - Upgrade
Upgrade
Suricatato a version that resolves this vulnerability.Fixed in 7.0.17
Event History
Frequently Asked Questions
Which deployments are exposed to incorrect state reuse?
Deployments running Suricata before 7.0.17 or 8.0.6 are affected when they process crafted IPv4 and IPv6 address pairs that collide in the IPPair hash. The impact applies to IPPair-backed features including xbits with track ip_pair and FTP data expectations.
Which rule configurations have additional exposure?
On the 7.0 release line, thresholding, detection_filter, and rate_filter rules that use track by_both can also reuse incorrect state across IP address families. This additional rule impact is specifically identified for 7.0.
What does an attacker need to do to trigger the issue?
An attacker needs to send crafted IPv4 and IPv6 address pairs that collide in the IPPair hash. No privileges or user interaction are required according to the supplied severity vector.
How can this be remediated?
Upgrade to Suricata 7.0.17 or 8.0.6, which fix the missing IP address-family comparison before IPPair-backed state is reused.