CVE-2026-31935
Memory Exhaustion via HTTP2 Frame Flooding in Suricata
Publication date: 2026-04-02
Last updated on: 2026-04-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| oisf | suricata | to 7.0.15 (exc) |
| oisf | suricata | From 8.0.0 (inc) to 8.0.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-31935 is a high-severity vulnerability affecting Suricata versions prior to 8.0.4 and 7.0.15. It involves an attacker flooding the system with crafted HTTP/2 continuation frames, which causes unbounded resource consumption leading to memory exhaustion.
This memory exhaustion typically results in the Suricata process being terminated by the operating system. The root cause is improper control over resource allocation and maintenance, classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling).
The attack is network-based, requires no privileges or user interaction, and affects the availability of the Suricata service without impacting confidentiality or integrity.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Suricata (CVE-2026-31935) leads to memory exhaustion and process termination, impacting availability but not confidentiality or integrity of data.
Since the issue affects availability only and does not result in data leakage or unauthorized data modification, it does not directly compromise compliance with data protection regulations such as GDPR or HIPAA, which primarily focus on confidentiality and integrity of personal and sensitive data.
However, availability is a component of overall security and operational resilience, which can indirectly affect compliance if critical security monitoring is disrupted.
How can this vulnerability impact me? :
This vulnerability impacts the availability of the Suricata network IDS/IPS/NSM engine by causing memory exhaustion through flooding with crafted HTTP/2 continuation frames.
As a result, the Suricata process is typically shut down by the operating system, leading to a denial of service condition where network monitoring and intrusion detection capabilities are lost.
There is no impact on confidentiality or integrity, but the loss of availability can disrupt security monitoring and response.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves flooding Suricata with crafted HTTP/2 continuation frames causing memory exhaustion and process termination. Detection can focus on monitoring Suricata process stability and resource usage.
You can check if Suricata is crashing or being killed by the operating system due to memory exhaustion by reviewing system logs and Suricata logs.
Commands to help detect this include:
- Check Suricata process status and recent restarts: `systemctl status suricata` or `ps aux | grep suricata`
- Review system logs for out-of-memory (OOM) killer events: `dmesg | grep -i 'killed process'` or `journalctl -xe | grep suricata`
- Monitor Suricata memory usage over time: `top -p $(pidof suricata)` or `ps -o pid,rss,cmd -p $(pidof suricata)`
- Analyze network traffic for abnormal HTTP/2 continuation frame floods using Suricata logs or network capture tools like `tcpdump` or `wireshark` focusing on HTTP/2 frames.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade Suricata to version 7.0.15 or 8.0.4 or later, where this vulnerability has been patched.
If upgrading immediately is not possible, alternative mitigations include:
- Configure the `stream.reassembly.depth` parameter to a positive value to limit resource consumption during HTTP/2 stream reassembly. Setting it to 0 or leaving it unset means unlimited, which is vulnerable.
- Disable the HTTP/2 parser entirely to prevent processing of HTTP/2 continuation frames.