High [CVE-2026-54369] Symlink traversal privilege escalation via libacl functions
This high-severity Red Hat Linux advisory covers CVE-2026-54369 affecting Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Summary
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. A flaw was found in the `acl` package, specifically within its `libacl` pathname-based functions.
Exploitation requires local access with the ability to create symlinks in a directory that a privileged program later processes with acl_get_file() or acl_set_file(). In default RHEL and OpenShift CoreOS configurations, standard file permission settings limit where unprivileged users can create symlinks, reducing the practical attack surface.
Programs that operate on user-supplied paths with elevated privileges are most at risk. Red Hat severity: Important — CVSS 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).
Weakness: CWE-59.
- < 2.4.0
Official advisory · high-confidence parse· fetched 13 days ago·verify at source
- acl-0:2.4.0-1.el10_2
- acl-0:2.4.0-0.el10_0.1
- acl-0:2.4.0-1.el8_10
- acl-0:2.4.0-1.el9_8
- acl-0:2.4.0-0.el9_2.1
- acl-0:2.4.0-0.el9_4.1
- acl-0:2.4.0-0.el9_6.1
- rhcos-4.22.9.8.202608130832-0
- discovery/discovery-server-rhel9:1784821670
- discovery/discovery-ui-rhel9:1784821750
- acl-main-2.4.0-0.1.hum1
- insights-proxy/insights-proxy-container-rhel9:1786433656
- rhosdt/opentelemetry-collector-rhel9:1785704636
- rhui5/cds-kubernetes-rhel9:1784794818
- rhui5/cds-rhel9:1784794778
- rhui5/haproxy-rhel9:1784795112
- rhui5/installer-rhel9:1784794289
- rhui5/rhua-rhel9:1784795076
- rhui5/cds-kubernetes-tp-rhel9:1787241211
- rhui5/installer-tp-rhel9:1787135742
- rhui5/rhua-tp-rhel9:1787241260
- RHSA-2026:42739
- RHSA-2026:64805
- RHSA-2026:43420
- RHSA-2026:42736
- RHSA-2026:67142
- RHSA-2026:67144
- RHSA-2026:67140
- RHSA-2026:54769
- RHSA-2026:46836
- RHSA-2026:34351
- RHSA-2026:53371
- RHSA-2026:50205
- RHSA-2026:44481
- RHSA-2026:58981
Official advisory · high-confidence parse· fetched 13 days ago·verify at source
Mitigation checklist
- Restrict unprivileged users from creating symlinks in directories that privileged processes operate on with ACL commands. Where possible, use the fs.protected_symlinks sysctl (enabled by default on RHEL 7+), which prevents symlink following in world-writable sticky directories unless the owner of the symlink matches the owner of the target file or directory.
Official advisory · high-confidence parse· fetched 13 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.