CVE-2026-42946

What it actually does

The flaw affects NGINX configurations that proxy requests to SCGI or uWSGI upstreams using ngx_http_scgi_module or ngx_http_uwsgi_module. If an attacker can act as a man-in-the-middle between NGINX and the configured upstream server, or otherwise control the upstream response stream, crafted responses may trigger excessive memory allocation or an over-read in the NGINX worker process. The likely technical outcomes are disclosure of worker-process memory contents and worker-process restart/crash, with confidentiality impact higher than availability impact. The issue is not directly exploitable by a normal unauthenticated internet client unless the attacker can influence or intercept upstream SCGI/uWSGI responses.

Why it matters to the business

Organizations using NGINX, NGINX Plus, NGINX Ingress Controller, NGINX Gateway Fabric, NGINX App Protect, or related F5 NGINX products with SCGI or uWSGI upstreams may be exposed to leakage of sensitive in-memory data such as session material, request data, headers, cookies, credentials, or application secrets handled by the worker process. Exploitation can also cause worker restarts, which may create intermittent service disruption. The current EPSS score is low and stable, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, but the risk is higher in architectures where upstream traffic is unencrypted, crosses untrusted networks, or where upstream services can be compromised.

How an attack unfolds

An attacker first needs a path to control or tamper with responses sent from an SCGI or uWSGI upstream to NGINX. This may occur through network-level MITM access, DNS/routing manipulation, compromise of an upstream application server, or control of a service that NGINX proxies to using scgi_pass or uwsgi_pass. The attacker then returns specially crafted upstream response data designed to confuse the affected SCGI/uWSGI response handling logic. When the NGINX worker parses that response, it may allocate excessive memory or read beyond the intended buffer. Depending on runtime conditions, the attacker may receive unintended memory contents in a proxied response or trigger a worker crash/restart. Because exploitation requires upstream-response control, internet-facing NGINX servers are primarily at risk when the upstream channel is not strongly trusted or protected.

How to fix it

Upgrade affected F5 NGINX and NGINX product components to vendor-supported fixed releases as soon as they are available for the deployed product line. Because no exact fixed versions were provided in the input, administrators should consult the relevant F5/NGINX advisory for the specific product and release train, and avoid relying on end-of-technical-support versions. As compensating controls, remove unused scgi_pass and uwsgi_pass configurations, restrict upstream connectivity to trusted networks, use authenticated and encrypted transport where supported, prevent untrusted network paths between NGINX and upstream services, pin upstream destinations to trusted addresses, harden DNS/routing controls, and monitor/restart worker processes under supervision. If SCGI/uWSGI is not required, disable or remove those proxy paths entirely.

How to confirm the fix worked

Confirm exposure by reviewing NGINX configuration for active scgi_pass or uwsgi_pass directives, including included configuration files and generated ingress/controller configuration. Verify that deployed NGINX/F5 NGINX component versions match a vendor-fixed or non-affected release for the specific product. Confirm that SCGI/uWSGI upstream traffic does not traverse untrusted networks and cannot be intercepted or modified by unauthorized parties. After remediation, run configuration tests such as nginx -t, reload the service, verify application functionality through affected routes, and monitor error logs for worker crashes, abnormal memory growth, or upstream parsing errors. Where possible, perform packet inspection or mTLS/TLS validation to ensure upstream responses cannot be tampered with in transit.

Typical attack path

1. Identify an NGINX deployment using SCGI or uWSGI proxying, typically via application behavior, exposed headers, error behavior, or access to configuration information.
2. Gain the ability to intercept, spoof, or control responses from the configured SCGI or uWSGI upstream server.
3. Send a client request through NGINX that causes NGINX to contact the attacker-controlled or attacker-manipulated upstream.
4. Return a crafted SCGI/uWSGI response intended to trigger excessive allocation or an out-of-bounds read in the NGINX worker process.
5. Observe whether the proxied response contains leaked memory data or whether NGINX workers restart unexpectedly.
6. Repeat against selected request paths to harvest process memory fragments or cause intermittent service degradation.

How to detect it

There is no known unique network signature or public exploit artifact for this vulnerability based on the provided information. Detection should focus on exposure plus behavioral evidence: NGINX configurations containing scgi_pass or uwsgi_pass, unexpected worker-process exits or restarts, segmentation faults, abnormal resident memory growth, unusually large or malformed upstream responses, and anomalous responses returned to clients that contain fragments of unrelated request data, headers, cookies, or binary memory. Review NGINX error logs, access logs, process manager logs such as systemd or container runtime events, kernel logs for OOM or segfault messages, upstream application logs, reverse-proxy telemetry, and network captures between NGINX and SCGI/uWSGI upstreams. Pay special attention to time windows where an upstream host changed unexpectedly, DNS answers changed, routing paths shifted, TLS was absent or failed open, or an upstream service was compromised. Because exploitation requires control of upstream responses, correlate NGINX anomalies with upstream host authentication events, deployment changes, container image changes, service discovery updates, and network MITM indicators.

• scgi_pass
• uwsgi_pass
• worker process
• exited on signal 11
• segfault
• Out of memory
• cannot allocate memory
• upstream sent too big header
• upstream prematurely closed connection
• while reading response header from upstream
• while reading upstream

What your security team should do

• Inventory all NGINX and F5 NGINX deployments and identify any use of scgi_pass or uwsgi_pass.
• Prioritize remediation for deployments where SCGI/uWSGI upstream traffic crosses shared, untrusted, container overlay, cloud, or multi-tenant networks.
• Upgrade to vendor-fixed supported versions when available; do not defer remediation on end-of-technical-support builds.
• Remove unused SCGI/uWSGI proxy locations and replace legacy upstream integrations where feasible.
• Encrypt, authenticate, or isolate traffic between NGINX and SCGI/uWSGI upstream services.
• Review recent NGINX error logs, process supervision logs, and system logs for unexplained worker restarts or memory-related failures.
• Harden upstream service ownership and deployment pipelines because compromise of an upstream server can become a practical exploitation path.
• Add monitoring for sudden NGINX worker memory growth, repeated reloads/restarts, segmentation faults, or anomalous upstream response sizes.