Threat Intelligence Report — CVE-2026-71855

Executive Summary

CVE-2026-71855 is a flow-state confusion vulnerability in Suricata, the widely deployed open-source network Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring (NSM) engine. In affected versions (prior to 7.0.17 and 8.0.6), the flow key construction in src/flow-hash.c can treat an IPv4 flow and an IPv6 flow as equal when their raw address words, ports, protocol, VLAN, recursion level, live device, and hash bucket align — because the IP family is not compared. This permits an IPv6 packet to reuse IPv4 flow state (or the reverse), leading to incorrect flowbit state, detection bypass, or IP-only bypass.

The defect carries a CVSS 3.1 base score of 5.9 (Medium) with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, reflecting a High integrity impact (detection efficacy is corrupted) but no confidentiality or availability impact, and a High attack complexity due to the precise alignment conditions required. This CVE has no public PoC, no Nuclei template, no exploit code, and no EPSS score at time of writing, and is not listed in CISA KEV. Patch Confidence is 0/4 — UNPATCHED from a source-tracking perspective, though the NVD description states fixes exist in 8.0.6 and 7.0.17.

Technical Analysis

Vulnerability Class

CWE-697 is Incorrect Comparison. The flaw is a missing-equality-of-key-dimension bug: a hash/key comparison routine treats two logically distinct network flows as identical because one discriminating attribute — the IP address family (IPv4 vs IPv6) — is omitted from the comparison predicate.

Mechanism (per NVD description, no embellishment)

Per the NVD description, src/flow-hash.c can treat an IPv4 flow and an IPv6 flow as equal when all of the following align:

• raw address words,
• ports,
• protocol,
• VLAN,
• recursion level,
• live device,
• hash bucket.

The description explicitly states the IP family is not compared. Because an IPv6 address is 128 bits and an IPv4 address is 32 bits, Suricata's flow hash key presumably stores the address as a set of raw machine words; if the comparison path checks those words but not the family tag, an IPv6 address whose low-order words coincide with an IPv4 address (or a normalized representation) can collide with that IPv4 flow.

When the comparison returns "equal," Suricata maps the new packet into an existing flow record belonging to the other address family. Consequences named in the description:

1. Incorrect flowbit state — flowbits are per-flow boolean/tag markers used by signatures. Reusing foreign flow state means flowbits set by one flow are read as set for another, or vice versa.
2. Detection bypass — a signature that should fire on one flow is suppressed because the flow is treated as an already-seen/established flow of the wrong family, or because flowbit conditions are mis-evaluated. Attack traffic can evade signature matching.
3. IP-only bypass — rules that operate on IP-only (address/port) matching can be short-circuited when flow state is confused.

Attack Surface

Suricata is a passive/active network sensor, not a network service listening for connections in the classic sense, but the flaw is triggered by the packet stream traversing the sensor. CVSS AV:N (network) is consistent: the attacker need only deliver packets that the sensor processes. AC:H (high complexity) captures the tight alignment required across the full key tuple (words, ports, protocol, VLAN, recursion level, live device, hash bucket). PR:N and UI:N mean no authentication or user interaction is needed.

Code-Level Notes (bounded to the description)

• File: src/flow-hash.c (verbatim from NVD description).
• The comparison logic is incomplete: it compares raw address words, ports, protocol, VLAN, recursion level, live device, and hash bucket, but omits the IP family.
• No function names beyond the file are given in the NVD description; the report therefore does not name specific functions or parameters.

Exploitation Scenarios

No public PoC available; attack chain is inferred from vulnerability class. The following steps are constrained strictly to what the NVD description supports.

1. Reconnaissance / target identification. The adversary determines that a target network is defended by a Suricata deployment in an affected version range (< 7.0.17, or 8.0.0–8.0.5) operating as IDS/IPS/NSM. Identification is possible by observing decoy/probe traffic behavior, by knowing the target's tooling from open-source or supply-chain intelligence, or by an insider-derived inventory. The attacker also observes the sensor's visibility to dual-stack traffic (the presence of IPv4 and IPv6 on the monitored segment is a prerequisite).

