F5 Security Updates Patch High-Risk NGINX Open Source Flaws: What Changed and How to Protect Systems

F5 has released security updates to address multiple high-severity vulnerabilities affecting NGINX Open Source. The most urgent items include issues that can lead to denial of service, and at least one condition that can escalate to remote code execution in specific configurations. Organizations running NGINX components (including related F5 and NGINX offerings) are advised to review affected versions and apply upgrades promptly.

Summary of the patched vulnerabilities

The advisory highlights two key vulnerabilities impacting NGINX Open Source, each tied to a particular request processing module. The vulnerabilities can be exploited remotely without authentication when specific trigger conditions are present.

CVE-2026-42945: Heap buffer overflow (critical)

This vulnerability is classified as a critical issue with a CVSS v4 score of 9.2. It is a heap buffer overflow that may cause worker process crashes (denial of service) and can, under certain circumstances, enable remote code execution.

Primary location: ngx_http_rewrite_module

Risk impact: worker crashes (DoS) and potential remote code execution (RCE) depending on exploitability in the target environment.

Notable trigger conditions:

• A rewrite directive followed by another rewrite, an if, or a set.
• Use of an unnamed PCRE capture such as $1 and similar numeric backreferences.
• A replacement string that includes a question mark character (?).

Affected versions: NGINX Open Source 0.6.27 through 1.30.0

Fixed in: 1.30.1 and 1.31.0

CVE-2026-42946: Buffer overread (DoS and potential information exposure)

This issue is associated with a buffer overread that can lead to memory handling problems. The impact includes worker crashes (DoS) and may allow an attacker to access sensitive memory contents in some cases.

Primary location: ngx_http_scgi_module and ngx_http_uwsgi_module

Affected versions: NGINX Open Source 0.8.42 through 1.30.0

Fixed in: 1.30.1+ and 1.31.0+

Additional context from the same security batch

Alongside the two highlighted issues, the same security wave included other disclosed CVEs (for example, CVE-2026-42530 and CVE-2026-42055). Some entries emphasize memory safety bugs, including a use-after-free scenario in ngx_http_v3_module that could be triggered remotely under specific conditions. Even when a headline issue is the primary concern, the safest approach is to treat the entire advisory as a reason to upgrade the affected NGINX version lines.

Which products and deployments may be impacted

F5 notes that the advisory coverage extends beyond NGINX Open Source. Depending on how infrastructure is deployed, affected releases may include:

• NGINX Plus (noted as R32 through R36 in the reference)
• NGINX Ingress Controller
• NGINX Gateway Fabric
• NGINX App Protect

Recommended actions to reduce risk

Mitigation steps should focus on both version upgrades and configuration hardening, especially where ngx_http_rewrite_module behavior is relevant.

1) Upgrade NGINX Open Source immediately

The primary and most reliable remediation is to upgrade to one of the fixed versions referenced by the advisory:

• NGINX Open Source 1.30.1
• NGINX Open Source 1.31.0

Upgrades should be validated in staging first, then rolled out to production with an appropriate change management process, especially for systems with complex rewrite logic or SCGI/UWSGI usage.

2) Review rewrite rules for the CVE-2026-42945 trigger pattern

If upgrading is delayed, immediate configuration review can reduce exposure for the heap buffer overflow issue. Particular attention should be paid to rewrite directives that involve numeric (unnamed) PCRE captures.

Specific guidance from the reference: reduce reliance on unnamed capture backreferences such as $1, $2, and similar, and prefer named PCRE captures (for example, $foo), while also examining replacement strings for the presence of a ? character in contexts described by the trigger conditions.

3) Validate whether SCGI and UWSGI modules are in use

For CVE-2026-42946, systems using SCGI or UWSGI request handling should be treated as higher priority. Even if those modules are not intended for external exposure, verifying whether they are enabled and reachable through request paths helps ensure that memory-handling edge cases are addressed by the upgrade.

4) Confirm versions across all nodes and artifacts

Large deployments often contain multiple NGINX instances across fleets, containers, and control-plane managed components. Remediation should include:

• Inventory of running NGINX versions
• Updates to container base images and build artifacts
• Rollout updates to ingress controllers and gateway components

Why these bugs matter for security teams

Memory corruption vulnerabilities in request processing paths are particularly dangerous because they can be exercised through crafted network traffic. When an exploit chain becomes possible, the attacker may move from crashing workers to executing code or extracting sensitive information. The presence of conditions tied to rewrite directives means that security outcomes can vary significantly based on application routing and configuration details.

Bottom line: treat the referenced fixed versions (NGINX Open Source 1.30.1 or 1.31.0) as the primary mitigation, and use configuration review as a temporary risk reduction measure where immediate upgrades are not feasible.

Quick checklist

• Upgrade NGINX Open Source to 1.30.1 or 1.31.0 based on the advisory.
• Audit rewrite rules for numeric PCRE captures (like $1) and risky replacement patterns that include ?.
• Check for SCGI and UWSGI module usage and ensure fixed builds are deployed everywhere.
• Verify NGINX Plus, ingress controller, and gateway components match the patched release guidance.