CVE-2025-64330: Oisf Suricata Buffer Overflow Vulnerability

CVE-2025-64330 Overview

CVE-2025-64330 is a heap overflow vulnerability affecting Suricata, the network IDS, IPS, and NSM engine developed by the Open Information Security Foundation (OISF) and the Suricata community. The vulnerability exists in the verdict logging functionality within eve.alert and eve.drop records, where a single byte read heap overflow can occur under specific conditions.

The vulnerability is triggered when the per-packet alert queue is filled with alerts and subsequently followed by a pass rule. This condition causes an out-of-bounds memory read that can lead to application crashes, resulting in denial of service for network monitoring and intrusion detection capabilities.

Critical Impact

This heap overflow vulnerability can cause Suricata to crash, potentially leaving networks unprotected during the downtime. Organizations relying on Suricata for intrusion detection and prevention may experience security blind spots until the service is restored.

Affected Products

• OISF Suricata versions prior to 7.0.13
• OISF Suricata versions prior to 8.0.2

Discovery Timeline

• 2025-11-26 - CVE-2025-64330 published to NVD
• 2025-12-05 - Last updated in NVD database

Technical Details for CVE-2025-64330

Vulnerability Analysis

This vulnerability is classified under CWE-122 (Heap-based Buffer Overflow) and CWE-787 (Out-of-bounds Write). The flaw exists in the alert output processing code within Suricata's JSON alert logging functionality. When logging verdict information for network packets, the code incorrectly accesses the alert array using an index that can exceed the valid bounds of the array.

The vulnerable code path is triggered when the packet alert queue reaches its maximum capacity and a pass rule is subsequently evaluated. Under these conditions, the code attempts to access p->alerts.alerts[p->alerts.cnt] without proper bounds checking, resulting in a heap buffer over-read of one byte. While this is a read overflow rather than a write overflow, it can still cause memory access violations leading to process termination.

Root Cause

The root cause of this vulnerability lies in improper array index validation in the output-json-alert.c file. The original code accessed the alert array using p->alerts.cnt as an index without verifying that this index falls within the allocated bounds of the alert array. When the alert count equals the maximum allowed alerts (packet_alert_max), accessing the array at index cnt reads beyond the allocated memory region.

Attack Vector

This vulnerability is exploitable over the network by sending crafted network traffic designed to trigger multiple alerts, filling the per-packet alert queue. An attacker would need to:

1. Generate network traffic that triggers numerous alerts, filling the alert queue to its maximum capacity
2. Include traffic that matches a pass rule after the queue is filled
3. Have verdict logging enabled in the Suricata configuration

The attack does not require authentication or user interaction, making it exploitable by any network attacker who can send traffic through a Suricata-monitored network segment.

// Security patch in src/output-json-alert.c
// Source: https://github.com/OISF/suricata/commit/482e5eac9218d007adbe2410d6c00173368ce947
         JB_SET_STRING(jb, "action", "drop");
     } else if (PacketCheckAction(p, ACTION_ACCEPT)) {
         JB_SET_STRING(jb, "action", "accept");
-    } else if (p->alerts.alerts[p->alerts.cnt].action & ACTION_PASS) {
+    } else if (p->alerts.cnt == 0 ||
+               (p->alerts.cnt <= packet_alert_max &&
+                       (p->alerts.alerts[p->alerts.cnt - 1].action &
+                               (ACTION_PASS | ACTION_ALERT)) == (ACTION_PASS | ACTION_ALERT)) ||
+               (p->alerts.cnt < packet_alert_max &&
+                       p->alerts.alerts[p->alerts.cnt].action & ACTION_PASS)) {
         JB_SET_STRING(jb, "action", "pass");
     } else {
         // TODO make sure we don't have a situation where this wouldn't work

The patch adds proper bounds checking by verifying that p->alerts.cnt is within valid array bounds before accessing the alert array. It also adjusts the index to use cnt - 1 when appropriate to prevent the off-by-one access.

Detection Methods for CVE-2025-64330

Indicators of Compromise

• Unexpected Suricata process crashes or restarts in system logs
• Segmentation fault errors in Suricata logs related to alert processing
• Gaps in network monitoring data during periods of high alert volume
• Core dump files indicating memory access violations in output-json-alert.c

Detection Strategies

• Monitor Suricata process stability and configure automatic restart alerts
• Review system logs for segmentation faults or memory-related errors in Suricata
• Implement process monitoring to detect unexpected Suricata terminations
• Analyze traffic patterns for unusual alert volumes that could indicate exploitation attempts

Monitoring Recommendations

• Configure process supervision to automatically restart Suricata and alert administrators
• Monitor the packet-alert-max threshold and alert when approaching capacity
• Implement redundant IDS/IPS sensors to maintain coverage during potential crashes
• Enable core dump collection for post-incident analysis

How to Mitigate CVE-2025-64330

Immediate Actions Required

• Upgrade Suricata to version 7.0.13 or 8.0.2 immediately
• Increase the packet-alert-max configuration value as a temporary workaround
• Review Suricata configuration to assess if verdict logging is enabled
• Ensure process supervision is configured to restart Suricata if it crashes

Patch Information

OISF has released patched versions to address this vulnerability. Organizations should update to Suricata version 7.0.13 for the 7.x branch or version 8.0.2 for the 8.x branch. The security fix is tracked in GitHub commit 482e5eac9218d007adbe2410d6c00173368ce947. Additional details are available in the GitHub Security Advisory GHSA-83v7-gm34-f437.

Workarounds

• Increase the packet-alert-max setting in suricata.yaml to reduce the likelihood of triggering the vulnerability
• Disable verdict logging in eve.alert and eve.drop outputs if not required
• Implement network segmentation to limit the attack surface
• Deploy redundant IDS/IPS instances to maintain visibility during potential crashes

# Configuration example - suricata.yaml
# Increase packet-alert-max to reduce vulnerability exposure
vars:
  # Increase the maximum number of alerts per packet
  # Default is typically 64, consider increasing based on your environment
  packet-alert-max: 256