CVE-2026-45767 in Suricata
Summary
by MITRE • 09/10/2026
Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to versions 7.0.16 and 8.0.5, a malicious rule could potentially overwrite any file on the file system on rule load or reload. Versions 7.0.16 and 8.0.5 fix the issue. Some workarounds are available. Preprocess `load`+ `save` rules to disallow absolute filenames for save, use Suricata's privilege dropping to limit writable files, and/or configure landlock in suricata.yaml.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
Suricata is a widely deployed open-source network intrusion detection system, intrusion prevention system, and network security monitoring engine that processes traffic against user-defined rules to identify malicious activity. A critical vulnerability existed within the rule loading mechanism prior to versions 7.0.16 and 8.0.5, where a specifically crafted or maliciously intended rule could trigger an arbitrary file write operation on the host operating system during rule load or reload operations. This flaw stems from insufficient validation of file paths specified in save actions associated with detection rules, allowing attackers to specify absolute filenames that bypass expected directory restrictions and target sensitive locations within the filesystem.
The technical nature of this vulnerability aligns closely with CWE-732, which describes improper permission assignment for critical resources, as well as CWE-94, specifically the code injection variant where user-controlled input leads to unintended execution or modification of system files. In a typical deployment, Suricata operates under specific privileges and often drops root capabilities after initialization to adhere to the principle of least privilege. However, during the rule loading phase, if the application does not strictly sanitize absolute path inputs provided in save directives within rules, it may write data to arbitrary locations before full privilege dropping takes effect or by exploiting race conditions in permission checks. This allows an attacker with access to modify Suricata configuration files or inject malicious rules through a compromised management interface to overwrite system binaries, configuration files, or other critical assets on the host machine.
The operational impact of this vulnerability is severe, as it effectively grants remote code execution capabilities depending on what file is overwritten and under which user context Suricata was running at the time of rule loading. An attacker could replace legitimate executables with malicious versions to establish persistence, modify configuration files such as suricata.yaml to disable security controls or redirect logs for evasion purposes, or overwrite sensitive data leading to information disclosure. This capability undermines the integrity of the entire network security infrastructure managed by Suricata and can serve as a pivot point for further lateral movement within the internal network. From an ATT&CK perspective, this vulnerability facilitates techniques related to Defense Evasion through file modification and potentially Execution via system binary proxying if critical binaries are replaced.
To mitigate this risk, organizations must immediately upgrade to Suricata version 7.0.16 or 8.0.5 where the issue has been resolved with stricter path validation logic that prevents absolute paths from being used in save actions unless explicitly permitted by secure configuration defaults. For environments unable to patch immediately, several workarounds are recommended to reduce exposure. Administrators should preprocess load and save rules to actively disallow absolute filenames, ensuring only relative paths within designated directories are accepted. Additionally, enforcing strict privilege dropping mechanisms ensures that even if a rule attempts an unauthorized write, the process lacks the necessary permissions to affect critical system files. Configuring landlock security modules in suricata.yaml provides another layer of defense by restricting file system access at the kernel level based on defined rulesets, thereby containing potential damage from any remaining exploitable paths. Regular auditing of rule sets and monitoring for unexpected file modifications are also essential components of a comprehensive defense strategy against such configuration-based attacks.