CVE-2026-94083: Suricata DoH2 Use-After-Free Vulnerability

CVE-2026-94083 Overview

CVE-2026-94083 is a type confusion vulnerability [CWE-843] in the Suricata network intrusion detection and prevention system (IDS/IPS) affecting versions prior to 8.0.7. The flaw resides in the DNS-over-HTTPS/2 (DoH2) application-layer parser. When a connection performs an HTTP1 to HTTP2 upgrade carrying a DoH2 request, cleanup code for the HTTP2 state executes while the actual underlying state remains HTTP1. This mismatch causes an invalid free operation. The condition requires app-layer.protocols.doh2 to be enabled, which is the default configuration in 8.x releases.

Critical Impact
A remote attacker can trigger an invalid free in the Suricata process by sending a crafted HTTP1-to-HTTP2 upgrade carrying a DoH2 request, potentially crashing the sensor and disabling network monitoring.

Affected Products

Suricata 8.0.0 through 8.0.6
Suricata deployments with app-layer.protocols.doh2 enabled (default in 8.x)
Any IDS/IPS pipeline built on affected Suricata builds

Discovery Timeline

2026-09-20 - CVE-2026-94083 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-94083

Vulnerability Analysis

Suricata inspects DoH2 traffic by tracking application-layer protocol state transitions per flow. A single packet can drive a flow through multiple protocol changes: HTTP1, then HTTP2 via the Upgrade mechanism, then DoH2 once the DNS payload is detected. The parser assumed a single protocol transition per flow. When two transitions occur back-to-back in one packet, the flow's alproto_orig field is overwritten before the previous protocol's state is freed. Cleanup routines then dispatch based on the new protocol tag (HTTP2) while operating on memory that still belongs to the HTTP1 state, resulting in a type-confusion-driven invalid free.

Root Cause

The defect lives in SCAppLayerForceProtocolChange within src/app-layer-detect-proto.c. The original code unconditionally set f->alproto_orig = f->alproto on every protocol change. If a prior change was already in flight (FlowChangeProto(f) still true), the original protocol identity was lost, so later cleanup code freed HTTP1-backed state as if it were HTTP2.

Attack Vector

Exploitation requires only that Suricata observe a single crafted TCP flow containing an HTTP1 request with an Upgrade: h2c header immediately followed by a DoH2 (application/dns-message) request over HTTP2. No authentication or user interaction is needed because Suricata is a passive network sensor. Any adversary able to send traffic across a monitored segment can reach the vulnerable code path.

// Patch from src/app-layer-detect-proto.c
 void SCAppLayerForceProtocolChange(Flow *f, AppProto new_proto)
 {
     if (new_proto != f->alproto) {
-        f->alproto_orig = f->alproto;
+        if (!FlowChangeProto(f)) {
+            // may happen when changing protocol from http1 to http2, then doh2
+            // We need to keep the original alproto, as HTTP1 state was not freed yet
+            f->alproto_orig = f->alproto;
+        } else if (f->alproto == f->alproto_expect) {
+            // First change went as expected
+            f->alproto_expect = new_proto;
+        }
         f->alproto = new_proto;
         f->alproto_ts = f->alproto;
         f->alproto_tc = f->alproto;

Source: Suricata Commit e574009

Detection Methods for CVE-2026-94083

Indicators of Compromise

Unexpected Suricata process crashes or restarts on sensors running 8.0.x builds
Core dumps referencing AppLayerParserStateCleanup, HTTP2StateFree, or the doh2 parser
Gaps in EVE JSON output correlating with HTTP1-to-HTTP2 upgrade traffic on inspected links

Detection Strategies

Inspect packet captures for HTTP1 requests carrying Upgrade: h2c headers followed by HTTP2 frames with application/dns-message content on the same flow
Alert on Suricata engine crashes surfaced through process supervisors (systemd, monit) or SNMP watchdogs
Correlate sensor downtime windows with matching upgrade traffic seen on adjacent taps or mirror ports

Monitoring Recommendations

Forward Suricata stats and process telemetry into a centralized data lake for anomaly baselining
Track app_layer.error.doh2 and app_layer.error.http2 counters in Suricata stats output for spikes
Watch for repeated short-lived flows containing both h2c upgrades and DNS-over-HTTPS payloads from the same source

How to Mitigate CVE-2026-94083

Immediate Actions Required

Upgrade all Suricata deployments to version 8.0.7 or later without delay
Inventory sensors to identify any 8.0.0 through 8.0.6 instances exposed to untrusted traffic
Restart Suricata after upgrading to ensure the patched parser is loaded on every worker thread

Patch Information

The fix ships in Suricata 8.0.7, released by the Open Information Security Foundation (OISF). The corrective commit is e574009, which preserves the original alproto when a second protocol change occurs before the first cleanup completes. Release notes are available in the Suricata 8.0.7 Release Announcement and the full diff is published as the Suricata Version Comparison 8.0.6 to 8.0.7.

Workarounds

Disable the DoH2 parser in suricata.yaml by setting app-layer.protocols.doh2.enabled: no until patching is complete
Restrict monitored segments so Suricata does not inspect flows from untrusted sources during the remediation window
Deploy sensor process supervision to auto-restart Suricata if it aborts, preserving monitoring coverage

bash

# suricata.yaml - temporarily disable DoH2 parser
app-layer:
  protocols:
    doh2:
      enabled: no

# Validate configuration and reload
suricata -T -c /etc/suricata/suricata.yaml
systemctl restart suricata