## Summary Relyra `1.0.0` and `1.1.0` accept forged SAML signatures because `SignatureValue` was not cryptographically verified before the library returned a successful authentication result. ## Details In `1.0.0` and `1.1.0`, the XMLDSig trust boundary was incomplete. `:public_key.verify` over the exclusive-C14N canonicalized `SignedInfo` was not performed against the configured IdP certificate's public key, `DigestValue` was not recomputed over the canonicalized referenced element, and `canonicalize/2` remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes. ## Impact A forged `SignatureValue` carrying an attacker-controlled `NameID` can be accepted as `{:ok}`. Any relying-party application using Relyra `1.0.0` or `1.1.0` can be logged into as an arbitrary user if it trusts the affected response path. ## Patches Relyra `1.2.0` closes the gap with real exclusive-C14N canonicalization, `:public_key.verify` against the configured IdP certificate's public key, and a constant-time `DigestValue` recompute/compare bound to the exact consumed node on both `verify/4` and `verify_metadata_root/4`. ## Workarounds There is no safe configuration of `1.0.0` or `1.1.0`. Upgrade to `1.2.0` or later. ## Resources - Fix commit `2e45689` (wire real XMLDSig crypto into the candidate arm) - Fix commit `8910200` (close metadata trust bypass, pin over DER) - Regression proof: `test/security/xml/adversarial_crypto_test.exs`, `test/relyra/metadata/auto_refresh_test.exs`, `test/security/ci_gate_integrity_test.exs`
## Summary Relyra `1.0.0` and `1.1.0` accept forged SAML signatures because `SignatureValue` was not cryptographically verified before the library returned a successful authentication result. ## Details In `1.0.0` and `1.1.0`, the XMLDSig trust boundary was incomplete. `:public_key.verify` over the exclusive-C14N canonicalized `SignedInfo` was not performed against the configured IdP certificate's public key, `DigestValue` was not recomputed over the canonicalized referenced element, and `canonicalize/2` remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes. ## Impact A forged `SignatureValue` carrying an attacker-controlled `NameID` can be accepted as `{:ok}`. Any relying-party application using Relyra `1.0.0` or `1.1.0` can be logged into as an arbitrary user if it trusts the affected response path. ## Patches Relyra `1.2.0` closes the gap with real exclusive-C14N canonicalization, `:public_key.verify` against the configured IdP certificate's public key, and a constant-time `DigestValue` recompute/compare bound to the exact consumed node on both `verify/4` and `verify_metadata_root/4`. ## Workarounds There is no safe configuration of `1.0.0` or `1.1.0`. Upgrade to `1.2.0` or later. ## Resources - Fix commit `2e45689` (wire real XMLDSig crypto into the candidate arm) - Fix commit `8910200` (close metadata trust bypass, pin over DER) - Regression proof: `test/security/xml/adversarial_crypto_test.exs`, `test/relyra/metadata/auto_refresh_test.exs`, `test/security/ci_gate_integrity_test.exs`
Update relyra to 1.2.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRelyra SAML SignatureValue not cryptographically verified -> authentication bypass affects relyra (erlang). Severity is critical. ## Summary Relyra `1.0.0` and `1.1.0` accept forged SAML signatures because `SignatureValue` was not cryptographically verified before the library returned a successful authentication result. ## Details In `1.0.0` and `1.1.0`, the XMLDSig trust boundary was incomplete. `:public_key.verify` over the exclusive-C14N canonicalized `SignedInfo` was not performed against the configured IdP certificate's public key, `DigestValue` was not recomputed over the canonicalized referenced element, and `canonicalize/2` remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes. ## Impact A forged `SignatureValue` carrying an attacker-controlled `NameID` can be accepted as `{:ok}`. Any relying-party application using Relyra `1.0.0` or `1.1.0` can be logged into as an arbitrary user if it trusts the affected response path. ## Patches Relyra `1.2.0` closes the gap with real exclusive-C14N canonicalization, `:public_key.verify` against the configured IdP certificate's public key, and a constant-time `DigestValue` recompute/compare bound to the exact consumed node on both `verify/4` and `verify_metadata_root/4`. ## Workarounds There is no safe configuration of `1.0.0` or `1.1.0`. Upgrade to `1.2.0` or later. ## Resources - Fix commit `2e45689` (wire real XMLDSig crypto into the candidate arm) - Fix commit `8910200` (close metadata trust bypass, pin over DER) - Regression proof: `test/security/xml/adversarial_crypto_test.exs`, `test/relyra/metadata/auto_refresh_test.exs`, `test/security/ci_gate_integrity_test.exs`
AI coding agents often install or upgrade packages automatically in erlang. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| relyraerlang | >=1.0.0,<1.2.0 | 1.2.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate relyra to 1.2.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRelyra SAML SignatureValue not cryptographically verified -> authentication bypass affects relyra (erlang). Severity is critical. ## Summary Relyra `1.0.0` and `1.1.0` accept forged SAML signatures because `SignatureValue` was not cryptographically verified before the library returned a successful authentication result. ## Details In `1.0.0` and `1.1.0`, the XMLDSig trust boundary was incomplete. `:public_key.verify` over the exclusive-C14N canonicalized `SignedInfo` was not performed against the configured IdP certificate's public key, `DigestValue` was not recomputed over the canonicalized referenced element, and `canonicalize/2` remained an unused passthrough in the signature-verification path. The result was a structure-only acceptance path where document shape and trust-source rejection could succeed without proving the signature bytes. ## Impact A forged `SignatureValue` carrying an attacker-controlled `NameID` can be accepted as `{:ok}`. Any relying-party application using Relyra `1.0.0` or `1.1.0` can be logged into as an arbitrary user if it trusts the affected response path. ## Patches Relyra `1.2.0` closes the gap with real exclusive-C14N canonicalization, `:public_key.verify` against the configured IdP certificate's public key, and a constant-time `DigestValue` recompute/compare bound to the exact consumed node on both `verify/4` and `verify_metadata_root/4`. ## Workarounds There is no safe configuration of `1.0.0` or `1.1.0`. Upgrade to `1.2.0` or later. ## Resources - Fix commit `2e45689` (wire real XMLDSig crypto into the candidate arm) - Fix commit `8910200` (close metadata trust bypass, pin over DER) - Regression proof: `test/security/xml/adversarial_crypto_test.exs`, `test/relyra/metadata/auto_refresh_test.exs`, `test/security/ci_gate_integrity_test.exs`
AI coding agents often install or upgrade packages automatically in erlang. A critical vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| relyraerlang | >=1.0.0,<1.2.0 | 1.2.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard