CVE-2026-108981
3.6LowPublished 12 Oct 2026 · NVD status: Deferred · AI triage by gemini-3.8-flash
- Attack vector
- Local
- Complexity
- High
- Privileges needed
- Low
- User interaction
- None
- Impact
- Limited impact
- Weakness
- CWE-61
Impact
A local attacker sharing the nginx user account can delete arbitrary files on the system by placing symlinks inside the cache path. They need existing local file write access to the cache directory, such as through a co-hosted application like WordPress.
Root cause
ngx_cache_purge uses ngx_walk_tree() and stat() during purge operations, which follow symlinks rather than rejecting them.
Affected systems
ngx_cache_purge versions before 3.0.4
CVSS v3.1 · CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L
Fix & remediation
Upgrade ngx_cache_purge to version 3.0.4 or later. If patching immediately is not possible, run the upstream application and nginx under separate system users, and restrict permissions so the application cannot write into the nginx cache directory.
$ nginx -V 2>&1 | grep -o 'ngx_cache_purge[^ ]*'AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
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.)