CVE-2026-48142

What it actually does

The vulnerability is a heap buffer over-read in NGINX worker processes within the ngx_http_charset_module. It is reachable only when NGINX serves or proxies content through a location block configured with both `source_charset utf-8;` and a `charset` conversion directive, such as `charset koi8-r;`. A remote unauthenticated requester can trigger the vulnerable character-set conversion path under additional content-dependent conditions, potentially causing the worker to read beyond an allocated heap buffer. The practical technical outcomes are limited memory disclosure in responses or worker process termination and restart; integrity impact is not expected.

Why it matters to the business

Affected internet-facing NGINX deployments may leak small amounts of process memory or experience worker restarts when serving specific charset-converted responses. The CVSS score is moderate, EPSS is currently low, it is not in CISA KEV, and there is no known public exploit maturity in the provided data, so urgency is lower than for actively exploited remote code execution issues. However, NGINX is often deployed at critical application edges, ingress layers, gateways, and WAF-adjacent paths, so even limited disclosure or repeated worker crashes can create operational risk, expose sensitive in-memory fragments, and reduce service reliability if vulnerable charset configurations are present.

How an attack unfolds

An attacker first identifies an NGINX endpoint that serves or proxies responses using the charset filter module. The vulnerable path requires a configuration where a location uses `source_charset utf-8;` together with a target `charset` directive. The attacker then sends unauthenticated HTTP requests for content that causes NGINX to perform the affected character-set conversion. If the necessary response characteristics are present, the worker process performs an out-of-bounds heap read. Depending on memory layout and response behavior, the attacker may receive limited unintended memory contents or cause the worker handling the request to crash and be restarted by the NGINX master process. Exploitation is constrained by configuration and content conditions, which is consistent with the high attack complexity and low EPSS value.

How to fix it

Upgrade affected NGINX Open Source, NGINX Plus, and F5 NGINX-based products to vendor-fixed releases as soon as they are available for the specific product line in use. Because no exact fixed versions were provided in the input, use the official F5/NGINX advisory and package repositories to identify the corrected version for each affected product. As a mitigation, review NGINX configurations and remove unnecessary charset conversion, especially combinations of `source_charset utf-8;` and a target `charset` directive inside the same applicable `location`, `server`, or inherited context. If charset conversion is required, restrict exposure of affected locations where feasible, reduce access to trusted networks, and consider serving pre-converted content rather than relying on runtime conversion. Restart or reload NGINX only after configuration changes have been validated with `nginx -t`. Products that are End of Technical Support may not be evaluated or patched and should be upgraded to supported releases.

How to confirm the fix worked

Confirm exposure by inventorying NGINX Open Source, NGINX Plus, NGINX Ingress Controller, NGINX Gateway Fabric, NGINX Instance Manager, F5 WAF integrations, and other affected F5 NGINX-based deployments. Check the running version with commands such as `nginx -v` or package-manager inventory and compare it with the vendor advisory for this vulnerability. Review active configuration, including included files, generated ingress templates, and inherited `http`, `server`, and `location` contexts, for simultaneous use of `source_charset utf-8;` and `charset ...;`. Run `nginx -T` in a safe administrative context to inspect the fully rendered configuration. After patching or mitigating, verify that the vulnerable directive combination is removed or that the installed package is at a fixed vendor release, then perform a configuration test with `nginx -t` and monitor error logs for absence of worker crashes under normal traffic.

Typical attack path

1. Identify public NGINX, NGINX Plus, ingress, gateway, WAF, or related F5 NGINX-based endpoints.
2. Probe application paths that return text content and may perform character-set conversion.
3. Send crafted or repeated unauthenticated HTTP requests to paths handled by a location block using both `source_charset utf-8;` and a `charset` directive.
4. Trigger the ngx_http_charset_module conversion logic under vulnerable content conditions.
5. Observe abnormal responses, leaked memory fragments, connection resets, HTTP 5xx responses, or NGINX worker restarts.
6. Repeat requests to attempt limited memory disclosure or cause intermittent service degradation.

How to detect it

Look for evidence of exploitation or attempted exploitation in NGINX access logs, NGINX error logs, system logs, container logs, Kubernetes events, and crash reporting telemetry. Focus on endpoints served by locations using charset conversion, especially those with `source_charset utf-8;` and another `charset` value. In access logs, look for repeated unauthenticated requests to text-serving paths followed by connection resets, truncated responses, unusual response sizes, or bursts of HTTP 500/502/503/504 responses. In error logs and host telemetry, look for worker process crashes, segmentation faults, core dumps, abnormal worker exits, or rapid worker respawns. In containerized deployments, review pod restarts, OOM/crash-loop events, and controller logs around suspicious request times. Because the vulnerability does not have a stable public exploit string in the provided data and exploitation depends on content and configuration, detection should correlate suspicious requests with worker instability rather than rely on a single request signature.

• source_charset utf-8;
• charset koi8-r;
• ngx_http_charset_module
• worker process exited on signal 11
• segmentation fault
• segfault
• core dumped
• worker process
• upstream prematurely closed connection
• recv() failed
• connect() failed (111: Connection refused) while connecting to upstream
• HTTP/1.1" 500
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• CrashLoopBackOff
• nginx: [emerg]
• nginx -T

What your security team should do

• Prioritize inventory of internet-facing NGINX and F5 NGINX-based services to determine whether the charset module and vulnerable directive combination are in use.
• Patch to vendor-fixed versions once available for the deployed product and distribution channel; replace unsupported End-of-Technical-Support versions with supported releases.
• Before patching, mitigate by removing unnecessary `source_charset utf-8;` plus `charset` conversion combinations from exposed locations where business functionality allows.
• Increase monitoring on exposed NGINX services for worker crashes, segmentation faults, abnormal 5xx spikes, and unusual repeated requests to text/content-conversion endpoints.
• Review access logs and error logs from the period since publication for signs of probing or instability on paths using charset conversion.
• For Kubernetes ingress or gateway deployments, review controller-generated NGINX configuration as well as user annotations, ConfigMaps, and templates that may enable charset behavior.
• Treat any confirmed memory disclosure as a potential sensitive data exposure event and follow incident response procedures, including log preservation and assessment of secrets that may have been resident in process memory.