HIGH 7.1

CVE-2026-54369: acl Symlink Traversal Privilege Escalation Vulnerability

A vulnerability in the acl library before version 2.4.0 allows local users to escalate their privileges by exploiting how the library handles file paths. An attacker who can control any part of a file path—such as a directory name—can replace it with a symbolic link to redirect the library's ACL (Access Control List) operations to different files or directories than intended. This misdirection lets them read or modify access permissions on files they shouldn't be able to touch, ultimately gaining higher privileges on the system.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.1 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weaknesses (CWE)
CWE-59
Affected products
0 configuration(s)
Published / Modified
2026-06-29 / 2026-08-05

NVD description (verbatim)

acl before version 2.4.0 contains a symlink traversal vulnerability in the libacl pathname-based functions acl_get_file(), acl_set_file(), acl_extended_file(), and acl_delete_def_file() that allows local attackers to escalate privileges by replacing any pathname component with a symbolic link. Attackers who control any component of a pathname processed by a privileged caller can redirect ACL read or write operations to arbitrary files or directories, enabling unauthorized manipulation of access control lists and local privilege escalation.

13 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-54369 is a symlink traversal vulnerability affecting libacl's pathname-based functions: acl_get_file(), acl_set_file(), acl_extended_file(), and acl_delete_def_file(). The flaw stems from insufficient validation of symbolic links in pathname resolution. When a privileged process calls these functions with a path containing attacker-controlled components, the attacker can insert a symlink at any point in that pathname. The library follows the symlink without proper verification, causing ACL operations to be performed on arbitrary files or directories controlled by the attacker. This enables unauthorized manipulation of access control lists and local privilege escalation. The vulnerability requires local access and is rated CVSS 7.1 (HIGH) with high impact on confidentiality and integrity.

Business impact

Organizations relying on acl for discretionary access control on Linux/Unix systems face a local privilege escalation risk. If a privileged application—such as a system daemon, backup utility, or administrative tool—uses vulnerable acl functions and operates on paths where unprivileged users can introduce symlinks, attackers can bypass access controls and gain elevated permissions. In multi-tenant or shared hosting environments, this is particularly concerning. The vulnerability could lead to unauthorized access to sensitive data, modification of system configurations, or complete system compromise if chained with other attacks.

Affected systems

The acl library versions before 2.4.0 are affected. Systems running older versions of libacl on Linux and Unix platforms are at risk, particularly those where local user accounts exist and privileged processes invoke acl pathname functions on user-writable directories or paths where symlinks can be introduced. The vulnerability requires local access, so Internet-facing systems without local user accounts face lower immediate risk, but internal infrastructure, development systems, and multi-user environments warrant urgent assessment.

Exploitability

Exploitability is straightforward for attackers with local system access. The attack requires only the ability to create symbolic links in directories where a privileged process will later call acl functions—a common scenario in shared directories, temporary folders, or application-specific paths. No authentication bypass or complex race conditions are necessary; the attacker simply places a symlink in advance and waits for or triggers the vulnerable code path. This makes it a practical privilege escalation vector in environments with multiple local users.

Remediation

Upgrade the acl library to version 2.4.0 or later. Verify the upgrade across all systems running acl, including embedded or bundled installations within other software. Additionally, review application code and system configurations to identify where privileged processes invoke acl functions on paths where unprivileged users can introduce symlinks. Where possible, restrict symlink creation in critical directories or ensure that privileged operations use hardened path handling.

Patch guidance

Apply the update to acl version 2.4.0 or later across your infrastructure. Check both system package repositories (apt, yum, apk, etc.) and any in-house or containerized deployments of the acl library. Verify the update with your vendor's advisory or release notes to confirm the symlink traversal fix is included. Test the patched version in a non-production environment before full rollout to ensure compatibility with dependent applications and scripts that rely on acl functionality.

Detection guidance

Monitor system logs for unusual symlink activity in directories where privileged processes operate—particularly in temporary directories, application cache locations, and shared user directories. Use file integrity monitoring (FIM) tools to detect unexpected symlink creation in sensitive paths. Audit process execution logs to identify calls to acl functions by privileged processes operating on paths controlled or writable by unprivileged users. Endpoint detection and response (EDR) solutions can flag suspicious symlink-based path manipulation patterns correlated with privilege escalation attempts.

Why prioritize this

This vulnerability merits HIGH priority because it enables local privilege escalation through a straightforward attack requiring only local access. The impact on both confidentiality and integrity is significant. Organizations with multi-user systems, shared hosting, or development environments should prioritize patching. Even if your immediate Internet-facing systems have no local users, internal infrastructure running acl should be addressed promptly to prevent lateral movement and post-compromise privilege escalation.

Risk score, explained

The CVSS 7.1 (HIGH) rating reflects a local-only attack vector (AV:L), low complexity (AC:L), and a requirement for low privilege (PR:L). While the attack requires local access and cannot be exploited remotely, the absence of user interaction (UI:N) and the high impact on confidentiality and integrity (C:H/I:H) justify the elevated score. The vulnerability does not affect availability. Organizations with restricted local access may consider the practical risk lower, but the ease of exploitation and the direct path to privilege escalation keep this in the HIGH category.

Frequently asked questions

Does this vulnerability affect systems where only administrators have local access?

While risk is lower in environments with strictly controlled local access, the vulnerability still poses a threat during administrative operations, especially in automated or privileged system processes. Additionally, if any unprivileged service account can introduce symlinks, or if an administrator later gets compromised, the vulnerability becomes an escalation path. Patching is still recommended for defense-in-depth.

Can this be exploited remotely?

No. The CVSS vector shows AV:L (Attack Vector: Local), meaning the attacker must have local access to the system. Remote exploitation is not possible; however, remote compromise followed by local symlink-based privilege escalation is a realistic post-compromise scenario.

What versions of acl are safe?

Version 2.4.0 and later contain the fix for this symlink traversal vulnerability. Verify your current version with `getfacl --version` or `rpm -q acl` (Linux) and confirm you are running 2.4.0 or later after patching.

Are there workarounds if I cannot patch immediately?

While patching is the definitive fix, interim mitigations include restricting symlink creation in directories where privileged processes invoke acl functions, running acl-dependent services with minimal necessary privileges, and isolating multi-user systems where feasible. However, these are not substitutes for upgrading and should be treated as temporary measures.

This analysis is based on the vulnerability disclosure as of the published and modified dates listed. CVSS scores and severity ratings are provided by the National Vulnerability Database and reflect the authors' assessment at the time of publication. Actual risk varies by system configuration, network segmentation, and access controls in your environment. Always verify vendor advisories and test patches in non-production environments before deployment. SEC.co makes no warranty regarding the completeness or accuracy of third-party vulnerability data and recommends consulting official vendor resources for definitive patching and compatibility information. Source: NVD (public-domain), retrieved 2026-08-08. Analysis generated by SEC.co (claude-haiku-4-5).