CVE-2026-40460

What it actually does

This flaw affects NGINX Plus and NGINX Open Source deployments that enable the HTTP/3 QUIC module. Because QUIC runs over UDP, the vulnerable handling can allow a remote unauthenticated attacker to cause NGINX to treat traffic as if it originated from a different source IP address. If access controls, authorization decisions, geo/IP allowlists, deny lists, logging, abuse controls, or limit_req-style rate limiting depend on the client source IP, those controls may be bypassed or weakened. The vulnerability does not generally imply code execution; the primary impact is incorrect client attribution leading to authorization or rate-limit bypass and potentially reduced availability from abuse traffic.

Why it matters to the business

Organizations using NGINX HTTP/3 as an internet-facing reverse proxy, API gateway, load balancer, or edge server may have IP-based protections bypassed. This can expose restricted paths that were intended only for trusted networks, allow attackers to evade throttling, increase abuse of login/API endpoints, and make incident response harder because logs may attribute requests to the wrong source IP. The public exploitation likelihood is currently low based on EPSS, is not listed in CISA KEV, and has no reported exploit maturity in the provided data; however, the issue has been public for over 90 days, so internet-facing HTTP/3 deployments should still be remediated promptly.

How an attack unfolds

An attacker first identifies an NGINX endpoint that advertises or accepts HTTP/3 over QUIC, commonly through Alt-Svc headers or UDP/443 reachability. They then determine whether the application relies on source IP address for authorization or rate limiting, such as allowlisting admin paths, partner APIs, internal-only resources, or per-IP request throttles. The attacker crafts HTTP/3/QUIC traffic that abuses the vulnerable source-address handling so NGINX attributes the request to a spoofed or otherwise attacker-chosen IP address. If the chosen address is trusted or if the attacker rotates apparent addresses, NGINX may allow access that should have been denied or fail to apply rate limits correctly. Successful exploitation is most valuable where IP address is treated as an authentication or abuse-control boundary rather than merely as a logging attribute.

How to fix it

Upgrade NGINX Plus or NGINX Open Source to a vendor-supported release that contains the fix for this advisory. No exact fixed versions were provided in the input, so use the official NGINX/F5 advisory and package repository metadata to identify the corrected version for the deployed branch. Do not rely on End of Technical Support releases, because they are not evaluated and may not receive fixes. If immediate upgrade is not possible, disable HTTP/3/QUIC support by removing or commenting out QUIC/HTTP/3 listener configuration such as listen ... quic and by stopping advertisement of HTTP/3 through Alt-Svc headers. As a compensating control, avoid using source IP alone for authorization decisions; require strong authentication for sensitive paths, place critical administrative endpoints behind VPN or identity-aware access controls, and enforce rate limiting at an unaffected upstream edge, CDN, WAF, or network control that validates client identity independently of vulnerable QUIC handling.

How to confirm the fix worked

Confirm whether the service is exposed by reviewing NGINX build and configuration for HTTP/3/QUIC support, including nginx -V output for HTTP/3-related modules and configuration entries such as listen 443 quic, http3, or Alt-Svc headers advertising h3. From an external network, verify whether UDP/443 is reachable and whether clients can negotiate HTTP/3 using tools such as curl with HTTP/3 support, browser developer tools, or QUIC-capable scanners. Confirm remediation by verifying the installed NGINX package version is at or above the vendor-fixed version for the relevant branch, restarting/reloading NGINX, and retesting that either the patched version is active or HTTP/3/QUIC is no longer negotiated. Also validate that sensitive routes no longer depend solely on client IP for authorization and that rate limiting behaves consistently when requests are sent over HTTP/1.1, HTTP/2, and HTTP/3.

Typical attack path

1. Discover an internet-facing NGINX service that supports HTTP/3/QUIC, for example via Alt-Svc: h3 advertisement or UDP/443 behavior.
2. Identify endpoints protected by source-IP allowlists, deny lists, geo rules, or per-IP rate limits.
3. Send crafted HTTP/3/QUIC traffic that causes NGINX to associate the request with a spoofed or attacker-selected source IP address.
4. Use a trusted spoofed source IP to reach resources that should only be available to approved networks, or rotate apparent IPs to avoid throttling.
5. Repeat requests against sensitive API, authentication, administrative, or high-value application endpoints while logs may show misleading client attribution.

How to detect it

To determine whether exploitation may have occurred, focus on NGINX access logs, error logs, reverse-proxy logs, WAF/CDN logs, application authentication logs, and API gateway telemetry for HTTP/3 or QUIC traffic. Look for protected or rate-limited endpoints accessed over HTTP/3 from IP addresses that are normally trusted but show unusual user agents, impossible geography, abnormal request timing, unexpected account activity, or mismatches with upstream/CDN records. Compare NGINX-observed client IPs against network-layer telemetry such as firewall, load balancer, flow, or packet-capture records for UDP/443; discrepancies between packet source information and application-layer attribution may indicate spoofing or logging ambiguity. Investigate spikes in requests over HTTP/3 that avoided normal per-IP throttling, repeated 2xx/3xx responses to paths that should be allowlisted, or bursts of authentication/API attempts spread across many apparent source IPs. Because the vulnerability does not inherently require dropping files or launching local processes, host-based IOCs are not expected; detection is primarily behavioral and log-correlation based.

What your security team should do

• Inventory all NGINX Plus and NGINX Open Source instances that expose HTTP/3/QUIC, especially internet-facing reverse proxies, API gateways, and load balancers.
• Prioritize patching or disabling HTTP/3/QUIC on systems that use IP allowlists, geo restrictions, deny rules, or per-IP rate limiting for security decisions.
• Replace IP-only authorization for sensitive endpoints with authenticated and identity-aware controls; treat IP allowlisting as a supplemental control only.
• Review NGINX and application access logs for suspicious HTTP/3 requests to protected paths, especially requests logged as trusted IPs but inconsistent with expected geography, user agent, TLS/QUIC fingerprint, account activity, or request pattern.
• Ensure logging captures protocol, remote address, forwarded headers, request path, status, user agent, request rate, and upstream response codes so anomalous HTTP/3 activity can be investigated.
• If HTTP/3 is not operationally required, disable it until the fleet is confirmed patched and compensating controls are validated.
• Monitor vendor advisories, distribution packages, and security feeds for exact fixed versions and any change in exploit maturity or KEV status.