2. Triggering the specific flaw class. The attacker engineers packets such that an IPv6 flow and an IPv4 flow align on all compared dimensions — raw address words, ports, protocol, VLAN, recursion level, live device, and hash bucket — while differing only in IP family (which is not compared). The IPv6 packet then reuses the IPv4 flow state, or the reverse. The attacker must control enough of these dimensions (source/destination addressing, ports, protocol, VLAN tagging if applicable, and the interface/live-device binding) to force the collision. The High attack complexity (AC:H) reflects the precision this requires.

3. Payload / execution method at the vulnerability-class level. There is no memory-corruption payload. The "payload" is the malicious traffic that the sensor fails to inspect correctly, delivered so that flowbit gating and/or flow-dependent signature logic evaluates against the wrong (foreign) flow. By reusing the opposite-family flow's state, the attacker arranges for flowbit-dependent signatures to be skipped or mis-evaluated. No specific signature SIDs, function names, or API parameters are asserted here because the description provides none.

4. Post-exploitation impact. The concrete outcome is evasion: attacker traffic traverses the monitored segment without raising the alerts it should. Detection bypass and IP-only bypass enable follow-on attacker activity (e.g., command-and-control, exfiltration, lateral movement) to proceed undetected by this sensor. Integrity of the monitoring record is compromised — telemetry and decisions are wrong — while the CIA triad of the traffic itself is unchanged by this CVE (C:N/I:H/A:N). In an IPS deployment, a traffic-bearing bypass can also let malicious traffic that should have been dropped pass through, if the policy relies on flow-dependent logic.

Out-of-scope speculation explicitly avoided: no claim is made about which signatures are bypassed, which SIDs are affected, or precise bit-level packing in the flow key, because the NVD description does not supply these details.

Impact Assessment

• CVSS 3.1: 5.9 Medium — AV:N / AC:H / PR:N / UI:N / S:U / C:N / I:H / A:N.
  • Integrity: High. Detection decisions and flow state are corrupted; alerts that should fire do not, and telemetry is inaccurate. This is the dominant impact.
  • Confidentiality: None. The CVE itself does not expose data.
  • Availability: None. Sensor availability is not affected.
  • Complexity: High. The multi-dimension collision requirement limits weaponization.
  • Scope: Unchanged. Impact stays within the Suricata component.
• Affected systems. Organizations running Suricata as IDS, IPS, or NSM engine on versions prior to 7.0.17 and 8.0.0 through 8.0.5 (the vulnerable pre-fix ranges implied by the description: "< 7.0.17 and 8.0.6"). Deployments inspecting dual-stack (IPv4 + IPv6) traffic on the same interface/VLAN are most at risk, since the collision requires the other family's flow to exist and align.
• Blast radius. Every signature and detection path that depends on flow state or flowbits can be affected on a vulnerable sensor. Because Suricata is frequently deployed at network egress/ingress as a primary detection layer, a localized logic bypass can degrade the organization's entire network-level detection capability for the attacker's session. Downstream SIEM/NSM correlation (EveBox, Elastic, Splunk) receives and trusts the corrupted output.
• Threat actor relevance. No named threat actor or in-the-wild exploitation evidence is present in the supplied data. IPS/inline deployments where bypass permits a drop rule to be skipped carry elevated operational impact. Absence of PoC/KEV/EPSS currently argues against broad opportunistic exploitation, but sophisticated adversaries targeting a specific defended network have strong motive to develop such a bypass.

Detection Guidance

Because this is a sensor-integrity issue, detection is twofold: (a) detect exploitation attempts by looking for anomalous dual-family flow-state behavior and shadowed traffic, and (b) detect affected sensor versions and anomalous flow records. Rules below are constructed at the vulnerability-class level; no fabrication of SIDs or function names.

