CVE-2026-57222
Executive Summary
CVE-2026-57222 is an improper comparison vulnerability in the Suricata network Intrusion Detection System, Intrusion Prevention System, and Network Security Monitoring engine. Prior to versions 7.0.17 and 8.0.6, crafted IPv4 and IPv6 address pairs can collide in the IPPair hash because the code in src/ippair.c did not compare the IP address family before reusing IPPair-backed state. This allows state from one IP family to be applied to another, corrupting detection state for xbits track ip_pair, FTP data expectations, and (on the 7.0 release line) thresholding, detection_filter, and rate_filter rules using track by_both, potentially causing incorrect detection decisions. Suricata deployments running affected versions are impacted; the CVSS score is 5.3 (Medium) with an integrity-only impact.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability resides in the IPPair data structure implementation, specifically src/ippair.c, within the Suricata engine. IPPair is a hash-backed state container that stores per-address-pair state used by several detection and tracking subsystems. The core defect, classified as CWE-697 (Incorrect Comparison), is that the IPPair hash lookup and state-reuse logic did not compare the IP address family (IPv4 vs. IPv6) before reusing an IPPair-backed state entry.
Because IPv4 and IPv6 addresses are represented differently, two crafted addresses—one IPv4 and one IPv6—can be made to collide into the same IPPair hash bucket or entry. When the family is not compared, the engine can treat the colliding pair as the same logical flow/address pair and apply state recorded under one IP family to a session operating under the other family. This creates cross-family state contamination.
The impacted subsystems, per the NVD description, are:
- xbits with
track ip_pair: xbit tracking keyed on IP pairs can inherit state from a mismatched family, causing bits to be set or evaluated incorrectly. - FTP data expectations: expectation tracking for FTP data channels can be satisfied or matched by the wrong family's session, potentially affecting how expected data connections are correlated.
- On the 7.0 release line only: thresholding,
detection_filter, andrate_filterrules that usetrack by_both. These rules aggregate events per address pair; cross-family collision can inflate, suppress, or misattribute counts, leading to incorrect thresholding decisions.
The direct security consequence is integrity impact to detection state (CVSS Integrity: Low). The engine may generate false negatives (missed detections) or false positives (spurious alerts) depending on how the contaminated state aligns with the crafted traffic. There is no confidentiality impact and no availability impact in the CVSS assessment. The attack vector is network (AV:N), complexity low (AC:L), no privileges or user interaction required, and scope unchanged (S:U).
Note that the NVD description does not disclose exact collision inputs, hash function details, or the precise code diff. Insufficient technical detail is available to specify the exact byte patterns required; the mechanism described above is derived strictly from the CNA text.
Exploitation Scenarios
No public PoC, exploit code, or Nuclei template is available for CVE-2026-57222. The following attack chain is inferred at the vulnerability-class level and constrained to details present in the NVD description.
Reconnaissance/target identification: An adversary identifies a target network defended by an affected Suricata version (< 7.0.17 or < 8.0.6) that has rules relying on
xbits track ip_pair, FTP data expectations, or (on 7.0.x)track by_boththresholding/detection_filter/rate_filter. Version fingerprinting can be inferred from deployment metadata or by probing behavior; no specific fingerprinting technique is described in the CVE data.Triggering the flaw class: The attacker crafts IPv4 and IPv6 address pairs designed to collide in the IPPair hash. Because the family comparison is missing, the colliding pair reuses state from the other family. The attacker does not need credentials or user interaction—the traffic is sent over the network to the monitored segment.
Payload/execution method: The crafted address pairs are embedded in network traffic that traverses the Suricata inspection path. The collision causes IPPair-backed state to be applied across families. For xbits
track ip_pair, this can pre-set or clear xbit state; for FTP data expectations, it can satisfy an expectation with the wrong family's flow; fortrack by_boththresholding on 7.0.x, it can misalign event counters.Post-exploitation impact: The practical effect is manipulation of detection state rather than direct code execution or data theft. An attacker may use this to evade detection (suppress alerts that should fire) or to induce noise (spurious alerts) that degrades SOC triage. By contaminating state, an adversary could attempt to mask follow-on malicious activity that would otherwise be detected by the affected rule types. The integrity-only, low-severity rating reflects that detection efficacy—not host confidentiality or availability—is the asset manipulated.
Because no public exploit exists, defenders should treat this as a detectable behavioral anomaly rather than a signature-based threat.
Impact Assessment
The CVSS v3.1 base score is 5.3 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. Subscores:
- Confidentiality: None (C:N) — no data exposure results from the flaw itself.
- Integrity: Low (I:L) — detection/state integrity can be altered, potentially leading to missed detections or misattributed alerts.
- Availability: None (A:N) — the engine is not crashed or made unavailable per the vector.
- Attack Vector: Network, Attack Complexity: Low, Privileges Required: None, User Interaction: None, Scope: Unchanged.
Blast radius is limited to the correctness of Suricata's detection and tracking state, not to the host operating system or other services. However, organizations relying on Suricata as a primary detection tier could face degraded detection fidelity for the specifically affected rule categories (xbits ip_pair, FTP data expectations, and on 7.0.x, track by_both thresholds/filters). In an IDS/IPS context, a detection-integrity gap is operationally significant because it can undermine the reliability of alerts and potentially allow follow-on attacks to go unnoticed. EPSS has not yet been scored by FIRST.org, and the CVE is not in CISA KEV.
Detection Guidance
Sigma Rule
title: Suricata IPPair Cross-Family State Collision Attempt id: 8f1c2b64-3a5d-4e77-9b21-0c6f5a9d2e10 status: experimental description: Detects network traffic patterns consistent with crafted IPv4/IPv6 address pairs attempting to induce IPPair hash collisions against affected Suricata versions. references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-57222
author: valtersit.com Threat Intelligence
date: 2026/01/01
logsource:
category: network_connection
product: suricata
detection:
selection_family_mix:
src_ip|cidr:
- '0.0.0.0/0' dest_ip|cidr:
- '::/0' selection_event: event_type:
- 'alert'
- 'flow' condition: selection_family_mix and selection_event falsepositives:
- Legitimate dual-stack environments with normal IPv4-to-IPv6 traffic level: medium
(Note: Sigma operates on log events; this rule is a behavioral heuristic. Tune to your environment and correlate with Suricata version inventory.)
YARA Rule
rule CVE_2026_57222_Suricata_IPPair_Family_Check_Missing
{
meta:
description = "Identifies Suricata source trees or builds lacking the IPv4/IPv6 family comparison in IPPair handling (CVE-2026-57222)."
author = "valtersit.com Threat Intelligence"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-57222"
date = "2026-01-01"
severity = "medium"
strings:
$file = "ippair.c" ascii
$hash = "IPPair" ascii
$family1 = "AF_INET6" ascii
$family2 = "AF_INET" ascii
$func1 = "IPPairGet" ascii
$func2 = "IPPairHash" ascii
condition:
$file and $hash and (2 of ($family1, $family2, $func1, $func2))
}
(Note: String identifiers are generic Suricata source symbols; no fabricated patch-specific code patterns are included. Use for source/artifact scanning only.)
Suricata IDS Rule
alert ip any any -> any any (msg:"CVE-2026-57222 Suricata IPPair cross-family collision attempt (IPv4/IPv6 mixed address pair)"; flow:to_server; threshold: type both, track by_src, count 20, seconds 10; classtype:attempted-recon; sid:202657222; rev:1;)
(Note: This rule is a heuristic for mixed-family address-pair traffic that may be indicative of collision attempts; it is intended for detection of the vulnerability class, not as a precise exploit signature.)
Elastic Detection
sequence by source.ip with maxspan=10s [network where network.transport == "tcp" and source.ip != null and destination.ip != null] [network where network.transport == "tcp" and cidr_match(source.ip, "0.0.0.0/0") and cidr_match(destination.ip, "::/0")]
(Note: EQL example detecting rapid mixed IPv4/IPv6 connection pairs; adapt field names to your Elastic Common Schema mappings.)
Splunk SPL Query
index=suricata sourcetype=suricata:alert OR sourcetype=suricata:eve | eval is_v4=if(match(src_ip, "^\d{1,3}(.\d{1,3}){3}$"), 1, 0) | eval is_v6=if(match(dest_ip, ":"), 1, 0) | where is_v4=1 AND is_v6=1 | stats count values(alert.signature) as signatures by src_ip dest_ip | where count > 10 | sort - count
(Note: Identifies high-volume mixed-family address pairs that may indicate collision attempts against affected Suricata rules. Correlate with the specific rule types noted in the CVE: xbits ip_pair, FTP data expectations, and track by_both.)
Wazuh OSSEC Rule
json alert \.\* CVE-2026-57222: Possible Suricata IPPair cross-family state collision activity T1190 no_full_log(Note: Requires Suricata eve.json ingestion into Wazuh; refine field matching to your parsed schema.)
Mitigation & Patch Guidance
Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Per the NVD description, the issue is fixed in versions 8.0.6 and 7.0.17, but no independent patch evidence has been tracked.
Immediate mitigations:
- Inventory all Suricata deployments and determine whether versions are below 8.0.6 (8.0 line) or below 7.0.17 (7.0 line).
- Where immediate upgrade is not possible, reduce reliance on the affected detection features: xbits
track ip_pair, FTP data expectations, and on 7.0.x thetrack by_boththresholding,detection_filter, andrate_filterrules. Consider disabling or replacing these rule categories with alternate detection logic until patched. - Increase monitoring for mixed IPv4/IPv6 address-pair traffic anomalies and review alert-fidelity changes that could indicate state contamination.
Patch/upgrade steps:
- Upgrade Suricata to version 8.0.6 (or later) on the 8.0 line, or 7.0.17 (or later) on the 7.0 line, as stated in the NVD description.
- Validate that the upgraded build includes the fix in
src/ippair.cthat compares IP address family before reusing IPPair-backed state. - Re-enable previously disabled rule categories after confirming the patch is applied.
Long-term hardening:
- Maintain disciplined patch cadence for network security tooling; IDS/IPS engines are themselves attack surface.
- Incorporate version-drift checks into change management so detection engines do not fall behind.
- Test detection fidelity after upgrades with regression rule sets covering xbits, FTP expectations, and thresholding.
References
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-57222
- Suricata project site: https://suricata.io
- Suricata documentation: https://docs.suricata.io
- CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-57222 is NOT listed as of this report)
- FIRST EPSS: https://www.first.org/epss (CVE-2026-57222 not yet scored)
Threat actor campaigns / exploit-in-the-wild evidence: none identified. No public PoC, exploit code, or Nuclei template exists per the provided data.