CVE-2026-54371

What it actually does

attr versions before 2.6.0 have a time-of-check/time-of-use symlink traversal flaw in the getfattr and setfattr utilities. When these tools traverse a directory hierarchy, an attacker who can control or replace a pathname component can swap that component with a symbolic link and redirect the privileged file-attribute operation to a different file. If getfattr or setfattr is run by root or another privileged process against an attacker-controlled path, the attacker may cause extended attributes to be read from or written to arbitrary local files, potentially enabling local privilege escalation or unauthorized disclosure of sensitive file metadata.

Why it matters to the business

This is a local privilege-escalation risk affecting systems where privileged scripts, backup jobs, packaging workflows, scanners, or administrative automation run getfattr or setfattr over paths writable by less-privileged users. Successful exploitation could allow a local user or compromised application account to gain higher privileges, tamper with sensitive files, or access protected metadata. The CVSS score is high at 7.1, but current EPSS is very low, it is not listed in CISA KEV, and no mature public exploit is indicated, so remediation should be prioritized for multi-user Linux systems, shared hosting, build infrastructure, and servers processing untrusted filesystem content.

How an attack unfolds

An attacker first obtains local access as a low-privileged user or controls a directory that a privileged process later scans or modifies using getfattr or setfattr. The attacker prepares a directory hierarchy and monitors for the privileged operation. During traversal, the attacker replaces a pathname component with a symbolic link pointing to a protected target file. Because vulnerable versions do not safely constrain traversal against this race, the utility can follow the substituted symlink and perform the intended extended-attribute read or write on the attacker-chosen target instead of the original path. With setfattr, this may allow manipulation of sensitive extended attributes if the invoking process has sufficient privileges; with getfattr, it may expose metadata from files the attacker could not normally inspect. The practical impact depends heavily on whether privileged automation invokes these utilities on attacker-controlled paths.

How to fix it

Upgrade the attr package to version 2.6.0 or later wherever it is installed. If vendor packages use backported patches, install the vendor security update that explicitly addresses this symlink traversal issue even if the displayed upstream version remains below 2.6.0. As interim mitigation, do not run getfattr or setfattr as root or with elevated privileges over attacker-writable directories, user upload areas, temporary directories, build workspaces, extracted archives, or other untrusted filesystem trees. Replace shell scripts that recursively process untrusted paths with safer code that opens directories using file-descriptor-relative APIs, avoids following symlinks, validates ownership and permissions after opening, and fails closed on path changes. Limit write access to directories processed by privileged automation and use sandboxing, least-privilege service accounts, and filesystem protections where possible.

How to confirm the fix worked

Confirm installed attr versions using package inventory and commands such as `getfattr --version`, `setfattr --version`, `rpm -q attr`, `dpkg -l attr`, or the relevant package manager for the platform. Validate that all systems have attr 2.6.0 or a vendor-patched equivalent. Review privileged scripts, cron jobs, systemd timers, backup tooling, build tooling, and maintenance automation for invocations of getfattr or setfattr against writable or untrusted paths. In a non-production test environment, verify that privileged workflows no longer follow attacker-replaced symlink components during traversal. Confirm mitigations by ensuring unprivileged users cannot modify any directory components traversed by privileged getfattr/setfattr jobs.

Typical attack path

1. Gain local low-privileged access or control over a writable directory processed by a privileged job or script.
2. Identify privileged use of getfattr or setfattr against a path containing attacker-controlled components.
3. Create a directory/file structure designed to be traversed by the privileged utility.
4. Race the traversal by replacing a pathname component with a symbolic link to a protected target file.
5. Cause the privileged getfattr or setfattr process to follow the symlink and operate on the attacker-selected target.
6. Use the resulting attribute disclosure or modification to escalate privileges, weaken protections, or support further local compromise.

How to detect it

To assess possible prior exploitation, review process execution telemetry, auditd logs, sudo logs, shell history for privileged accounts, cron/systemd job logs, and EDR data for getfattr or setfattr executions running as root or another privileged user against writable or untrusted directories. Correlate those executions with rapid symlink creation, deletion, or rename activity in the same path immediately before or during execution. Linux audit records of interest include execve for getfattr/setfattr, symlink/symlinkat, rename/renameat/renameat2, setxattr/lsetxattr/fsetxattr, and operations involving sensitive files. For suspected setfattr abuse, examine unexpected extended attributes on sensitive binaries, scripts, service files, and configuration files, especially security.capability, trusted.*, security.*, and system.* attributes. Look for privileged automation errors, unusual attribute changes, or access to files outside the intended directory tree. There are no reliable network indicators because exploitation is local and filesystem-race based; detections should be behavior-focused and treated as low-to-medium fidelity unless correlated with writable-path traversal and symlink activity.

• /usr/bin/getfattr
• /usr/bin/setfattr
• comm="getfattr"
• comm="setfattr"
• a0="getfattr"
• a0="setfattr"
• type=EXECVE msg=audit
• syscall=symlink
• syscall=symlinkat
• syscall=rename
• syscall=renameat
• syscall=renameat2
• syscall=setxattr
• syscall=lsetxattr
• syscall=fsetxattr
• security.capability
• trusted.
• security.
• system.posix_acl_access

What your security team should do

• Inventory all Linux/Unix systems with the attr package installed and prioritize multi-user servers, CI/build workers, shared application hosts, and systems processing untrusted files.
• Patch attr to 2.6.0 or the vendor-fixed package version as part of the next security update cycle; expedite where privileged automation processes writable paths.
• Search configuration management, scripts, cron, and systemd units for privileged getfattr or setfattr usage and remove unsafe traversal of user-controlled directories.
• Add audit or EDR monitoring for root-owned getfattr/setfattr executions involving /tmp, /var/tmp, home directories, upload directories, build workspaces, or extracted archives.
• Harden relevant workflows by using least privilege, dedicated service accounts, ownership checks, and no-symlink-safe file handling patterns.
• Because this is not currently KEV-listed and has very low EPSS, track for exploit publication but prioritize based on local exposure and presence of vulnerable privileged workflows.