CVE-2026-108981: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-108981 is a UNIX symbolic link (symlink) following vulnerability in the ngx_cache_purge nginx module that allows a local low-privileged attacker to delete arbitrary files outside the cache directory. It affects ngx_cache_purge versions 2.4.0 through 2.5.6 and 3.0.0 through 3.0.3, and is exploitable only when nginx and a served application (e.g., WordPress) run under the same OS user account. The vulnerability was published on October 12, 2026, with a fix released in version 3.0.4. It carries a CVSS v3.1 base score of 3.6 (Low) (Github Advisory, Feedly).

The root cause is CWE-61 (UNIX Symbolic Link Following): the module's four purge walk operations (purge_all, wildcard/partial purge, vary-aware exact purge, and background queue) all rely on nginx's ngx_walk_tree(), which classifies directory entries using ngx_de_info() — a wrapper around stat() on Unix — and therefore follows symbolic links. The pre_tree_handler callback, which can return NGX_DECLINED to skip a directory, was set to a no-op, meaning any symlink planted inside the cache path (e.g., cache/evil -> /var/www/wp-content) would be recursively walked and its contents deleted. The fix in version 3.0.4 introduces ngx_http_purge_file_cache_pre_tree(), which calls ngx_link_info() (lstat()) on each directory before descent and returns NGX_DECLINED for symbolic links; however, a narrow TOCTOU race condition between lstat() and opendir() remains unresolved (GitHub PR #72, GitHub Commit).

A local attacker with low privileges who can write to the cache directory can delete arbitrary files accessible to the nginx worker user, including application files, configuration files, or uploaded content (e.g., WordPress wp-content or uploads directories). There is no confidentiality impact, but integrity and availability are both affected — critical application files can be permanently deleted, potentially causing service disruption or application compromise. The attack is most impactful in shared-user deployments where nginx and PHP-FPM (or similar) run as the same OS user (e.g., www-data), a common configuration (GitHub PR #72, Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires local access and the ability to create a symlink inside the cache path, and triggering the deletion requires a cache purge operation to occur (which may happen automatically via cache plugins). No threat actor attribution is available.

1. Identify target environment: Confirm that nginx with ngx_cache_purge (versions 2.4.0–2.5.6 or 3.0.0–3.0.3) is running under the same user account as a web application (e.g., www-data for both nginx and PHP-FPM/WordPress).
2. Gain write access to cache directory: Exploit a vulnerability in the web application (e.g., a file write or code execution flaw in WordPress) to obtain the ability to create files/symlinks inside the nginx cache path (e.g., /var/cache/nginx/).
3. Plant a malicious symlink: Create a symbolic link inside the cache directory pointing to a target directory outside the cache whose files should be deleted: ln -s /var/www/html/wp-content /var/cache/nginx/evil.
4. Trigger a cache purge: Wait for or trigger a purge_all or wildcard purge operation. This may occur automatically via a WordPress cache plugin, or can be triggered if the attacker has access to send a PURGE request. The module walks the cache tree, follows the symlink, and deletes files in the target directory.
5. Achieve arbitrary file deletion: Files in the symlinked directory (e.g., /var/www/html/wp-content/) are deleted with the privileges of the nginx worker user, potentially causing application failure or enabling further exploitation (GitHub PR #72).

• File System: Unexpected symbolic links inside the nginx cache directory (e.g., /var/cache/nginx/<zone>/evil -> /var/www/html/wp-content); missing application files (uploads, plugins, themes) that were previously present.
• Logs: nginx error log entries containing ngx_cache_purge: skipping symbolic link in cache tree (present only after patching to 3.0.4); unexpected Permission denied or unlink() errors in nginx logs during purge operations on paths outside the cache.
• Process: Purge operations (purge_all or wildcard PURGE requests) occurring at unusual times or frequencies, particularly if triggered by automated cache plugins.

Upgrade ngx_cache_purge to version 3.0.4 or later, which introduces lstat()-based symlink detection in all four purge walk paths (Release 3.0.4). Note that a residual TOCTOU race condition between lstat() and opendir() remains in 3.0.4; the robust architectural mitigation is to run nginx and served applications (e.g., PHP-FPM) under separate OS user accounts so that application code cannot write to the nginx cache directory. Additionally, restrict filesystem permissions on the cache directory so that only the nginx worker user can write to it, preventing unauthorized symlink creation.

The vulnerability was responsibly disclosed by researcher hsntgm via a public pull request (PR #72) to the ngx_cache_purge repository, noting the absence of a SECURITY.md or private reporting channel and recommending the maintainers add a security policy for future reports. The maintainer (denji) merged the fix and released version 3.0.4 the same day. The PR description provides a thorough technical analysis including reproduction steps and test cases (GitHub PR #72).