CVE-2026-57222: Suricata IDS IP Family Hash Collision Vulnerability

CVE-2026-57222 Overview

CVE-2026-57222 is a logic flaw in Suricata, the open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring engine maintained by the Open Information Security Foundation (OISF). Prior to versions 7.0.17 and 8.0.6, src/ippair.c did not compare the IP address family when reusing IPPair-backed state. Crafted IPv4 and IPv6 address pairs can therefore collide in the IPPair hash. State applied to one IP family can be incorrectly reused for another, affecting 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. The result is incorrect detection state and potential detection evasion.

Critical Impact
Attackers can cause IPv4 and IPv6 address pairs to share IPPair state, corrupting Suricata detection logic tied to IP-pair tracking and enabling silent evasion of thresholding, rate filtering, and FTP data expectations.

Affected Products

Suricata 7.0.x prior to 7.0.17
Suricata 8.0.x prior to 8.0.6
Deployments using xbits track ip_pair, FTP data expectations, or track by_both rule options

Discovery Timeline

2026-09-18 - CVE-2026-57222 published to the National Vulnerability Database (NVD)
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-57222

Vulnerability Analysis

Suricata maintains per-IP-pair state through an IPPair structure keyed by two addresses. The comparison routine in src/ippair.c matched addresses in both directions using the CMP_ADDR macro but omitted a check on the family field. Because the underlying address storage can hold either IPv4 or IPv6 values, two structurally similar entries from different families could satisfy the comparison and be treated as the same pair.

This is a comparison logic weakness classified under [CWE-697] (Incorrect Comparison). The impact is not memory corruption; it is functional integrity of detection state. Rules relying on xbits track ip_pair may read or set flags against the wrong session context. FTP data expectations may be paired with unrelated flows. On the 7.0 line, thresholding, detection_filter, and rate_filter rules using track by_both may undercount or overcount events, allowing alert suppression or misattribution.

Root Cause

The root cause is a missing address-family check inside the IPPair comparison function. Address bytes were compared without verifying that both endpoints were of the same family, allowing an IPv4 pair and an IPv6 pair to hash and compare as equal.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker sending crafted traffic across both IPv4 and IPv6 on a monitored network segment can induce state collisions in Suricata. Since Suricata sits inline or on a span, the attacker only needs their traffic to be inspected — no direct access to the sensor is required.

// Patch from src/ippair.c: enforce address-family check during IPPair comparison
{
    /* compare in both directions */
    if ((CMP_ADDR(&p->a[0], a) && CMP_ADDR(&p->a[1], b)) ||
            (CMP_ADDR(&p->a[0], b) && CMP_ADDR(&p->a[1], a))) {
        if (p->a[0].family == a->family) {
            return 1;
        }
    }
    return 0;
}

Source: Suricata commit 4a728464

Detection Methods for CVE-2026-57222

Indicators of Compromise

Suricata sensor running a version earlier than 7.0.17 or 8.0.6 with rules using xbits track ip_pair or track by_both
Unexpected drops or inconsistencies in alert counts for rules using thresholding, detection_filter, or rate_filter on the 7.0 line
FTP sessions where data-channel expectations attach to flows involving unrelated peers

Detection Strategies

Inventory Suricata deployments and query the running engine version via suricata --build-info to identify vulnerable installs
Review rule sets for use of track ip_pair and track by_both and correlate their alert volumes against baseline traffic
Compare alert telemetry across sensors of different versions to spot missing detections indicative of state collision

Monitoring Recommendations

Ingest Suricata eve.json output into a centralized analytics platform and alert on sudden drops in rule hit rates tied to IP-pair tracking
Monitor upstream package repositories for Suricata 7.0.17 and 8.0.6 availability and track patch deployment status
Watch for dual-stack (IPv4 and IPv6) traffic patterns from the same client that may indicate deliberate state-collision attempts

How to Mitigate CVE-2026-57222

Immediate Actions Required

Upgrade all Suricata sensors to version 7.0.17 or 8.0.6 as published in the OISF security advisory GHSA-2r8x-23fw-hgcg
Audit rule sets for reliance on xbits track ip_pair, track by_both, and FTP data expectations, and validate detection logic post-upgrade
Restart the Suricata service after upgrade to ensure new comparison logic is loaded

Patch Information

The fix is delivered in Suricata 7.0.17 and Suricata 8.0.6. The patch adds a family comparison inside the IPPair matcher in src/ippair.c, ensuring IPv4 and IPv6 pairs are no longer treated as equivalent. Reference commits: 4a728464, 9d788575, and c92e270c. See also Open Information Security Foundation issue #8559.

Workarounds

Where immediate upgrade is not possible, remove or replace rules using xbits track ip_pair and track by_both until sensors are patched
Disable FTP expectation tracking if the deployment does not require it and stateful FTP detection is not critical
Segment IPv4 and IPv6 monitoring onto separate Suricata instances so cross-family state collisions cannot occur on the same sensor

bash

# Verify Suricata version after upgrade
suricata --build-info | grep -i "this is suricata version"

# Expected output on patched systems:
# This is Suricata version 7.0.17 RELEASE
# or
# This is Suricata version 8.0.6 RELEASE