CVE-2026-94083: Suricata DoH2 Type Confusion

How to Detect It

Detection should combine asset inventory, configuration review, process monitoring, and traffic telemetry. A vulnerable version alone does not prove exploitation, while a crash alone does not prove this CVE was the cause. Correlate Suricata restarts with HTTP/2 or DoH-related traffic and preserve the relevant logs for incident analysis.

Look for unexpected process termination, repeated service restarts, or allocator errors on sensors processing HTTP upgrade traffic. Common operating-system messages may include segmentation fault, invalid free, double free, SIGABRT, or service-manager restart messages. These strings are indicators, not a CVE-specific signature.

Technical Notes

A basic Linux search for process instability can be used as an initial triage query:

journalctl --since "24 hours ago" -u suricata \
  | grep -Ei 'suricata|invalid free|double free|segmentation fault|SIGABRT|crash|restart'

For systems using systemd, identify repeated restarts and the termination reason:

systemctl status suricata
systemctl show suricata \
  -p ExecMainStatus -p ExecMainCode -p NRestarts -p ActiveEnterTimestamp

Search Suricata’s event and protocol logs for HTTP/2 or DoH-related activity around a crash window. Field names vary by output configuration, so start with a broad search:

grep -RniE 'doh2|http2|HTTP/2|upgrade' \
  /var/log/suricata /var/log 2>/dev/null | tail -200

A SIEM query should correlate a Suricata service restart with HTTP upgrade or DoH-related events within a short time window. For example, a generic Sigma-like analytic can be expressed as:

(EventSource = "systemd" AND Service = "suricata"
 AND Message matches /(failed|stopped|started|restart|SIGABRT|segmentation fault|invalid free)/)
AND
(related_event.Message matches /(doh2|http2|HTTP\/2|Upgrade)/)
WITHIN 5m

This is a triage analytic, not a network signature. The available information does not provide a reliable byte-level IDS rule for triggering the vulnerability, and defenders should not deploy an invented signature as if it were validated detection logic.

Mitigation and Patching

Upgrade Suricata to 8.0.7 or later. The Suricata project describes 8.0.7 as a security release, and the upstream comparison identifies the corrective changes between 8.0.6 and 8.0.7. After upgrading, verify the running binary rather than assuming that a package transaction updated the executable used by the sensor.

If an immediate upgrade is not possible, assess whether disabling DoH2 processing is operationally acceptable for the affected sensor. This can reduce exposure to the described execution path, but it may also reduce visibility into DoH2 traffic. Apply the setting using the configuration schema and packaging conventions of the installed release, validate the configuration, and restart Suricata under change control.

For endpoint systems connected to monitored networks, a separate endpoint-security product such as Malwarebytes may complement network monitoring, but it does not remediate this Suricata vulnerability or replace upgrading the affected sensor.

Technical Notes

For an installation built from upstream source, a representative upgrade sequence is:

cd /usr/local/src/suricata
git fetch --tags https://github.com/OISF/suricata.git
git checkout suricata-8.0.7
./configure
make -j"$(nproc)"
sudo make install
sudo ldconfig
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl restart suricata
suricata --version

Package-managed systems should use the vendor repository that provides 8.0.7 or later, then validate the installed version:

sudo apt update
sudo apt install --only-upgrade suricata
suricata --version
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl restart suricata

The apt command upgrades only if the configured repositories offer a fixed package. Confirm that the reported version is 8.0.7 or later; do not treat a successful package command as proof of remediation.

For temporary mitigation, locate the effective DoH2 configuration and disable it according to the installed Suricata configuration schema. A deployment using the documented dotted setting should verify the resulting value before restart:

grep -nA8 -B3 'doh2' /etc/suricata/suricata.yaml
sudo suricata -T -c /etc/suricata/suricata.yaml
sudo systemctl restart suricata

If the configuration does not expose a clear disable control, do not guess at YAML structure. Consult the package’s shipped configuration or Suricata documentation, and prioritize upgrading instead. Maintain sensor redundancy during the change so that disabling a protocol or restarting a sensor does not create an unmonitored network segment.

Incident Response Considerations

If a vulnerable sensor crashes unexpectedly, preserve system logs, Suricata logs, core dumps, configuration files, package metadata, and relevant network telemetry before restarting or rebuilding the host where practical. Teams should document the sensor’s monitoring coverage and determine whether the interruption created a detection or prevention gap.

Review authentication, administrative, and deployment logs for unauthorized changes, but do not assume that a crash proves compromise. A structured incident response plan can help coordinate evidence collection, containment, failover, and recovery activities.

References

The primary vulnerability record is the NVD entry for CVE-2026-94083. It documents the affected version boundary, the reported DoH2 condition, the invalid-free behavior, and the NVD-assigned 9.4 base score. The reviewed NVD response did not include the CVSS vector, so metric-level claims should be verified against the live record.

The Suricata project’s security release announcement and upstream source changes provide the remediation evidence. The project comparison should be reviewed by teams that need to validate the patch or build Suricata internally.

The supplied assessment identified no verified public PoC, no confirmed in-the-wild exploitation, and no CISA KEV listing. Those statuses can change, so incident response and vulnerability-management teams should recheck the NVD record, Suricata advisories, GitHub activity, and CISA KEV during remediation planning.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.