Symlink Attacks: When File Operations Betray Your Trust

Symbolic links are one of the most powerful features in modern operating systems, enabling flexible file management and elegant system architecture. However, this same flexibility creates a dangerous attack surface that continues to plague developers and security teams worldwide. From container escapes in Docker and Kubernetes to privilege escalation on Windows and Linux systems, symlink attacks remain a persistent and evolving threat that demands attention.

Understanding Symbolic Links and Their Security Implications

A symbolic link (symlink) is a special type of file that serves as a pointer or reference to another file or directory. Unlike hard links that point directly to data on disk, symlinks contain the path to their target, acting essentially as sophisticated shortcuts. This indirection is precisely what makes them both useful and dangerous.

When an application follows a symlink, it typically accesses the target file with the permissions of the process performing the operation—not the permissions of the user who created the link. This behavior creates opportunities for attackers to redirect privileged file operations to unintended locations, bypassing access controls and manipulating sensitive system resources.

The fundamental security concern with symlinks stems from how operating systems resolve file paths. When a privileged process opens a file path containing symlinks, it follows those links transparently, potentially accessing files the original requester should never touch. An attacker who can create symlinks in strategic locations can exploit this behavior to read, write, or delete files far outside their intended access scope.

The Anatomy of Symlink Attacks

Symlink attacks generally fall into several categories, each exploiting different aspects of file system behavior and application design.

File Upload and Extraction Vulnerabilities

One of the most prevalent attack vectors involves archive extraction—a vulnerability class popularized by the “Zip Slip” research disclosed in 2018 that affected thousands of projects across multiple programming ecosystems. The attack leverages maliciously crafted archive files containing either path traversal sequences or symbolic links that, when extracted, write files outside the intended destination directory.

The symlink variant of this attack is particularly insidious. An attacker creates an archive containing a symlink entry pointing outside the extraction directory, followed by a regular file with the same name. During extraction, the symlink is created first, establishing a path to an arbitrary location. When the subsequent file is extracted, the application follows the symlink and writes content to the attacker-controlled target location.

This vulnerability pattern continues appearing in modern software. In April 2025, a Zip Slip vulnerability was discovered in the popular Go library mholt/archiver (CVE-2025-3445), demonstrating that despite years of awareness, new instances continue to emerge in both legacy and modern codebases.

Symlink Race Conditions (TOCTOU)

Time-of-check to time-of-use (TOCTOU) race conditions represent another major category of symlink vulnerabilities. These attacks exploit the window between when an application checks a file’s properties and when it actually uses the file. An attacker who can replace a legitimate file with a symlink during this window can redirect the operation to an unintended target.

The classic example involves privileged programs that check file permissions before performing operations. A malicious user creates a symbolic link to a file they cannot normally access. When the privileged program creates a file matching the symlink’s name, it actually creates (or modifies) the linked target file instead, potentially inserting attacker-controlled content into protected locations.

These races have caused significant real-world impact. In October 2025, AWS experienced a major disruption due to a TOCTOU race condition in its DNS management system for DynamoDB, resulting in widespread service failure across the US-EAST-1 region. The incident demonstrated how race conditions can affect even the most sophisticated infrastructure.

Container Escapes: Breaking the Isolation Boundary

Container technologies like Docker and Kubernetes rely heavily on Linux namespaces and filesystem isolation to separate workloads. Symlink attacks have repeatedly proven effective at breaking these boundaries, allowing attackers to escape container isolation and access the host system.

The Leaky Vessels Vulnerabilities

In January 2024, Snyk announced the discovery of four critical vulnerabilities in Docker and Kubernetes that exemplify container-focused symlink attacks. CVE-2024-21626, affecting the runC container runtime, involved a file descriptor leak that attackers could exploit using symlinks to gain access to the host filesystem.

A malicious container image could set up paths that, through symlink manipulation, provided the container process with working directory access to the host filesystem rather than the container’s isolated environment. This granted read, write, and potentially execute privileges on host resources depending on the leaked file descriptor’s permissions.

CVE-2024-23651 demonstrated a symlink race condition during Docker’s build process. By carefully timing symlink operations during cache invalidation, attackers could mount sensitive host directories into the container filesystem, enabling data exfiltration or privilege escalation.

The 2025 RunC Vulnerabilities

The container security landscape faced renewed challenges in November 2025 with the disclosure of three new high-severity vulnerabilities in runC (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881). These flaws center on how runC handles masked paths, mount targets, and writes to procfs—all manipulable through race conditions and symlink abuse.

The vulnerabilities exploit runC’s use of /dev/null to mask sensitive host files. Because runC failed to verify that /dev/null was legitimate, attackers could swap it with a symlink during container initialization. This allowed arbitrary host paths to be bind-mounted into the container, enabling writes to critical locations like /proc/sys/kernel/core_pattern—a well-known container escape vector.

The Kubernetes log mount escape technique further illustrates these risks. Kubernetes stores pod logs in /var/log with symlinks pointing to container log files. Attackers with access to a pod mounted on /var/log can manipulate these symlinks to read arbitrary host files through the Kubernetes log interface, demonstrating how legitimate functionality can be weaponized.

Privilege Escalation on Desktop Systems

Beyond containers, symlink attacks remain a potent privilege escalation technique on traditional Windows and Linux systems.

Windows Privilege Escalation

