What is the CVSS score of CVE-2026-49454?

CVE-2026-49454 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of Relyra are affected by CVE-2026-49454?

Relyra SAML 2.0 Service Provider library versions 1.0.0 and 1.1.0 contain a critical authentication bypass flaw that allows unauthenticated attackers to forge user identities and impersonate any…. A patch is available.

How to fix or mitigate CVE-2026-49454?

Within 24 hours, conduct an inventory to identify all applications and systems using Relyra SAML SP library versions 1.0.0 or 1.1.0, prioritizing production environments and services managing critical business functions or privileged accounts. Within 7 days, upgrade all affected applications to Relyra version 1.2.0 or later through a controlled rollout, including testing SAML authentication flows in staging environments before production deployment. Within 30 days, perform forensic review of access logs and user activity during the vulnerable period to detect any unauthorized authentication or account anomalies, implement enhanced monitoring for SAML assertion validation failures, and confirm all systems are running patched versions.

Relyra CVE-2026-49454

EUVD-2026-37950 CRITICAL

Improper Authentication (CWE-287)

2026-06-18 GitHub_M

GHSA-jv46-xfwm-36j7

Authentication Bypass Relyra

9.1

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

9.1 CRITICAL

Unauthenticated attacker submits a forged SAML Response over the network with no user interaction; full identity impersonation gives high C and I, but no availability loss, so A:N.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Jun 18, 2026 - 23:16 EUVD

Source Code Evidence Fetched

Jun 18, 2026 - 21:50 vuln.today

Analysis Generated

Jun 18, 2026 - 21:50 vuln.today

CVE Published

Jun 18, 2026 - 20:52 cve.org

CRITICAL 9.1

DescriptionCVE.org

Relyra is a strict-by-default SAML 2.0 Service Provider library for Elixir and Phoenix. Versions 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. The XMLDSig trust boundary was incomplete as :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. A forged SignatureValue carrying an attacker-controlled NameID could be accepted as {:ok}. This issue has been fixed in version 1.2.0.

AnalysisAI

Authentication bypass in the Relyra SAML 2.0 Service Provider library for Elixir/Phoenix (versions 1.0.0 and 1.1.0) allows attackers to forge SAML assertions and log in as any user, because the library returned a successful authentication result without ever cryptographically verifying the XMLDSig SignatureValue. A forged SignatureValue carrying an attacker-controlled NameID is accepted as {:ok}, enabling full identity impersonation against any relying-party application. No public exploit identified at time of analysis, and EPSS is low (0.14%), but the flaw is trivially exploitable and marked automatable with total technical impact by CISA's SSVC framework.

Technical ContextAI

Relyra implements the SAML 2.0 SP side, where a relying party must validate that an IdP-issued SAML Response is authentic by verifying its XML Digital Signature (XMLDSig). Correct XMLDSig verification requires three linked steps: canonicalizing the SignedInfo element with exclusive C14N and running :public_key.verify against the configured IdP certificate's public key; recomputing the DigestValue over the canonicalized referenced element; and binding that reference to the exact node consumed downstream. In 1.0.0/1.1.0 none of the cryptographic steps executed - :public_key.verify was never called, DigestValue was never recomputed, and the canonicalize/2 function was a dead passthrough - leaving only structural and trust-source checks. This is a textbook CWE-287 improper authentication: the trust boundary validated document shape but never proved the signature bytes, so a syntactically valid but forged signature passed. The CPE cpe:2.3:a:sztheory:relyra confirms the single affected component, and the 1.2.0 fix (commit 2e45689) wires in real exclusive-C14N canonicalization, :public_key.verify against the configured cert, and a constant-time DigestValue recompute/compare, with commit 8910200 closing an analogous metadata trust bypass pinned over DER.

RemediationAI

Upgrade to Relyra 1.2.0 or later - this is the only safe remediation, and the vendor states explicitly that there is no safe configuration of 1.0.0 or 1.1.0, so no config-level workaround exists. Vendor-released patch: 1.2.0, delivered via fix commits 2e456897af3158c175bb490ce7fc51d6241c8922 (real XMLDSig cryptographic verification) and 8910200 (metadata trust bypass, pinned over DER). After upgrading, confirm your dependency lockfile (mix.lock) resolves relyra to 1.2.0+ and redeploy. As a temporary compensating control until you can patch, disable or gate the SAML/SSO login path in the relying-party application (e.g. take the SAML assertion consumer endpoint offline or restrict it to trusted network sources) so forged responses cannot be submitted; the trade-off is that SSO login is unavailable to users during that window. Review advisory GHSA-jv46-xfwm-36j7 for the vendor's regression proofs (test/security/xml/adversarial_crypto_test.exs) to validate your upgraded build actually rejects forged signatures.