CVE-2026-54370

What it actually does

This is a local time-of-check to time-of-use race condition in acl before 2.4.0. The vulnerable utilities and library paths perform an lstat() check on a pathname component and later perform operations that may follow symbolic links, including stat(), chown(), chmod(), acl_get_file(), and acl_set_file(). If a low-privileged local attacker controls part of the path being processed, they can rapidly replace that component with a symlink after the check but before the use, causing privileged ACL or permission operations to be applied to an unintended file. Successful exploitation can modify access controls or ownership-related metadata on arbitrary files reachable by the privileged process, enabling local privilege escalation. Exploitation requires local access, control over a pathname component, and reliable race timing, so the attack complexity is high, but the confidentiality and integrity impact can be significant if privileged automation invokes getfacl, setfacl, or chacl on attacker-controlled paths.

Why it matters to the business

Systems that use vulnerable acl versions in privileged maintenance jobs, backup scripts, provisioning workflows, package hooks, or administrative tooling may allow a local user to turn limited shell access into elevated access. The most likely operational consequences are unauthorized modification of file permissions, exposure of protected files, tampering with security-sensitive configuration, and potential root-level compromise on shared Linux or Unix-like systems. The CVSS score is moderate and EPSS is currently very low, with no known CISA KEV listing or ransomware association, so this is not an internet-scale emergency; however, it is important for multi-user systems, build servers, shared hosting, developer workstations, and environments where untrusted users or workloads can create filesystem paths processed by privileged jobs.

How an attack unfolds

An attacker first obtains low-privileged local access to a system running acl before 2.4.0. They identify a privileged process, script, or administrative workflow that runs getfacl, setfacl, chacl, or acl library operations against a directory tree containing attacker-controlled path components, such as a writable workspace, temporary directory, extracted archive, user home subdirectory, or build artifact path. The attacker prepares a benign-looking file or directory so the privileged process passes its lstat() safety check. During the narrow race window before the later symlink-following operation, the attacker replaces that component with a symbolic link to a sensitive target file. If the race is won, the privileged ACL or permission operation is redirected to the target. The attacker can then use the resulting ACL or permission change to read protected data, alter privileged configuration, or create a path to further privilege escalation. There are no named threat actors or public exploit maturity signals in the supplied data, but the vulnerability class is well understood and may be attractive in local post-compromise escalation scenarios.

How to fix it

Upgrade acl to version 2.4.0 or later wherever it is installed. If vendor packages are used, apply the distribution-provided security update rather than building manually, because package maintainers may backport the fix while retaining an older-looking version string. Until patching is complete, reduce exposure by avoiding privileged getfacl, setfacl, and chacl operations over attacker-writable directories; do not run ACL-recursive maintenance tasks over paths beneath /tmp, world-writable directories, shared workspaces, unpacked untrusted archives, user-writable build directories, or untrusted mount points; and review scripts that combine elevated privileges with user-controlled path input. Where feasible, perform privileged ACL changes only on canonicalized, trusted paths and isolate untrusted workloads from privileged filesystem maintenance automation.

How to confirm the fix worked

Confirm the installed acl package is version 2.4.0 or a vendor-patched build that includes the TOCTOU fix. Use package-manager queries such as rpm -q acl, dpkg -l acl, apk info acl, or the equivalent for the platform, and verify against the operating system vendor advisory if the displayed version includes backported patches. Inventory privileged scripts, cron jobs, systemd timers, CI/CD runners, backup jobs, and provisioning tools for calls to getfacl, setfacl, chacl, or acl library operations over writable or user-supplied paths. Validate that privileged ACL operations are no longer performed on attacker-controlled path components. For higher assurance, run file integrity monitoring or audit rules around sensitive files while exercising administrative ACL workflows to confirm ACLs are not unexpectedly modified through symlinked paths.

Typical attack path

1. Gain low-privileged local access to a vulnerable system.
2. Find a privileged job, script, or administrator action that invokes getfacl, setfacl, chacl, or acl library functions on a path containing attacker-controlled components.
3. Create or prepare files/directories under the attacker-controlled path so initial lstat() checks appear safe.
4. Continuously swap a checked pathname component with a symbolic link to a chosen sensitive target file during the race window.
5. Wait for the privileged ACL or permission operation to follow the symlink and modify the unintended target.
6. Use the altered ACLs or permissions to read protected files, modify privileged configuration, or otherwise escalate local privileges.

How to detect it

To investigate possible prior exploitation, focus on local telemetry because this is not remotely exploitable by itself. Review process execution logs, auditd logs, EDR telemetry, shell history, sudo logs, cron/systemd timer logs, and file integrity monitoring for privileged executions of getfacl, setfacl, or chacl against attacker-writable paths such as /tmp, /var/tmp, user home directories, shared build workspaces, extracted archives, or world-writable mount points. Look for bursts of symlink creation, deletion, and rename operations occurring immediately before or during privileged ACL operations. Audit sensitive files for unexpected ACL entries, permission changes, or metadata changes around the same timestamps, especially files under /etc, privileged service configuration directories, root-owned SSH material, sudo policy files, service unit files, and application secrets. In auditd, useful evidence may include execve events for setfacl/chacl/getfacl by uid 0, symlink or rename syscalls under writable directories, and setxattr/removexattr/chmod/chown activity against sensitive targets. Because successful exploitation is race-dependent, absence of a single command string does not prove safety; correlate process, filesystem, and ACL change timelines.

• /usr/bin/setfacl
• /bin/setfacl
• /usr/bin/getfacl
• /bin/getfacl
• /usr/bin/chacl
• /bin/chacl
• comm="setfacl"
• comm="getfacl"
• comm="chacl"
• type=EXECVE
• SYSCALL=symlink
• SYSCALL=symlinkat
• SYSCALL=rename
• SYSCALL=renameat
• SYSCALL=renameat2
• SYSCALL=setxattr
• SYSCALL=lsetxattr
• SYSCALL=removexattr
• SYSCALL=chmod
• SYSCALL=fchmodat
• SYSCALL=chown
• SYSCALL=fchownat
• setfacl -m
• setfacl --modify
• setfacl -R
• setfacl --recursive
• chacl -r
• getfacl -R
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Prioritize patching acl to 2.4.0 or a vendor-fixed package on multi-user systems, shared build infrastructure, bastion hosts, developer workstations, and systems that run privileged filesystem automation over user-controlled content.
• Search privileged scripts, cron jobs, systemd units, backup tooling, deployment tooling, and CI/CD jobs for getfacl, setfacl, or chacl usage involving /tmp, user homes, shared workspaces, extracted archives, or other writable paths.
• Temporarily block or redesign privileged ACL operations over untrusted path trees until patching and workflow review are complete.
• Add audit or EDR monitoring for root-owned getfacl, setfacl, and chacl executions against writable directories and for suspicious rapid symlink replacement activity near those executions.
• Review recent ACL or permission changes on sensitive files if vulnerable systems allowed local untrusted users or workloads.
• Treat any confirmed successful exploitation as a local privilege escalation incident and perform full host triage, because the attacker may have modified permissions to enable persistence or data access.