Windows presents multiple symlink types that attackers can chain together for privilege escalation: NTFS junctions (directory-level redirections), object manager symbolic links, and registry key symbolic links. Research by James Forshaw and others has shown how combining these primitives enables powerful attacks against privileged processes.

CVE-2019-1161, a vulnerability in Windows Defender, exemplifies this pattern. The MpSigStub.exe process, running with SYSTEM privileges, could be manipulated through object manager symlinks to delete arbitrary files. An attacker created symlinks redirecting Defender’s file operations to protected system locations, achieving arbitrary file deletion with the highest privileges.

Microsoft has implemented mitigations including restricting sandboxed processes from creating certain symlink types and adding verification checks. However, the October 2025 disclosure of CVE-2025-55696—a TOCTOU race in NtQueryInformationToken—demonstrates that Windows kernel code remains vulnerable to race-based attacks that can lead to privilege escalation.

Linux and Unix Vulnerabilities

Linux systems face particular challenges with symlink attacks in world-writable directories like /tmp. The “Nimbuspwn” vulnerabilities (CVE-2022-29799 and CVE-2022-29800) discovered in the systemd component networkd-dispatcher combined directory traversal with symlink races to achieve root privilege escalation.

Kernel developers have implemented protections for sticky directories (like /tmp), restricting symlink following so that only symlinks owned by the directory owner or the symlink’s target owner can be followed. However, these protections don’t cover all scenarios, and vulnerable applications continue to be discovered.

Apple Ecosystem: TCC Bypass Through Symlinks

In December 2024, Jamf Threat Labs disclosed CVE-2024-44131, demonstrating how symlink attacks could bypass Apple’s Transparency, Consent, and Control (TCC) framework on iOS and macOS. The vulnerability resided in the FileProvider component, allowing malicious apps to intercept user file operations and redirect them through symlinks.

When a user moved or copied files using the Files app, a background malicious app could manipulate symlinks to redirect the operation, gaining unauthorized access to protected data including health information, photos, and even camera or microphone access—all without triggering user prompts. Apple addressed the issue with improved symlink validation in iOS 18 and macOS Sequoia 15.

Defense Strategies and Mitigation

Protecting against symlink attacks requires a multi-layered approach combining secure coding practices, system hardening, and runtime monitoring.

Secure File Operations

Applications handling file operations, particularly with elevated privileges, should implement several defensive measures. Using the O_NOFOLLOW flag when opening files prevents automatic symlink resolution, forcing applications to explicitly handle symlinks. Before performing sensitive operations, applications should use functions like lstat() to check if paths are symlinks and validate their targets.

For archive extraction, applications must validate that destination paths remain within intended directories after resolving any symlinks. The filepath.EvalSymlinks function in Go and similar facilities in other languages help resolve the full path before performing extraction. Applications should reject archives containing symlinks pointing outside the extraction directory or, where symlinks aren’t needed, simply skip symlink entries entirely.

Race Condition Mitigation

Eliminating TOCTOU vulnerabilities requires atomic operations that combine checking and using resources without an exploitable window. Creating temporary files with O_CREAT|O_EXCL ensures atomic creation that fails if the file already exists, preventing symlink substitution. The mkstemp() function provides secure temporary file creation that avoids predictable naming.

File locking with APIs like LockFileEx on Windows helps prevent manipulation during critical operations, though it doesn’t protect against all attack scenarios. Where possible, using file descriptors rather than paths for subsequent operations ensures the application continues working with the originally opened resource regardless of path changes.

System-Level Protections

Operating systems provide various symlink protections that administrators should enable. Linux’s fs.protected_symlinks sysctl setting restricts symlink following in sticky directories. Windows Defender Credential Guard and application allowlisting can prevent untrusted code from running in contexts where symlink attacks would be effective.

For container environments, enabling user namespaces without mapping the host root user prevents namespaced users from accessing relevant host files due to Unix DAC permissions. Rootless containers significantly reduce the potential damage from container escape vulnerabilities by eliminating root privileges entirely. Enforcing Pod Security Standards, applying seccomp profiles, and implementing AppArmor or SELinux policies minimize the syscall and filesystem attack surface available to containerized workloads.

Monitoring and Detection

Security teams should monitor for suspicious symlink creation patterns, particularly in sensitive directories or from unprivileged processes targeting privileged locations. EDR solutions can flag rapid symlink creation operations, unusual mount activities, and unexpected writes to /proc or other sensitive locations.

Runtime security tools like Falco can detect container escape attempts by monitoring for symlink creation pointing to sensitive host directories during container initialization. Correlating these events with process behavior helps distinguish legitimate operations from exploitation attempts.

Conclusion

Symlink attacks occupy a unique position in the security landscape—they exploit fundamental operating system features rather than implementation bugs, making them inherently difficult to eliminate. The continued stream of CVEs affecting everything from container runtimes to mobile operating systems demonstrates that even sophisticated development teams struggle to handle symlinks safely.

For organizations, the path forward requires acknowledging symlinks as a persistent threat requiring ongoing attention. This means implementing secure coding practices in custom applications, keeping container runtimes and system components updated, enabling available OS-level protections, and maintaining visibility into file system operations that could indicate exploitation attempts.

As cloud-native architectures proliferate and containers become the default deployment model, the attack surface for symlink-based exploits only grows. The runtime layer that provides container isolation becomes a single point of failure where symlink manipulation can breach the boundary between isolated workloads and underlying infrastructure. Understanding these attacks and implementing comprehensive defenses is no longer optional—it’s essential for maintaining the integrity of modern computing environments.