CVE-2026-78689 F5 CVE debrief

Who should care

NGINX system administrators, security teams, and developers who use NGINX JavaScript (njs) or QuickJS (qjs) engines should be aware of this vulnerability and take necessary actions to mitigate it. This includes verifying if they are using the affected configuration, applying patches or updates provided by the vendor, implementing compensating controls such as monitoring and exception tracking, restricting access to the NGINX system to only trusted sources, and verifying the integrity of the NGINX configuration. Additionally, they should ensure that the NGINX configuration does not pass externally controlled XML namespace prefix lists to the xml.exclusiveC14n() method. Those responsible for maintaining and securing NGINX systems must prioritize this vulnerability due to its potential impact on system availability and security. This also includes reviewing and updating incident response plans and ensuring that relevant teams are informed and prepared to respond to potential exploitation attempts. Lastly, developers should review the code and configurations for any custom or third-party modules that may interact with NGINX and ensure they are not introducing additional vulnerabilities or exposures. The NGINX community and relevant security forums should also be consulted for additional guidance and best practices in mitigating this vulnerability. Lastly, NGINX users should stay informed about any updates or advisories from the vendor regarding this vulnerability and plan to implement necessary changes in a timely manner. Those who manage NGINX systems should also consider conducting a thorough risk assessment to identify and prioritize which systems are most vulnerable and require immediate attention. This assessment should consider factors such as system criticality, exposure to potential attackers, and the potential impact of a successful exploit. Based on this assessment, they should develop and implement a remediation plan that addresses the most critical vulnerabilities first and ensures that all necessary resources are allocated to mitigate the vulnerability effectively. This plan should also include testing and verification procedures to ensure that the NGIX

Technical summary

The vulnerability in NGINX JavaScript (njs) and QuickJS (qjs) engines is caused by an out-of-bounds write past the end of a heap allocation in the XML module's namespace prefix list parser. This occurs when an affected NGINX configuration passes an externally controlled XML namespace prefix list to the xml.exclusiveC14n() method. Both the njs and QuickJS (qjs) engines are affected. A crafted prefix list causes an out-of-bounds write past the end of a heap allocation. With the njs engine, which is the engine used when the js_engine directive is absent, this corrupts adjacent objects and crashes the NGINX worker. With the QuickJS engine, the same call additionally leaks the prefix list on every invocation, causing worker memory to grow across requests. The official nginxinc/nginx-saml reference implementation is affected during SAML signature verification. It reads InclusiveNamespaces/@PrefixList from an untrusted SAML message and passes it to xml.exclusiveC14n() before the signature has been verified, so a valid SAML signature is not required. A crafted SAML Response, Assertion, LogoutRequest, or LogoutResponse is sufficient.

Defensive priority

This vulnerability allows remote attackers to cause a denial of service on the NGINX system, either through repeatable worker restarts or through worker memory growth or possibly trigger code execution.

Recommended defensive actions

• Inventory NGINX systems and verify if they are using the affected configuration.
• Apply patches or updates provided by the vendor to fix the vulnerability.
• Implement compensating controls such as monitoring and exception tracking.
• Restrict access to the NGINX system to only trusted sources.
• Verify the integrity of the NGINX configuration and ensure it does not pass externally controlled XML namespace prefix lists to the xml.exclusiveC14n() method.

Evidence notes

The vulnerability is in the XML module's namespace prefix list parser, reachable through the xml.exclusiveC14n() method. An unauthenticated remote attacker can trigger it when an affected NGINX configuration passes an externally controlled XML namespace prefix list to that method.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.