CVE-2026-55841: Log Evasion and Tampering in Graylog FortiGate Syslog Parser

Graylog Server and Graylog Forwarder utilize specialized syslog codecs to ingest and parse log messages from a wide array of network security infrastructure. Among these, the FortiGate syslog parser is responsible for decoding key-value formatted diagnostic and audit data emitted by FortiGate enterprise firewalls. The integrity of this ingestion process is vital to downstream security operations, including automated threat detection, incident response workflows, and compliance-driven log retention.

A serious security vulnerability, tracked as CVE-2026-55841 (and GHSA-gqr6-r77p-c2pj), exists within Graylog's FortiGate parser components, specifically GLFortiGateSyslogEvent.java and SyslogCodec.java. The vulnerability is classified under CWE-138 (Improper Neutralization of Special Elements). It occurs because the ingestion parser mishandles field-like text nested within quoted values, enabling unauthenticated remote senders to systematically strip or corrupt critical log fields.

The attack surface is exposed through any active TCP or UDP syslog input configured with the FortiGate codec. Since syslog listeners typically operate without transport-layer authentication, any remote attacker who can transmit network traffic to the logging port, or route traffic containing crafted URL parameters through a monitored firewall, can trigger the vulnerability. The resultant parser misbehavior can render security alerts non-functional and blind security teams to ongoing attacks.

The technical root cause of CVE-2026-55841 consists of two distinct parsing vulnerabilities involving naive regular expression post-processing and improper boundary tokenization. To understand the implementation flaw, it is necessary to examine how Graylog handled equals signs (=) nested inside legitimate field values, such as HTTP query parameters. Because the underlying third-party parser, syslog4j (v0.9.61), would erroneously parse parameters inside url="/index.php?param=value" as standalone top-level fields, Graylog developers implemented a custom cleanup routine in GLFortiGateSyslogEvent.getFields().

