fail2ban security advisories and hardening

fail2ban has a short, mostly low-severity vulnerability list. The open issue in October 2026 is CVE-2026-109786 (CVSS 5.3): a crafted SSH username can make the sshd filter in versions 0.10.5 through 1.1.1 ban an IP of the attacker's choice. 1.1.1 fixed a regex denial of service (GHSA-33wh-ccjc-p397), and 0.10.7/0.11.3/1.0.1 fixed CVE-2021-32749, a code execution bug in the mail-whois action. The widely shared "fail2ban privilege escalation" isn't a bug in fail2ban: it abuses a misconfigured server where non-root users can write to /etc/fail2ban/action.d.

Known fail2ban vulnerabilities#

Most entries share one pattern: a filter regex loose enough that text an attacker controls — a username, an email address, a hostname — is read as the "attacker IP". The result is a ban against someone else (a denial of service), not a compromise of your server.

CVE-2026-109786: sshd filter ban injection#

What it is. OpenSSH logs the username a client offers without sanitizing it. The sshd filter in fail2ban 0.10.5 through 1.1.1 accepts an optional on <token> suffix after the host address, so a username crafted to look like … from <victim IP> on … makes fail2ban count the failure against the victim's IP. Repeat it maxretry times and the victim is banned. The default filter mode is affected. The CVE was published on 2026-10-13 with CVSS 3.1 score 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

Who is affected. Anyone running the sshd jail on 0.10.5 – 1.1.1, which covers every currently packaged version: Ubuntu 24.04 (1.0.2), Debian 12 (1.0.2), Debian 13 (1.1.0), EPEL (1.1.0) and Debian sid (1.1.1). At the time of writing Debian and SUSE list their packages as affected, and no upstream release contains the fix.

Fix. Upstream commit ddd879d removes the on \S+ alternative. Until your package is updated, apply the same change as a local override, which survives upgrades:

[DEFAULT]
# CVE-2026-109786: only an optional port may follow the host address
__on_port_opt = (?: port \d+)?
__suff = %(__on_port_opt)s(?: \[preauth\])?\s*

sudo fail2ban-regex /var/log/auth.log sshd    # or: systemd-journal sshd
sudo fail2ban-client reload sshd

With the override in place, fail2ban-regex -o ip attributes a Failed password line with an injected username to the real client address instead of the injected one. Also put your own management IPs in ignoreip so an injected ban can never lock you out. The filter itself is described on the sshd filter page.

GHSA-33wh-ccjc-p397: ReDoS in domino-smtp and dovecot filters#

What it is. A failregex in the domino-smtp filter could backtrack catastrophically on a line with an SMTP username full of spaces, making fail2ban spend a very long time on one log line. While it's stuck, the jail detects nothing. The advisory rates it moderate (CVSS 5.3), CWE-1333, with no CVE assigned; the similar pattern in the dovecot filter was judged even less likely to be reachable because that log text isn't normally attacker-controlled.

Who is affected. Only servers with the domino-smtp jail enabled, which is off by default. The advisory lists the 1.1.1 development version as affected; it was fixed in the 1.1.1 release on 2026-08-15.

Fix. Upgrade to 1.1.1, or replace the regex in a filter.d/domino-smtp.local with the fixed one from the 1.1.1 filter. Background on regex performance: high CPU usage.

CVE-2021-32749: mail-whois remote code execution#

What it is. The mail-whois actions pipe the output of whois into the mail command. GNU mailutils' mail interprets lines starting with ~! as shell commands, so an attacker who controls the whois record for their IP range could get commands executed as root when fail2ban sent the alert. Rated high severity.

Who is affected. fail2ban up to 0.9.7, 0.10.6 and 0.11.2 using action_mw/action_mwl (or mail-whois* directly) with GNU mailutils as the mail command.

Fix. Upgrade to 0.10.7, 0.11.3 or 1.0.1+, or use the sendmail-* actions, or switch mail to bsd-mailx. On fixed versions, mailutils is called with -E 'set escape'; if your mailcmd doesn't support that, see email alerts.

