CVE-2026-54369

What it actually does

The flaw is a symlink traversal issue in libacl pathname-based ACL functions before acl 2.4.0, including acl_get_file(), acl_set_file(), acl_extended_file(), and acl_delete_def_file(). When a privileged process performs ACL operations on a path that includes attacker-controlled path components, an attacker can replace one of those components with a symbolic link and cause the privileged operation to apply to a different file or directory than intended. This can allow unauthorized reading, modification, or deletion of POSIX ACL metadata on arbitrary targets reachable by the privileged caller, potentially enabling local privilege escalation or weakening access controls on sensitive files.

Why it matters to the business

This vulnerability is primarily a local privilege-escalation risk: an attacker already able to create or modify files in a path used by a privileged program may be able to gain broader access on the affected system. Successful exploitation could result in unauthorized access to sensitive files, modification of file permissions, persistence through weakened access controls, or escalation from a low-privileged local account to higher privileges. The issue is not listed in CISA KEV, has low EPSS at the time of assessment, and has no reported exploit maturity in the provided data, so it is less urgent than an actively exploited internet-facing flaw, but it should still be remediated on multi-user systems, build hosts, shared servers, and systems running privileged automation that manipulates ACLs.

How an attack unfolds

An attacker first obtains low-privileged local access to a system or to an application-controlled writable directory. They identify a privileged process, script, package hook, administrative job, or service that calls libacl pathname-based functions against files or directories located under a path component the attacker can influence. The attacker prepares a race or replacement condition by creating a normal directory or file structure that the privileged caller expects, then swaps one pathname component for a symbolic link pointing to a sensitive target. When the privileged caller invokes acl_get_file(), acl_set_file(), acl_extended_file(), or acl_delete_def_file(), libacl follows the attacker-controlled symlink and performs the ACL operation on the unintended target. Depending on the caller behavior, this may grant the attacker access to protected files, remove restrictive ACLs, or otherwise alter permissions in a way that supports privilege escalation. Exploitation is local and depends on a privileged ACL operation crossing attacker-controlled path components; there is no indication from the provided data of active exploitation, ransomware use, or a public mature exploit.

How to fix it

Upgrade acl/libacl to version 2.4.0 or later as soon as packages are available from the operating system or distribution vendor. Apply vendor security updates for all products that bundle or statically link libacl, and rebuild or redeploy statically linked consumers so they use the corrected library. On systems where immediate upgrade is not possible, reduce exposure by avoiding privileged ACL operations on paths containing user-writable components, moving privileged workflows out of attacker-writable directory trees, using file-descriptor-based or no-symlink-follow path handling where available, validating each path component before privileged ACL operations, and applying least privilege to scripts or services that manipulate ACLs. Review custom privileged code that calls acl_get_file(), acl_set_file(), acl_extended_file(), or acl_delete_def_file() and prefer safer designs that open trusted directory file descriptors, reject symlinks, and avoid time-of-check/time-of-use races.

How to confirm the fix worked

Confirm the installed acl/libacl package is version 2.4.0 or later, or that the distribution vendor has backported the fix to its supported package version. Validate both runtime and development packages where applicable, and identify applications that statically link libacl so they can be rebuilt or updated. On Linux systems, package validation can typically be performed with native package tools such as rpm, dpkg, apt, dnf, yum, apk, pacman, or vendor software inventory tooling. After patching, rerun vulnerability scans or software composition analysis to confirm the affected library version is no longer present. For custom privileged software, perform code review or dynamic testing to verify ACL operations cannot be redirected through attacker-controlled symlinks and that ACL changes apply only to intended targets.

Typical attack path

1. Gain low-privileged local access to an affected system or to a writable directory used by a privileged process.
2. Identify a privileged program, script, service, installer, backup job, or administrative workflow that performs POSIX ACL operations through libacl pathname-based APIs.
3. Create or control a pathname component that the privileged caller will process during an ACL read, write, extended ACL check, or default ACL deletion operation.
4. Replace that pathname component with a symbolic link pointing to a sensitive file or directory before or during the privileged ACL operation.
5. Trigger or wait for the privileged process to call acl_get_file(), acl_set_file(), acl_extended_file(), or acl_delete_def_file().
6. Use the redirected ACL operation to weaken access controls, grant access, remove restrictions, or otherwise manipulate permissions on the unintended target.
7. Leverage the changed ACLs to read, modify, or execute protected content and escalate local privileges.

How to detect it

There is no single reliable network indicator for this vulnerability because exploitation is local and depends on how privileged software uses libacl. To investigate possible prior exploitation, review filesystem audit logs, EDR telemetry, shell history, process execution logs, and file integrity monitoring for unexpected ACL changes on sensitive files or directories. Focus on events where ACLs or POSIX ACL extended attributes were changed by privileged processes after accessing paths under user-writable locations such as temporary directories, shared application workspaces, build directories, upload directories, home directories, or spool locations. Look for rapid path replacement patterns, symlink creation or renaming shortly before ACL modification, and ACL changes that grant access to non-administrative users or groups on privileged files. Useful Linux audit sources include auditd SYSCALL, PATH, CWD, PROCTITLE, and xattr-related records; EDR file events showing symlink creation, rename, chmod-like behavior, or xattr modification; package-manager logs confirming whether the vulnerable acl/libacl version was present; and file integrity baselines showing unexpected ACL drift. Investigators should compare current ACLs against known-good baselines using getfacl or equivalent tooling, especially for security-sensitive system paths, service files, privileged executables, configuration files, keys, and credential stores.

What your security team should do

• Prioritize patching shared, multi-user, developer, CI/CD, build, bastion, and administrative systems where untrusted local users or workloads can create filesystem paths processed by privileged tasks.
• Upgrade acl/libacl to 2.4.0 or a vendor-fixed backport, and ensure bundled or statically linked consumers are also updated.
• Inventory privileged scripts, services, installers, backup tools, and administrative automation that manipulate POSIX ACLs on paths that may contain user-writable components.
• Harden privileged filesystem workflows by rejecting symlinks, avoiding attacker-writable parent directories, and using safer file-descriptor-based path handling where feasible.
• Enable or review Linux audit logging for suspicious ACL and extended-attribute changes to sensitive files, especially where changes originate from unexpected privileged processes.
• Treat unexpected ACL grants or removals on sensitive configuration, credential, service, or executable paths as potential evidence of exploitation.
• Because this is not KEV-listed and has low EPSS in the provided data, schedule remediation according to local privilege-escalation risk rather than emergency internet-facing exposure, but do not defer on shared systems.