CVE-2026-42934

What it actually does

This is a heap buffer over-read in the NGINX ngx_http_charset_module that can be reached remotely by unauthenticated HTTP clients when a specific configuration combination is present: charset/source_charset/charset_map processing is enabled and requests are proxied with buffering disabled. Under those conditions, crafted or unlucky request/response processing can cause an NGINX worker process to read beyond the intended heap buffer. The expected impact is limited memory disclosure in HTTP responses or worker process restart/crash; the vulnerability does not indicate direct code execution or data modification.

Why it matters to the business

Organizations using NGINX as an internet-facing reverse proxy or application gateway could experience intermittent worker crashes, reduced availability, or limited leakage of memory from the NGINX worker process if vulnerable charset conversion and unbuffered proxying are configured. The CVSS score and EPSS probability are low, there is no known KEV listing, no known ransomware use, and no public exploit maturity reported, but the issue is still relevant because NGINX is commonly deployed on high-value edge systems and a crash on a front-end proxy can affect customer-facing services.

How an attack unfolds

An attacker first identifies an NGINX endpoint that proxies requests to an upstream application and uses charset conversion through ngx_http_charset_module. The vulnerable path also requires proxy buffering to be disabled, which changes response streaming behavior. The attacker sends unauthenticated HTTP requests that cause NGINX to process proxied response data through the charset module under the vulnerable conditions. If the required runtime conditions align, the worker reads beyond the bounds of a heap buffer. Depending on memory layout and response handling, this may disclose a small amount of adjacent worker memory in the response or cause the worker to terminate and be restarted by the master process. Exploitation appears configuration-dependent and partially constrained by conditions outside the attacker's direct control, reducing reliability.

How to fix it

Upgrade NGINX Open Source or NGINX Plus to a vendor-fixed release when available for the deployed branch. If exact fixed versions are not yet established for the environment, track the official NGINX/F5 advisory for CVE-2026-42934 and deploy the first supported fixed build for the affected product line. As mitigations, remove or avoid the vulnerable configuration combination where feasible: disable unnecessary charset conversion, remove unused charset_map/source_charset directives, avoid applying ngx_http_charset_module processing to proxied responses, or re-enable proxy buffering instead of using proxy_buffering off on affected locations. Ensure deployments are on supported versions because end-of-technical-support versions were not evaluated and may remain vulnerable without patches.

How to confirm the fix worked

Confirm remediation by inventorying all NGINX and NGINX Plus instances and verifying their versions against the vendor advisory/fixed release list. Review active configuration with nginx -T and look for locations or server blocks that combine charset/source_charset/charset_map behavior with proxy_pass and disabled proxy buffering. After patching or changing configuration, run nginx -t, reload NGINX, and confirm the running binary version with nginx -v or nginx -V. Validate that previously exposed routes still function and that error logs no longer show worker process crashes or abnormal upstream/response handling during testing. External scanners may not reliably confirm exploitability because the issue depends on runtime configuration and response conditions.

Typical attack path

1. Reconnaissance: identify internet-facing NGINX or NGINX Plus services acting as reverse proxies.
2. Fingerprint likely NGINX behavior using HTTP headers, error pages, timing, or application routing characteristics.
3. Find routes that return proxied content processed with charset conversion and unbuffered proxy streaming.
4. Send repeated crafted HTTP requests that influence charset processing and response boundaries.
5. Observe responses for anomalous bytes, truncated output, malformed content, or connection resets that suggest worker instability.
6. Repeat requests to attempt limited memory disclosure or trigger worker restarts, causing intermittent availability impact.

How to detect it

To assess prior exploitation, review NGINX access logs, error logs, system journals, container logs, and process supervisor logs for the period since publication and especially after any abnormal availability events. Focus on servers whose configuration includes charset conversion and unbuffered proxying. Look for repeated requests to the same proxied routes followed by worker process exits, segmentation faults, signal 11 events, connection resets, truncated responses, or unusual 5xx spikes. Compare access-log timestamps to error-log worker restarts to identify suspicious request patterns. If full packet capture, WAF logs, CDN logs, or reverse-proxy telemetry is available, look for bursts of unauthenticated requests against charset-converted proxied endpoints that correlate with malformed responses or upstream/client premature close messages. Memory disclosure may not leave a clear server-side artifact, so absence of logs does not prove absence of exploitation.

What your security team should do

• Prioritize internet-facing NGINX and NGINX Plus reverse proxies, API gateways, and load-balancing tiers for inventory and configuration review.
• Search NGINX configurations for the combined presence of charset, source_charset, charset_map, proxy_pass, and proxy_buffering off; treat matching locations as higher priority for patching or mitigation.
• Upgrade affected supported NGINX branches to the vendor-fixed version as soon as it is available and remove end-of-technical-support builds from production.
• If immediate patching is not possible, re-enable proxy buffering or disable charset conversion on proxied routes where business functionality allows.
• Monitor NGINX error logs and service supervisors for worker process crashes, segmentation faults, abnormal restarts, or unexplained connection resets on affected routes.
• Because EPSS is low and there is no KEV or known ransomware association, prioritize based on exposure and configuration match rather than treating every NGINX deployment as equally urgent.