CVE-2026-108981 in ngx_cache_purge
Summary
by MITRE • 10/12/2026
ngx_cache_purge before 3.0.4 can allow file deletion via a symlink attack in certain situations where nginx and a served application (e.g., WordPress) run under the same user account. The attacker must be able to create a symlink inside the cache path. Version 3.0.4 fixes this for the case of a symlink created at an arbitrary earlier time, but does not resolve an applicable TOCTOU race condition. (The ngx_cache_purge module follows symlinks while walking the cache directory tree during purge operations. The module relies on nginx's ngx_walk_tree(), which relies on stat() and therefore follows symlinks.)
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in versions of the ngx_cache_purge module prior to 3.0.4 represents a critical security flaw rooted in improper handling of symbolic links during cache directory traversal operations. This issue specifically affects environments where the Nginx web server and the backend application, such as WordPress, operate under the same user account privileges. The core technical failure lies within the purge mechanism which is designed to remove cached content from disk storage. When executing these cleanup routines, the module utilizes nginx's internal ngx_walk_tree function to iterate through the cache directory structure. This underlying function relies on standard system calls like stat(), which inherently follow symbolic links rather than treating them as distinct file entries. Consequently, if an attacker can create a symlink within the accessible cache path that points to a sensitive location outside of the intended web root or cache directory, the purge operation will inadvertently delete the target file referenced by that link instead of merely removing the cached entry itself.
The operational impact of this vulnerability is severe, potentially leading to arbitrary file deletion on the host system depending on the permissions granted to the user account running Nginx. An attacker who gains write access to the cache directory can craft a symbolic link pointing to critical system files or application configuration data. Upon triggering a purge operation for any cached item that causes the module to traverse the path containing this malicious symlink, the targeted file is deleted permanently. This capability allows an unprivileged user with limited web-facing access to escalate their impact significantly by disrupting service availability through denial of service attacks against specific files or potentially compromising system integrity if critical binaries are removed. The risk is exacerbated in shared hosting environments or misconfigured setups where application code and server processes share identical filesystem privileges, removing the isolation barrier that typically prevents such cross-context damage.
This flaw aligns with CWE-59 Improper Link Resolution Before File Access commonly known as a symlink attack, specifically manifesting during file deletion operations rather than just read access. The vulnerability also exhibits characteristics of CWE-367 Time-of-check to Time-of-use race conditions because the module follows symlinks based on their state at the time of traversal without verifying that the link target remains within an expected safe boundary throughout the operation. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1564.008 Hidden Files and Directories: Symbolic Link Hijacking, where attackers leverage symbolic links to redirect operations toward unintended targets. The module's design choice to follow symlinks during recursive directory walks creates a predictable attack vector that exploits the trust placed in filesystem metadata without sufficient validation of link destinations against allowlists or path constraints.
Mitigation strategies must address both the immediate software defect and the underlying architectural risks associated with shared user privileges. Upgrading to ngx_cache_purge version 3.0.4 is the primary remediation step as it resolves the specific case where symlinks created at arbitrary earlier times are followed during purge operations. However, administrators should be aware that this update does not fully resolve all applicable time-of-check-to-time-of-use race conditions inherent in the module's design philosophy regarding symlink handling. Therefore, additional hardening measures are recommended to reduce the attack surface. These include configuring Nginx and backend applications to run under distinct user accounts with minimal privileges, ensuring that cache directories are owned by a dedicated service account separate from application code writers. Furthermore, implementing filesystem-level protections such as mount options like nosymlinks or using chroot jails can prevent symbolic link exploitation entirely. Regular auditing of file permissions and monitoring for unusual symlink creation in web-accessible directories provides an additional layer of defense against this class of vulnerability.