# fail2ban security advisories and hardening > fail2ban vulnerabilities and CVEs: CVE-2026-109786, the GHSA-33wh-ccjc-p397 ReDoS, CVE-2021-32749, the action.d privilege escalation and how to check your server. > > Source: https://fail2ban.dev/security/ · Updated 2026-10-25 · Checked against fail2ban 1.1.1 > fail2ban.dev is an independent guide, not the official fail2ban project. 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 | ID | Component | Impact | Affected | Fixed in | |---|---|---|---|---| | CVE-2026-109786 | `sshd` filter | Attacker can get an arbitrary IP banned | 0.10.5 – 1.1.1 | Upstream commit `ddd879d` (no release yet) | | GHSA-33wh-ccjc-p397 | `domino-smtp`, `dovecot` filters | Regex denial of service (detection blocked) | 1.1.1 development versions | 1.1.1 | | CVE-2021-32749 | `mail-whois` action with mailutils | Remote code execution via crafted whois reply | ≤ 0.9.7, ≤ 0.10.6, ≤ 0.11.2 | 0.10.7, 0.11.3, 1.0.1 | | CVE-2013-7177 | `cyrus-imap` filter | Attacker can get an arbitrary IP banned | before 0.8.11 | 0.8.11 | | CVE-2013-7176 | `postfix` filter | Attacker can get an arbitrary IP banned | before 0.8.11 | 0.8.11 | | CVE-2013-2178 | `apache-*` filters | Attacker can get an arbitrary IP banned | before 0.8.10 | 0.8.10 | | CVE-2012-5642 | `` tag in actions | Unsafe handling of log content in custom actions | before 0.8.8 | 0.8.8 | | CVE-2009-5023 | `dshield`, `mail-buffered`, `mynetwatchman` actions | Local file overwrite via predictable temp files | before 0.8.5 | 0.8.5 | | CVE-2009-0362 | `wuftpd` filter | Crafted reverse DNS name causes bans | 0.8.3 | Distribution patches | | CVE-2007-4321 | `sshd` filter | Remote attacker can add arbitrary hosts to `hosts.deny` | 0.8 and earlier | 0.8.1 | | CVE-2006-6302 | `sshd` filter | Same class, via crafted user name | 0.7.4 and earlier | Later 0.7.x releases | 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 ` suffix after the host address, so a username crafted to look like `… from 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](https://github.com/fail2ban/fail2ban/commit/ddd879d22664904ace24e1255ac6571808c58187) removes the `on \S+` alternative. Until your package is updated, apply the same change as a local override, which survives upgrades: ```ini [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 ``` ## 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](/troubleshooting/high-cpu/). ## 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](/config/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 action actionban `), 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 ```bash 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 ``` ### Fix permissions ```bash sudo chmod -R go-w /etc/fail2ban ``` ## Harden your fail2ban setup 1. **Stay current.** Use a supported distribution release and apply updates; check your version against the table above. See [fail2ban versions](/versions/). 2. **Whitelist what must never be banned.** Your admin IPs, monitoring and load balancers belong in `ignoreip`, which also blunts every "ban someone else" bug. 3. **Set `usedns = no`** in `[DEFAULT]` when your services log IP addresses. Resolving hostnames from logs can ban the wrong IP. 4. **Keep custom actions safe.** fail2ban escapes `` and F-tags before substituting them, but don't pass log content to another interpreter (mail clients, `eval`, `sh -c`) in your own actions. 5. **Lock down the config.** Root-owned `/etc/fail2ban`, no group write, no sudo access to `fail2ban-client` for untrusted users. 6. **Test filters before trusting them.** Run custom regexes through [fail2ban-regex](/fail2ban-regex/); anchor them and avoid `.*` before ``, the pattern behind most injection CVEs. 7. **Don't rely on fail2ban alone.** Use SSH keys, disable password logins where you can, and keep a firewall default-deny. More in [best practices](/best-practices/). 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.