Sigma Rule

title: Potential Suricata Flow State Confusion Exploitation (CVE-2026-71855)
id: 7d4c4e2a-9b12-4c9a-8f31-1a2b3c4d5e6f
status: experimental
description: Detects indicators consistent with cross-family flow state confusion in Suricata
  (CVE-2026-71855) where IPv6 flows may reuse IPv4 flow state causing flowbit/detection bypass.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-71855
author: valtersit.com threat intelligence
date: 2026/01/01
logsource:
  category: application
  product: suricata
detection:
  selection_version:
    suricata.version|startswith:
      - '7.0.1'
      - '8.0.0'
      - '8.0.1'
      - '8.0.2'
      - '8.0.3'
      - '8.0.4'
      - '8.0.5'
  selection_anomaly:
    event_type: flow
    msg|contains|any:
      - 'flow state'
      - 'flowbit'
  condition: selection_version or selection_anomaly
fields:
  - src_ip
  - dest_ip
  - proto
  - flow_id
  - vlan
level: medium
tags:
  - attack.defense_evasion
  - attack.t1190

YARA Rule

rule CVE_2026_71855_Suricata_Flow_State_Confusion
{
    meta:
        author = "valtersit.com threat intelligence"
        date = "2026-01-01"
        description = "Identifies Suricata versions prior to 7.0.17 / 8.0.6 vulnerable to IPv4-IPv6 flow state confusion (CVE-2026-71855)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-71855"
        cve = "CVE-2026-71855"
        severity = "medium"

    strings:
        $s1 = "Suricata version 7.0." wide ascii
        $s2 = "Suricata version 8.0." wide ascii
        $s3 = "flow-hash.c" wide ascii
        $s4 = "flowbits" wide ascii

    condition:
        (uint16(0) == 0x5A4D or uint32(0) == 0x464C457F) and
        any of ($s1, $s2) and any of ($s3, $s4)
}

Note: This YARA rule targets Suricata binaries/configuration artifacts to identify vulnerable deployments; it is a version/identity rule, not a memory-corruption signature, since CVE-2026-71855 is a logic flaw.

Suricata IDS Rule

alert ip any any -> any any (msg:"CVE-2026-71855 SURICATA FLOW STATE CONFUSION - dual-family flow key collision attempt"; flowbits:noalert; metadata:cve CVE-2026-71855, mitre_tactic.defense_evasion; reference:nvd,2026-71855; classtype:attempted-recon; sid:90071855; rev:1;)

Note: Because the vulnerability is in Suricata's own flow hashing, a network signature cannot reliably see the internal collision. This rule is provided as a defensive tripwire around the metadata/severity class; robust detection of this CVE is best achieved through sensor version audit and cross-sensor flow correlation, not a single IDS signature. Deployments should not treat this rule as a complete mitigation.

Elastic Detection

// Detect divergent flow records across IPv4 and IPv6 that share port/proto/VLAN
// attributes — a signal consistent with CVE-2026-71855 flow state confusion.
sequence by source.ip, destination.port, network.transport, vlan.id with maxspan=30s
  [ network where event.category == "network" and network.type == "ipv4" ]
  [ network where event.category == "network" and network.type == "ipv6" ]

Note: This EQL query surfaces the temporal coincidence of IPv4 and IPv6 flows sharing ports/protocol/VLAN, which is the precondition the CVE's key-collision relies on. It is a heuristic, not a proof of exploitation.

Splunk SPL Query

index=suricata sourcetype=suricata:flow OR sourcetype=suricata:eve
| eval fam=if(match(src_ip,":"), "ipv6", "ipv4")
| stats dc(fam) as families values(src_ip) as srcs values(dest_ip) as dsts by dest_port, proto, vlan, flow_id
| where families > 1
| table _time, flow_id, srcs, dsts, dest_port, proto, vlan, families
| sort - _time

Note: This query hunts for flow records that associate multiple address families with the same ports/protocol/VLAN — the observable precondition and a potential artifact of flow state confusion in CVE-2026-71855. Adapt field names to your Suricata EVE/flow schema.

Wazuh OSSEC Rule

<group name="suricata,cve-2026-71855,">
  <rule id="100718" level="6">
    <decoded_as>json</decoded_as>
    <field name="event_type">^flow$</field>
    <match>flowbit</match>
    <description>CVE-2026-71855: Suricata flowbit anomaly - possible IPv4/IPv6 flow state confusion</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_71855,defense_evasion,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED (no patch evidence from any tracked source). Note the discrepancy: the NVD description states the issue is fixed in 8.0.6 and 7.0.17, but no patch source, vendor advisory entry, or OSV package record is present in the supplied intelligence and no workarounds are documented. Treat patching as version-driven rather than advisory-driven.

1. Immediate mitigations (no patch evidence required):

   • Inventory and version-audit all Suricata deployments. Any instance below 7.0.17 or in 8.0.0–8.0.5 is potentially vulnerable. Capture suricata --build-info / version strings in your CMDB.
   • Segment IPv4 and IPv6 inspection onto separate sensor interfaces/VLANs where operationally feasible, reducing the dual-stack coexistence that the key-collision requires. This is a compensating control, not a fix.
   • Layer defense. Do not rely on a single Suricata sensor as a sole detection layer. Add host-based detection (EDR), flow analytics from independent sources (Zeek, NetFlow/IPFIX with independent flow keys), and endpoint/network correlation to detect bypassed activity.
   • Increase cross-sensor corroboration: require alerts from independent detection paths before trusting a "clean" verdict for high-value segments.
   • Restrict dual-stack where unused: if IPv6 is not required on a monitored segment, disable it, removing the attacker's ability to force a cross-family collision.

2. Patch / upgrade steps:

   • Upgrade to Suricata 8.0.6 (8.x line) or 7.0.17 (7.x line) as stated in the NVD description.
   • Verify post-upgrade that src/flow-hash.c comparison paths include IP-family discrimination (validate via regression/lab testing in a dual-stack testbed).
   • Re-run your rule/signature regression suite, specifically flowbit-dependent signatures, to confirm restored detection behavior.
   • Because Patch Confidence is 0/4, independently verify the official Suricata release notes and advisories before declaring closure; do not assume the fix's scope from this report alone.

3. Long-term hardening:

   • Adopt dual-stack-aware flow key integrity testing in CI: validate that flow hash/comparison keys always include address family, protocol, ports, and zone/VLAN as discriminating dimensions.
   • Implement continuous flow-state consistency monitoring: periodically inject canary flows of both families and confirm the sensor distinguishes them.
   • Maintain a bidirectional detection validation program (red-team traffic that must be detected) to surface detection bypasses like CWE-697 comparison defects before adversaries do.
   • Track Suricata releases and subscribe to the upstream advisory channel; ingest CVE feeds into sensor asset management so version drift is caught automatically.

References

1. NVD — CVE-2026-71855: https://nvd.nist.gov/vuln/detail/CVE-2026-71855
2. MITRE CWE-697 — Incorrect Comparison: https://cwe.mitre.org/data/definitions/697.html
3. Suricata project releases and documentation (verify 8.0.6 / 7.0.17 fix notes here): https://suricata.io/ and https://github.com/OISF/suricata/releases
4. OISF (Open Information Security Foundation) advisories: https://suricata.io/support/security-advisories/ (consult for the authoritative fix advisory)
5. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-71855 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Exploit-in-the-wild and threat actor evidence: None provided. No public PoC, no Nuclei template, no exploit code, no EPSS score, and no CISA KEV entry were present in the supplied intelligence. Any claim of active exploitation at this time would be unsupported and is therefore not made.