This cleanup filter scanned all parsed field values using two static regular expressions: KV_PATTERN (compiled as (\w+)=([^\s\"]*)) and QUOTED_KV_PATTERN (compiled as (\w+)=\"([^\"]*)\"). If a field value contained an equals sign, the parser collected the key names of any nested parameters into a temporary set called removalKeys. After iterating over all fields, the method invoked removalKeys.forEach(fields::remove). Because this removal process is global and context-insensitive, if the cleanup routine matched any key-value structure within a URL or message string, it deleted the corresponding authentic top-level fields of that name from the entire log entry.

Simultaneously, the second flaw lies in the syslog4j (v0.9.61) tokenizer itself, which failed to correctly handle backslash-escaped quotes (\") within quoted field values. When the tokenizer encountered an escaped quote inside a string, it treated the escape sequence as the terminal boundary of the current field. This allowed any trailing substring inside the quotes to spill out and be parsed as new, standalone top-level fields. Consequently, an attacker could force the parser to overwrite existing security fields (such as srcip) with malicious payloads.

The flawed processing logic in GLFortiGateSyslogEvent.getFields() illustrates how the global removal mechanism was constructed. The custom wrapper class iterated over the parsed fields and matched nested key structures inside legitimate values, as shown in the vulnerable code path:

// VULNERABLE COMPONENT: GLFortiGateSyslogEvent.java
@Override
public Map<String, String> getFields() {
    Map<String, String> fields = new HashMap<>(super.getFields());
    Set<String> removalKeys = new HashSet<>();
    for (Map.Entry<String, String> entry : fields.entrySet()) {
        String value = entry.getValue();
        if (value != null && value.contains("=")) {
            Matcher matcher = KV_PATTERN.matcher(value);
            while (matcher.find()) {
                removalKeys.add(matcher.group(1)); // Erroneously collects the key name
            } 
            matcher = QUOTED_KV_PATTERN.matcher(value);
            while (matcher.find()) {
                removalKeys.add(matcher.group(1)); // Erroneously collects quoted key name
            }
        }
    }
    // Global destruction of all collected keys, regardless of origin
    removalKeys.forEach(fields::remove);
    return fields;
}

To resolve this vulnerability, Graylog engineers entirely deleted the custom wrapper class GLFortiGateSyslogEvent.java and upgraded the upstream syslog4j library to version 0.9.63 in the Maven configuration. The updated syslog4j parser implements a state-aware tokenizer capable of natively distinguishing nested values and escaped quotes. The corresponding patch in SyslogCodec.java removes reference to the custom wrapper and instantiates the clean FortiGateSyslogEvent directly:

// PATCHED COMPONENT: SyslogCodec.java
- import org.graylog2.inputs.codecs.GLFortiGateSyslogEvent;
+ import org.graylog2.syslog4j.server.impl.event.FortiGateSyslogEvent;
  ...
  } else if (FORTIGATE_PATTERN.matcher(msg).matches()) {
-     e = new GLFortiGateSyslogEvent(msg.trim(), defaultTimeZone);
+     e = new FortiGateSyslogEvent(msg.trim(), defaultTimeZone);
  }

By migrating tokenization directly to the native, state-based parser in syslog4j v0.9.63, the system no longer executes post-processing key-stripping loops. This ensures that parameters embedded inside quoted fields like URLs are correctly preserved without causing the collateral erasure of primary metadata fields.

An attacker can exploit CVE-2026-55841 through two primary attack vectors. The first is passive exploitation, which requires no direct communication with Graylog. An attacker can target a system situated behind a monitored FortiGate firewall and execute a network transaction—such as a crafted HTTP GET request—containing parameters named after critical log metadata fields. The firewall generates a syslog event containing the malicious string, which triggers the global cleanup vulnerability upon reaching Graylog, deleting the attacker's source IP address from the security index.

The second vector is active exploitation, where an attacker sends a spoofed UDP or TCP syslog packet directly to the Graylog input port. This method allows the attacker to manipulate the parsing topology of any ingested log fields. For instance, sending a message containing backslash-escaped quotes terminates the parsing string prematurely, causing the remaining string to overwrite adjacent fields.

The conceptual logic of this parsing exploitation is outlined below:

Because the cleanup parser does not validate whether the source of a deletion key is a nested URL query parameter or a primary syslog key, sending any text value containing srcip= or date= leads to the immediate destruction of those keys. No specialized exploitation frameworks are required to trigger this state; a simple netcat utility transmitting the payload over UDP is sufficient to bypass detection.

The impact of CVE-2026-55841 is characterized by a complete compromise of log integrity and audit reliability. By systematically stripping critical identifiers such as source IP addresses (srcip), destination IP addresses (dstip), and admin action states, an attacker can blind correlation engines, intrusion detection systems, and SIEM dashboards to active threats. Automated alerts built to flag brute-force attempts, data exfiltration, or unauthorized API access will fail to fire if the identifying fields are eliminated prior to indexing.

Furthermore, by targeting structural metadata fields such as date, time, and tz (timezone), attackers can cause Graylog to ingest records without temporal context. Because Elasticsearch and OpenSearch databases require precise timestamps to organize data indexes, log records lacking valid temporal metadata are either rejected outright as malformed or cataloged under arbitrary, incorrect dates. This provides attackers with a reliable mechanism to execute targeted log denial-of-service, rendering search queries during forensic investigations completely ineffective.

The vulnerability is assigned a CVSS v3.1 base score of 7.5, reflecting its low attack complexity, lack of privilege requirements, and severe integrity impact. While it does not allow direct remote code execution on the underlying server, its utility as an evasion mechanism for sophisticated actors makes it a high-risk security issue.

Remediation of CVE-2026-55841 requires upgrading the affected Graylog deployments to the latest patched releases. Graylog Server installations must be upgraded to version 6.3.12, 7.0.7, or 7.1.2 or higher. Graylog Forwarder installations must be upgraded to version 7.3 or higher. These updates replace the custom post-processing filter with the secure, state-aware syslog4j v0.9.63 library.

If immediate software upgrades are not feasible, organizations should implement the following defensive workarounds:

1. Network-Level Access Control Lists (ACLs): Restrict access to UDP and TCP syslog listener ports (typically port 514) using strict firewall rules. Ensure that only designated, trusted FortiGate devices or centralized syslog collectors can transmit traffic to the Graylog input ports.

2. Alternative Pipeline Parsing: Temporarily disable the native FortiGate syslog input codec. Configure a raw syslog input receiver and develop manual extraction logic using secure Graylog Pipelines. The custom pipeline regexes must use strict extraction patterns and avoid global recursive deletion operations.