ngx_cache_purge EUVD-2026-97159

Requires that nginx and the served application (e.g., WordPress) run under the SAME OS user account, AND that the attacker can create a symbolic link inside the configured proxy_cache_path directory - which in practice means the attacker already holds code execution or arbitrary file-write as that shared user. A cache purge operation (e.g., a proxy_cache_purge PURGE request, purge_all, or wildcard purge) must then be triggered to walk the cache tree. Limiting factors: local access only (no remote vector), the shared-user deployment is not nginx's default isolation posture, and against version 3.0.4 the only remaining avenue is a TOCTOU race that must be won during the walk. These constraints make opportunistic or remote exploitation impractical.

All exploitation signals point to a genuinely LOW real-world priority. The vendor-supplied CVSS vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L, base 3.6) describes a local, high-complexity, authenticated flaw with only limited integrity and availability impact and no confidentiality impact - consistent with the description, which requires an attacker to already be able to create a symlink inside the cache path (i.e., to already hold code execution as the same user nginx runs as). No EPSS score was provided, there is no CISA KEV listing, and no public exploit was identified at time of analysis, so there is no evidence of active or opportunistic exploitation. The signals are therefore internally consistent rather than conflicting: this is a defense-in-depth hardening fix, not a high-urgency item. Two caveats security teams should note explicitly: (1) the 'Information Disclosure' tag in the metadata conflicts with both the description ('file deletion') and the CVSS C:N - the actual impact is destructive (integrity/availability), not disclosure; and (2) the vendor states that 3.0.4 only fixes the arbitrary-earlier-symlink case and does NOT resolve an applicable TOCTOU race condition, so even patched installations retain a residual, harder-to-win race window - verify this limitation with the vendor before considering the issue fully closed.

An attacker who has already compromised a WordPress (or other) application running under the same OS user as nginx plants a symbolic link (e.g., 'evil -> /var/www') inside the proxy_cache_path directory. When a cache purge operation runs (such as a PURGE request using purge_all), nginx's ngx_walk_tree() stat()s the link, follows it as if it were a real cache subdirectory, and deletes files that live outside the cache. No public exploit code was identified at time of analysis; exploitation requires local same-user access and, against 3.0.4, winning a TOCTOU race.