CVE-2026-8711 is a high severity (CVSS 8.1) heap buffer overflow in F5 NGINX JavaScript (njs). It needs a specific setup: js_fetch_proxy set with a client-controlled variable, and a location that calls ngx.fetch(). An unauthenticated request can then crash a worker. Check F5 advisory K000161307 for fixed versions and update.
What's affected
The record names F5 njs and does not list version numbers. The F5 advisory K000161307 holds the affected and fixed versions, and it could not be loaded when this guide was written, so read it for the exact list. The record also notes that software versions which have reached End of Technical Support were not evaluated.
Exposure depends on configuration. Both of these must be true:
- The js_fetch_proxy directive uses at least one variable the client controls, such as one built from a request header, query argument or cookie.
- A location runs njs code that calls ngx.fetch().
Without both, the vulnerable path is not reached.
How to check if you're exposed
Check the installed njs version, then search your configuration for the two conditions.
nginx -V 2>&1 | head -5
nginx -T 2>/dev/null | grep -n "js_fetch_proxy"
nginx -T 2>/dev/null | grep -n "js_content\|js_import"
The first command shows build details, including whether the njs module is compiled in. The second lists every use of js_fetch_proxy. If any of them contains a dollar variable that starts with http_, arg_ or cookie_, a client can influence it. Then open the njs scripts that those locations load and look for ngx.fetch calls.
Also check dynamic modules on disk, since njs can be loaded as a separate module from your distribution package.
What to do now
- Read F5 advisory K000161307 and note the fixed version for your branch.
- Update the njs package or the NGINX build that bundles it.
- Where you cannot update yet, stop building js_fetch_proxy from client-controlled variables. Use a fixed proxy value, or map to a short list of known values.
- Review other njs code that makes outbound requests and confirm it validates its inputs.
- Watch worker restarts in your logs, since the record says the overflow can cause a restart.
Removing the client-controlled variable removes one of the two stated conditions, so it is a sound stopgap, but it is not a fix. Plan the update anyway.
A fixed proxy value is the simplest change. If the proxy genuinely depends on the request, use an NGINX map block to translate a small set of accepted inputs into known values, so that arbitrary client text never reaches the directive.
Why it matters
The weakness is CWE-122 (heap-based buffer overflow). Data from the request ends up in the proxy setting that the fetch operation uses, and the code that handles it writes past the end of a heap buffer. The record says this usually restarts the worker. It adds that code execution is possible where address space layout randomization is off or can be bypassed, which is why the attack complexity is rated high.
The lesson is general: configuration directives that accept variables turn request data into configuration. Treat each one as an input that needs validation.
The record does not mark this CVE as known exploited, and it is not in the CISA KEV list.
Try it yourself
Only some servers run the exact configuration this bug needs. A check that asks whether the vulnerable path is reachable helps you rank the work.
Click through it at your own pace, or open it full screen.
Quick check
Does every NGINX server need the fix?
Only those with the njs module and the configuration described above are in the vulnerable path. Still, update when F5 publishes the fixed version for your branch.
How do I tell if a variable is client-controlled?
Variables that begin with http_, arg_ or cookie_ come straight from the request, so a client can set them.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Listed in the record but not readable when this guide was written, so confirm details there:
Last reviewed: 19 October 2026.
