TL;DR: NGINX JavaScript js_fetch_proxy heap buffer overflow, classified as CWE-122 (Heap-based Buffer Overflow). Vendor (F5 SIRT): 8.1 HIGH. NVD: 9.8 CRITICAL. The NVD score reflects worst-case network attack assumptions; the vendor score reflects observed exploitation complexity. Patch on the higher score, hunt on the worst-case vector.
What This Vulnerability Is
NGINX JavaScript has a vulnerability when the js_fetch_proxy directive is configured with at least one client-controlled NGINX variable (for example, $http_*, $arg_*, $cookie_*) and a location invoking the ngx.fetch() operation from NGINX JavaScript. An unauthenticated attacker can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.
The National Vulnerability Database assigned this issue a CVSS base score of 9.8, placing it in the CRITICAL category. The identifier CVE-2026-8711 was published on 19 May 2026. The weakness class is CWE-122 (Heap-based Buffer Overflow).
- CVE Identifier
- CVE-2026-8711
- CVSS Base Score
- 9.8 / 10.0 (CRITICAL)
- CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H- Weakness Class
- CWE-122 (Heap-based Buffer Overflow)
- Published
- 19 May 2026
- Vendor Advisory
- https://my.f5.com/manage/s/article/K000161307
- NVD Entry
- https://nvd.nist.gov/vuln/detail/CVE-2026-8711
How a Sherlock Forensic Examiner Triages a Suspected NGINX Worker Compromise
If you suspect this vulnerability has been exploited in your environment, the first artifact a Sherlock forensic examiner pulls is the NGINX error log. The signature is unambiguous: worker process exited on signal 11 (SIGSEGV) or worker process exited on signal 6 (SIGABRT) in /var/log/nginx/error.log, repeated across multiple worker PIDs in a short window. A single SIGSEGV is unremarkable. A cluster aligned with HTTP requests carrying long or unusual client-controlled values in headers, cookies or query parameters routed through a js_fetch_proxy location is the exploitation signature.
The second artifact is the access log. The attacker payload must enter the worker through one of the client-controlled variables that the vulnerable JavaScript handler consumes. Filter /var/log/nginx/access.log for requests in the SIGSEGV window. Pay attention to $http_*, $arg_* and $cookie_* values that are unusually long, contain unprintable bytes (URL-encoded as %00 through %1F or %7F) or carry repeated patterns consistent with heap grooming. Cross-reference the source IP and the User-Agent against your threat intelligence feed.
The third artifact is the worker memory image. If ASLR was disabled or if the attacker was able to bypass ASLR through a separate information disclosure primitive, the heap buffer overflow is a remote code execution path. On Linux systems with core dumps enabled (/proc/sys/kernel/core_pattern set, NGINX worker not running with RLIMIT_CORE at zero), the worker crash will drop a core dump. Preserve the core dump immediately with a SHA-256 hash. Capture process accounting via /var/log/acct/pacct or your auditd configuration: look for child processes spawned from the NGINX worker UID in the SIGSEGV window. Outbound network connections from the NGINX worker UID to unexpected destinations are post-exploitation lateral movement candidates.
Configuration tampering is the fourth artifact. Even if remote code execution did not succeed, an unauthenticated attacker who can crash NGINX workers at will has a denial-of-service primitive. Hash your NGINX configuration files (/etc/nginx/nginx.conf, /etc/nginx/conf.d/*, /etc/nginx/sites-enabled/*) and compare against your last-known-good configuration backup. An attacker who chained this vulnerability with separate code execution would likely modify js_fetch_proxy configuration or related JavaScript files to either pivot deeper or remove the exploitation trace.
Detection Signature
Illustrative Sigma rule for SIEM-based detection. Tune thresholds to your baseline before production deployment.
title: NGINX Worker Crash Signature Pattern CVE-2026-8711
id: cve-2026-8711-nginx-worker-crash
status: experimental
description: Detects clusters of NGINX worker SIGSEGV crashes consistent with CVE-2026-8711 exploitation against js_fetch_proxy.
logsource:
category: webserver
product: nginx
detection:
selection:
Message|contains:
- 'worker process exited on signal 11'
- 'worker process exited on signal 6'
condition: selection | count() by host > 3 within 5m
level: high
What to Do About It
- Apply the vendor patch. Follow the vendor advisory for the current patched version. Patch on the NVD-9.8 worst-case scoring rather than the vendor-reduced scoring; the NVD score reflects the worst-case attacker scenario, which is what your incident response plan should be built around.
- Run the forensic triage above on any system showing the indicator pattern. The forensic angle in this analysis is grounded in primary-source NVD data and Sherlock incident response methodology. If your team lacks the bandwidth, an external incident response engagement closes the gap.
- Subscribe to the CISA Known Exploited Vulnerabilities catalog. The CISA KEV catalog tracks CVEs with confirmed in-the-wild exploitation. Treat additions to the KEV catalog as emergency patch tickets.
- Document your response. Record what you checked, what you patched and what residual risk remains. This matters for compliance and for any incident response activity that follows.