Signed-XML validation bypass in NGINX JavaScript
NGINX JavaScript (njs) versions before 1.0.2 contain an XML attribute interpretation inconsistency affecting both the built-in njs and QuickJS backends. Attributes containing internal entity references are exposed differently by the njs XML module than by libxml2 canonicalization: the $attr$Name getter may return undefined for an explicitly present attribute, while $attrs may return a value derived only from the first attribute child. Consequently, application validation can interpret security-relevant attributes as absent or truncated while XML signature verification succeeds. nginx-saml using the built-in njs backend is a confirmed affected consumer.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
An unauthenticated attacker possessing a suitable genuinely signed XML document can bypass attribute-based security checks. In nginx-saml, affected checks include expiry, Destination, and request correlation, potentially permitting replay or acceptance of a signed response outside its intended context. Exploitation does not permit signature or identity forgery and has no direct availability impact. Exposure is limited to the data plane, with no control-plane exposure.
If you can’t patch tonight, do this now.
Reject DTD-bearing XML before calling xml.parse(). Check the complete document after decoding its accepted input encoding, and prefer parser-level DTD prohibition over a raw byte search for a DOCTYPE declaration. Treat missing security-relevant attributes as validation failures. In nginx-saml, explicitly validate Destination, require request correlation unless unsolicited SSO is intended, and enforce assertion validity, bearer SubjectConfirmation, Recipient, and SubjectConfirmationData InResponseTo checks.
Patch, then assume compromise.
Upgrade NGINX JavaScript to version 1.0.2 or a later fixed release. No fix is listed for the affected 0.x branch; migrate those deployments to a release containing the fix. For packaged or embedded deployments, verify that the installed vendor build incorporates the correction.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
10 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.