CVE-2026-109786 in fail2ban
Summary
by MITRE • 10/13/2026
In fail2ban 0.10.5 through 1.1.1 before ddd879d, the sshd filter (config/filter.d/sshd.conf) accepts an "on <token>" suffix after the host address. Because OpenSSH logs the offered username verbatim, a remote unauthenticated attacker can use a username such as "x VICTIM-SOURCE-IP-ADDRESS on" to make fail2ban associate failed login attempts with an arbitrary source IP address and ban it (e.g., to block logins from a legitimate user). The default filter mode is affected.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability in Fail2Ban versions 0.10.5 through 1.1.1, prior to commit ddd879d, represents a critical flaw in the input validation logic of the sshd jail configuration file located at config/filter.d/sshd.conf. This issue stems from an insufficient sanitization mechanism when parsing log entries generated by OpenSSH. Specifically, the regular expression used to extract source IP addresses from SSH authentication failure logs incorrectly permits an "on <token>" suffix following the host address field. While this syntax is not standard in typical SSH client behavior, it exploits a discrepancy between how Fail2Ban parses log lines and how OpenSSH records them. Because OpenSSH logs the username provided by the connecting client verbatim without stripping or escaping special characters that might appear within the authentication payload, an attacker can manipulate the structure of the logged data to inject arbitrary values into fields intended for IP address extraction.
From a technical perspective, this flaw allows for log injection and subsequent rule manipulation. When a remote unauthenticated attacker initiates an SSH connection with a specially crafted username string such as "x VICTIM-SOURCE-IP-ADDRESS on", Fail2Ban processes the resulting log entry using its default filter mode. The parsing logic mistakenly identifies the injected IP address within the username field as the source of the failed login attempt rather than recognizing it as part of the authentication credential. Consequently, Fail2ban associates the subsequent ban action with this fabricated source IP address instead of the actual attacker's IP. This misalignment between the perceived and actual origin of the attack vector enables an adversary to bypass their own rate limiting while simultaneously targeting unrelated systems or users.
The operational impact of this vulnerability is significant for network security posture, particularly regarding availability and integrity of access control mechanisms. By leveraging this flaw, a malicious actor can execute a denial-of-service attack against legitimate users by causing Fail2Ban to ban the IP addresses associated with those users. This results in the unintended blocking of valid administrative or user connections, effectively locking out authorized personnel from critical infrastructure. Furthermore, this behavior undermines the reliability of intrusion prevention systems that rely on accurate source attribution for threat intelligence and forensic analysis. The ability to arbitrarily assign blame to specific IPs disrupts audit trails and complicates incident response efforts, as security teams may investigate innocent parties while the actual attacker remains unblocked due to their own IP not being flagged by the manipulated logs.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command (Log Injection variant) and falls under MITRE ATT&CK technique T1036, which covers Masquerading or Obfuscation techniques where attackers manipulate system outputs to evade detection. To mitigate this risk, organizations running affected versions must upgrade Fail2Ban to a version released after commit ddd879d, which addresses the parsing logic in the sshd filter. Additionally, administrators should review their jail configurations for any custom filters that might exhibit similar lax validation patterns. Implementing strict input validation on log parsers and ensuring that only expected formats are accepted can prevent such injection attacks. Regular auditing of ban logs against actual connection records is also recommended to detect anomalies indicative of this exploitation attempt in environments where upgrading may not be immediately feasible.