CVE-2025-45311: fail2ban-client Privilege Escalation

CVE-2025-45311 Overview

CVE-2025-45311 describes insecure permissions in fail2ban-client v0.11.2 that allow attackers with limited sudo privileges to perform arbitrary operations as root. The issue is classified under [CWE-266: Incorrect Privilege Assignment]. Multiple parties dispute this CVE because Fail2ban actions for triggered rules can legitimately execute arbitrary operations as root. According to the dispute, the software operates in accordance with its intended privilege model, and the behavior reflects design rather than a defect.

Critical Impact
A user granted limited sudo access to fail2ban-client can leverage Fail2ban's action mechanism to execute arbitrary commands as root, resulting in full local privilege escalation on affected hosts. This finding is disputed by the project maintainers.

Affected Products

Fail2ban fail2ban-client version 0.11.2
Linux distributions packaging the affected release
Hosts where sudo rules grant non-root users access to fail2ban-client

Discovery Timeline

2025-11-26 - CVE-2025-45311 published to the National Vulnerability Database
2025-12-03 - Public discussion of the issue on the Openwall oss-security mailing list
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-45311

Vulnerability Analysis

Fail2ban is a daemon that monitors log files and triggers configurable actions when match patterns indicate abusive behavior. The fail2ban-client utility communicates with the running daemon to manage jails, filters, and actions. When administrators delegate control of fail2ban-client through sudo, they implicitly delegate the ability to define or modify actions.

Actions in Fail2ban are arbitrary shell commands run by the privileged daemon. A user able to invoke fail2ban-client with elevated privileges can therefore add, edit, or trigger actions that execute commands as root. The advisory characterizes this as insecure permissions because the trust boundary between sudo-limited users and the root context collapses through action definitions.

The maintainers contend this is expected behavior. Granting sudo access to fail2ban-client is equivalent to granting root because the client's purpose includes defining root-executed actions.

Root Cause

The root cause is a privilege model mismatch between sudo policy and Fail2ban's action subsystem. sudo rules that allow execution of fail2ban-client without restricting subcommands give the user a path to command execution through legitimate Fail2ban features such as set <jail> banip with custom actions or set <jail> action <act> actionban.

Attack Vector

An attacker requires an existing local account with sudo permission to run fail2ban-client. Using fail2ban-client, the attacker defines a new action containing an arbitrary command, or modifies an existing action, then triggers it through a ban event. The Fail2ban server, running as root, executes the command. No memory corruption, no network exposure beyond the local host, and no authentication bypass is involved. Public proof-of-concept material is referenced in the GitHub PoC Repository and the Packet Storm File Release.

No verified exploit code is reproduced here. See the GitHub Issue on Fail2ban for the maintainers' dispute and technical discussion.

Detection Methods for CVE-2025-45311

Indicators of Compromise

Unexpected entries in /etc/fail2ban/action.d/ or modifications to existing action files outside change windows.
fail2ban-client set <jail> action <name> actionban invocations issued by non-administrator accounts.
Root-owned processes spawned as children of fail2ban-server that do not match defined banning workflows.
sudo audit records showing non-root users executing fail2ban-client with add, set, or reload subcommands.

Detection Strategies

Audit sudoers files and drop-in directories for entries permitting fail2ban-client to non-administrative users.
Enable sudo I/O logging on hosts running Fail2ban and review the command stream for action modifications.
Correlate auditdexecve records for fail2ban-server child processes against expected action definitions.
Track changes to Fail2ban configuration files using file integrity monitoring.

Monitoring Recommendations

Alert on any write to /etc/fail2ban/jail.local, /etc/fail2ban/jail.d/, or /etc/fail2ban/action.d/ by non-root users via sudo.
Flag fail2ban-client invocations containing actionban, actionstart, or actionunban parameter overrides.
Monitor for shells, interpreters, or chmod/chown operations spawned by fail2ban-server.

How to Mitigate CVE-2025-45311

Immediate Actions Required

Remove sudo rules that grant non-root users the ability to run fail2ban-client, or restrict allowed subcommands to read-only operations such as status and ping.
Inventory hosts running Fail2ban 0.11.2 and identify any delegated administrative access.
Review existing action definitions for unauthorized modifications and revert to known-good configurations.
Rotate credentials for any account that may have abused delegated access.

Patch Information

The Fail2ban maintainers dispute that this constitutes a vulnerability and have not issued a code patch tied to CVE-2025-45311. The recommended remediation is operational: align sudo policy with Fail2ban's documented privilege model. Track the upstream discussion in the GitHub Issue on Fail2ban and the Openwall OSS Security Discussion.

Workarounds

Restrict fail2ban-client execution to root only and use configuration management to deploy jail and action changes.
If delegation is required, write sudoers rules with explicit command allowlists, for example Cmnd_Alias FAIL2BAN_RO = /usr/bin/fail2ban-client status, /usr/bin/fail2ban-client ping.
Enforce mandatory access control profiles (AppArmor or SELinux) on fail2ban-server to constrain the commands its action subsystem can execute.
Separate operational duties so that account holders with sudo access to Fail2ban cannot also modify configuration files outside an auditable workflow.

bash

# Configuration example: restrict sudo to read-only fail2ban-client subcommands
# /etc/sudoers.d/fail2ban-readonly
Cmnd_Alias FAIL2BAN_RO = /usr/bin/fail2ban-client status, \
                        /usr/bin/fail2ban-client status *, \
                        /usr/bin/fail2ban-client ping

%secops ALL=(root) NOPASSWD: FAIL2BAN_RO
# Explicitly deny destructive subcommands
%secops ALL=(root) !/usr/bin/fail2ban-client set *, \
                  !/usr/bin/fail2ban-client add *, \
                  !/usr/bin/fail2ban-client reload *