Is there a fail2ban 1.1.0 exploit?#

No public exploit targets a bug in 1.1.0 itself. Searches for "fail2ban 1.1.0 exploit" or "fail2ban v1.0.2 CVE" usually lead to one of two things:

• CVE-2026-109786 above, which affects 1.0.2 and 1.1.0 and lets a remote attacker cause bans, not run code;
• privilege-escalation write-ups (common in CTF and training labs) that rely on a misconfigured server, explained next.

The fail2ban privilege escalation scenario#

fail2ban runs as root and executes the shell commands in its action files — actionban, actionstart and so on — whenever a ban happens. That's by design. It becomes a privilege escalation path when someone other than root can change what those commands are:

• /etc/fail2ban/action.d/ (or any config file it reads) is writable by a group such as security or adm, or owned by a normal user;
• a user can create a .local file that fail2ban will read, overriding actionban;
• a user is allowed to run fail2ban-client or systemctl restart fail2ban via sudo. The client can set actionban at runtime (set <jail> action <act> actionban <cmd>), so sudo access to fail2ban-client is equivalent to root.

In each case, the attacker edits a ban command, triggers a ban (by failing logins against their own IP), and fail2ban runs the command as root. A stock package doesn't have this problem: everything under /etc/fail2ban belongs to root and only root can reach the socket.

Audit your server#

# anything under /etc/fail2ban not owned by root, or writable by group/others
sudo find /etc/fail2ban \( ! -user root -o -perm /go+w \) -ls

# who can run fail2ban-client or restart the service via sudo
sudo grep -rn 'fail2ban' /etc/sudoers /etc/sudoers.d/

# the socket should be root-only
sudo ls -l /var/run/fail2ban/fail2ban.sock

The find command should print nothing.

Fix permissions#

sudo chown -R root:root /etc/fail2ban
sudo chmod -R go-w /etc/fail2ban

Remove sudo rules that let non-administrators run fail2ban-client, fail2ban-server or systemctl … fail2ban. If staff need to unban addresses, give them a root-owned wrapper script that accepts only a validated IP and calls fail2ban-client unban, and allow sudo for that script alone.

Harden your fail2ban setup#

Report new vulnerabilities privately through GitHub's security advisory form on the fail2ban repository, not in public issues.

FAQ#

Is fail2ban safe?#

Yes, when installed from your distribution and kept updated. It runs as root, so its configuration must stay root-owned and only administrators should use fail2ban-client. Its known vulnerabilities mostly let attackers trigger bans against other IPs; the one code execution bug, CVE-2021-32749 in mail-whois, was fixed in 2021.

Does fail2ban have any CVEs?#

Yes. The most recent are CVE-2026-109786 (sshd filter ban injection, 0.10.5–1.1.1, fix in upstream commit ddd879d) and CVE-2021-32749 (mail-whois code execution, fixed in 0.10.7, 0.11.3 and 1.0.1). Older ones from 2006–2013 affected filters and actions in 0.8.x and earlier. GHSA-33wh-ccjc-p397, a regex denial of service, has no CVE.

What is the fail2ban privilege escalation?#

It's a misconfiguration, not a fail2ban bug. If a non-root user can write to /etc/fail2ban/action.d or run fail2ban-client with sudo, they can change a ban command and trigger a ban, and fail2ban runs it as root. Keep /etc/fail2ban owned by root without group write and remove such sudo rules.

Is fail2ban 1.0.2 vulnerable?#

fail2ban 1.0.2, shipped by Ubuntu 24.04 and Debian 12, is affected by CVE-2026-109786 in the sshd filter. Apply the filter.d/sshd.local override shown on this page until your distribution patches it. It already contains the fix for CVE-2021-32749.

How do I check if my fail2ban is vulnerable?#

Run fail2ban-client --version and compare it with the table on this page, then check your distribution's security tracker, because packages often carry backported fixes. For CVE-2026-109786, look for on \S+ in the __suff line of /etc/fail2ban/filter.d/sshd.conf; if it's there and no sshd.local override exists, you're affected.