CVE-2026-60005: 
NGINX vulnerability analysis and mitigation

CVE-2026-60005 is a use of uninitialized resource vulnerability (CWE-908) in the ngx_http_slice_module module of NGINX Plus and NGINX Open Source. When the slice directive and unnamed regex captures are configured, or when a background cache update occurs, unauthenticated remote attackers can send crafted requests that trigger uninitialized memory access in the NGINX worker process, leading to limited memory disclosure or a worker process restart. Affected versions include NGINX Open Source 1.15.8 through 1.30.3 and 1.31.2, and NGINX Plus R33 through R36 (before R36 P7) and 37.0.0.1 through 37.0.3.0. The vulnerability was published on July 15, 2026, with a CVSS v3.1 score of 8.2 (High) and a CVSS v4.0 score of 8.8 (High) (GitHub Advisory, F5 Advisory).

The root cause is CWE-908 (Use of Uninitialized Resource): the ngx_http_slice_module fails to properly initialize memory under two specific conditions — when the slice directive is used alongside unnamed regex captures in location matching, or during background cache update operations. In these scenarios, the NGINX worker process may access uninitialized memory regions, which an attacker can influence by sending specially crafted HTTP requests. No authentication or user interaction is required, and the attack is network-accessible with low complexity. The module is not compiled into NGINX by default and must be explicitly enabled with the --with-http_slice_module configuration parameter, which limits the attack surface to deployments that have opted into this feature (GitHub Advisory, F5 Advisory).

Successful exploitation can result in two primary outcomes: limited disclosure of NGINX worker process memory contents (confidentiality impact) and denial of service via worker process restart (high availability impact). There is no integrity impact and no control plane exposure — this is strictly a data plane issue. Memory disclosure is described as limited and not fully attacker-controlled, but could potentially expose sensitive data processed by the worker (e.g., request headers, cached content fragments). The worker process restart causes service disruption but does not result in persistent system compromise or lateral movement (GitHub Advisory, F5 Advisory).

There is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation as of the time of publication (GitHub Advisory). The vulnerability is automatable (no user interaction required) and exploitable by unauthenticated network attackers, but requires the non-default ngx_http_slice_module to be enabled. The EPSS score is approximately 0.61–0.71%, indicating a low near-term exploitation probability. No threat actor attribution has been reported, and the CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify NGINX instances running with the ngx_http_slice_module enabled (compiled with --with-http_slice_module) and configured with the slice directive alongside unnamed regex captures in location blocks, or with background cache update (proxy_cache_background_update on) enabled.
2. Fingerprint target: Confirm the NGINX version is within the affected range (Open Source 1.15.8–1.30.3 or 1.31.2; Plus R33–R36 before P7 or 37.0.0.1–37.0.3.0) via server response headers or version-specific behavior.
3. Craft malicious request: Send HTTP requests targeting endpoints served by the vulnerable slice/cache configuration. The request should be designed to trigger the uninitialized memory access path — for example, by requesting a resource that activates the slice module's range-splitting logic during a background cache update cycle.
4. Observe response: Analyze HTTP responses for leaked memory content embedded in response bodies or headers, or monitor for worker process restarts (e.g., connection resets, brief service interruptions) as a denial-of-service indicator.
5. Repeat/automate: Since no authentication is required and the attack is network-accessible, the process can be automated to repeatedly trigger memory disclosure or service disruption (GitHub Advisory, F5 Advisory).

• Network: Unusual or repeated HTTP requests targeting endpoints served by slice-configured location blocks; high volume of range requests (e.g., Range: bytes=... headers) from a single source IP against cached resources.
• Logs: NGINX error logs (error.log) showing worker process crashes or restarts (e.g., worker process XXXX exited on signal 11); access logs with repeated requests to the same sliced resource endpoint from external IPs.
• Process: Unexpected NGINX worker process restarts visible in system logs (/var/log/syslog, journalctl) or process monitoring; NGINX master process spawning replacement workers more frequently than normal.
• File System: No known file-based artifacts associated with this vulnerability, as exploitation is entirely in-memory and network-based.

F5 has released patched versions: NGINX Open Source 1.30.4 and 1.31.3, and NGINX Plus R36 P7 and 37.0.3.1. Organizations should upgrade to these versions as the primary remediation (F5 Advisory, GitHub Advisory). As a workaround, if the ngx_http_slice_module is not required, recompile NGINX without the --with-http_slice_module parameter. Additionally, if the module is needed but the vulnerable configuration (unnamed regex captures with slice directive, or background cache updates) can be avoided, reconfiguring to eliminate those combinations will mitigate the risk. Network access controls limiting who can send requests to NGINX instances provide additional defense-in-depth.

The vulnerability was covered alongside two other NGINX flaws (CVE-2026-42533 and CVE-2026-56434) in a broader F5 patch release, with multiple security news outlets reporting on the combined advisory (CyberSecurityNews, GBHackers). Coverage emphasized that F5 patched multiple NGINX vulnerabilities simultaneously, with some outlets noting the potential for heap buffer overflow and code execution in the related CVEs. The Beazley Security Lab published an advisory covering all three NGINX CVEs together (Beazley Security). Community reaction on Mastodon and InfoSec.Exchange noted the patch release without significant alarm, consistent with the limited exploitation potential and non-default module requirement.