NGINX JavaScript CVE-2026-18329

Exploitation requires the target NGINX instance to be configured with a js_access directive whose handler (1) performs asynchronous request-body reading (using async/await or callback-based body processing) and (2) lacks a try/catch block that explicitly issues an access denial on exception. NGINX instances not using js_access, or those using only synchronous js_access handlers, or those whose async handlers always issue an explicit deny in all code paths, are not affected. The CVSS PR:N/UI:N confirms no attacker authentication or user interaction is needed, but the non-default async handler configuration is the critical deployment prerequisite. The F5 advisory explicitly states there is no control-plane exposure - only the data plane (incoming HTTP requests through the configured js_access path) is reachable.

F5's CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N) scores 8.8 and reflects that no authentication or user interaction is required from the attacker. However, AC:L likely overstates ease of exploitation: the vulnerable code path requires a deliberate, non-default NGINX configuration using async js_access handlers that lack exception-safe denial logic - a pattern that reduces the exposed population considerably. VC:H accurately captures unauthorized access to confidential protected resources; VI:L reflects the limited integrity bypass (bypassing access controls rather than modifying data). No EPSS data was provided. KEV status is not confirmed. No public POC is identified. F5 explicitly scopes this as a data-plane-only issue with no control-plane exposure, which limits blast radius further. Real-world priority is moderate-to-high for NGINX deployments actively using async js_access scripting for security enforcement; low risk for standard NGINX configurations not using njs access scripting.

An unauthenticated attacker sends a crafted HTTP request - such as one with a malformed or deliberately oversized body - to an NGINX endpoint guarded by an async js_access handler. The malformed input triggers a JavaScript exception during body evaluation before the handler issues an explicit deny, causing the access phase to fail open and forwarding the request to the protected backend. No public POC exists at time of analysis, but the mechanism is straightforward to reproduce against any vulnerable async js_access configuration.