Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify Rocket.Chat with SAML SSO enabled
-
DeliveryObtain a valid IdP-signed SAML document
-
ExploitWrap it, injecting forged admin identity attributes
-
ExecutionPOST crafted response to SAML ACS endpoint
-
PersistSignature validates but is unbound to forged data
-
ImpactAuthenticated session as arbitrary/admin user
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK
2 techniques across 2 tactics: Defense Evasion, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the target Rocket.Chat instance to have SAML SSO enabled and configured to trust an external IdP certificate; the attacker must possess at least one document carrying a valid signature made by that trusted IdP certificate to reuse as the signature donor. Given CVSS PR:N/UI:N, no attacker authentication or user interaction is needed once a valid signed sample is available. Limiting factors: instances without SAML enabled are not affected at all, and obtaining a genuinely IdP-signed sample is the practical prerequisite (an attacker's own legitimate SAML login typically satisfies this). Affected versions are all releases below the per-branch fixes (e.g., <8.7.0, <8.6.1 ... <7.10.14). |
| Impact | This is a genuine high-priority issue, not an inflated CVSS number. The supplied CVSS 3.0 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) is internally consistent with the description: SAML endpoints are network-reachable, no attacker authentication is needed (the whole point is impersonating any account), and the attacker only needs one valid IdP-signed document as a signature donor plus the ability to craft the wrapper - low complexity. Classic SAML XSW bypasses are highly reliable and scriptable once a signed sample is obtained, so real-world exploitability is high where SAML SSO is enabled. No EPSS score, KEV status, or SSVC decision data was provided, so exploitation-probability and automatable ratings cannot be quantified from the input; the absence of KEV means active exploitation is not confirmed. The main real-world limiter is configuration scope: only deployments that have SAML SSO enabled and trust an external IdP are affected - instances using only password or OAuth login are not exposed. |
| Exploit ScenarioDerived | An attacker obtains any single SAML response legitimately signed by the target's trusted IdP certificate - for example their own valid login, an intercepted assertion, or a leaked sample - and wraps it so the genuine signature stays valid while forged NameID/attribute values identifying an admin account are placed where Rocket.Chat reads identity. Submitting this crafted document to the SAML ACS endpoint authenticates the attacker as the impersonated administrator without any password. No weaponized exploit is public, but the patch's regression tests (samlResponseNestedInWrapper) demonstrate the exact wrapping technique. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 30, 2026
Authentication bypass in Rocket.Chat's SAML SSO before 8.7.0 (and the 8.6.1, 8.5.2, 8.4.5, 8.3.7, 8.2.7, 8.1.7, 8.0.8, 7.10.14 branch fixes) lets a remote unauthenticated attacker log in as any user, including administrators, via an XML Signature Wrapping attack. The parser validated that a signature was cryptographically correct against the trusted IdP certificate but never bound that signature to the samlp:Response/saml:Assertion actually processed, so forged identity attributes wrapped alongside a genuine signature were accepted. There is no public exploit identified at time of analysis, but a HackerOne report and an upstream patch with signature-scope regression tests exist; EPSS/KEV data was not provided.
RemediationAI
Vendor-released patch: upgrade to the fixed release on your branch - 8.7.0, 8.6.1, 8.5.2, 8.4.5, 8.3.7, 8.2.7, 8.1.7, 8.0.8, or 7.10.14 (whichever is the next patched version at or above your current line), as delivered in the security hotfix of Rocket.Chat PR #41233 (https://github.com/RocketChat/Rocket.Chat/pull/41233); see also https://docs.rocket.chat/docs/security-fixes-and-updates. If you cannot patch immediately, the most effective compensating control is to disable SAML SSO in Admin > Settings > SAML and fall back to another authentication method (password/OAuth/LDAP), which fully closes the vector at the cost of removing SAML login for users. Where SAML must remain enabled, restrict network access to the SAML validation endpoints (e.g., /_saml/validate) to trusted IdP source ranges via a reverse proxy or firewall and monitor authentication logs for logins that do not correlate with expected IdP sessions - note this reduces but does not eliminate risk since the attacker only needs one valid signed assertion. Prioritize patching over workarounds.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in Rocket.Chat's Meteor SAML accounts module (apps/meteor/app/meteor-accounts-saml/server/lib/parsers/Response.ts), which parses SAML 2.0 assertions using the xml-crypto library. The root cause is CWE-287 (Improper Authentication) manifesting specifically as XML Signature Wrapping (XSW): xml-crypto confirmed the signature was mathematically valid over *some* referenced element, but the application never checked that the signed ds:Reference URI matched the ID of the Response/Assertion whose attributes it then trusted. An attacker can therefore relocate a legitimately signed element and inject an unsigned sibling containing arbitrary NameID/attribute values. The patch adds getElementId() and signatureCoversElement() to require that every signature reference URI equals the ID of the processed element, and additionally enforces that the SAML Response is the document root ('response !== doc.documentElement' rejection) to block wrapper-envelope tricks.
Know when Rocket Chat gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Network-facing SAML endpoint, no auth or interaction needed once a signed sample is held, yielding full impersonation of any account including admin - total C/I/A impact.
Primary rating from Vendor (hackerone).
CVSS VectorVendor: hackerone
Lifecycle Timeline
2DescriptionCVE.org
Rocket.Chat's SAML SSO before versions 8.7.0, 8.6.1, 8.5.2, 8.4.5, 8.3.7, 8.2.7, 8.1.7, 8.0.8, and 7.10.14 verified XML signatures but did not bind the validated signature to samlp:Response / saml:Assertion. An attacker could submit a wrapped document carrying forged identity attributes alongside any valid signature made by the trusted IdP certificate, and log in as an arbitrary user.
Executive ViewAI
Rocket.Chat versions prior to 8.7.0 contain a critical SAML authentication bypass that allows unauthenticated attackers to gain administrative access by manipulating XML signatures. Any organization using affected Rocket.Chat instances with SAML SSO enabled faces immediate risk of unauthorized account takeover, including access to administrative controls, chat history, and integrated systems.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Rocket Chat
View allA sanitization vulnerability exists in Rocket.Chat server versions <3.13.2, <3.12.4, <3.11.4 that allowed queries to an
A improper input sanitization vulnerability exists in Rocket.Chat server 3.11, 3.12 & 3.13 that could lead to unauthenti
A improper authentication vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 that allowed two factor authentic
A SQL injection vulnerability exists in Rocket.Chat <v3.18.6, <v4.4.4 and <v4.7.3 which can allow an attacker to retriev
A Server-Side Request Forgery (SSRF) affects Rocket.Chat's Twilio webhook endpoint before version 6.10.1. Rated high sev
Rocket.Chat versions prior to 6.12.0 expose the OAuth applications API endpoint to any authenticated user, allowing disc
An information disclosure vulnerability exists in the Rocket.Chat server fixed v3.13, v3.12.2 & v3.11.3 that allowed ema
An improper authentication vulnerability exists in Rocket.Chat Mobile App <4.14.1.22788 that allowed an attacker with ph
A cleartext transmission of sensitive information exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 relating to Oauth token
An information disclosure vulnerability exists in Rocket.Chat <v5 due to the getUserMentionsByChannel meteor server meth
Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript. Rated medium severity
A blind self XSS vulnerability exists in RocketChat LiveChat <v1.9 that could allow an attacker to trick a victim pastin
EUVD-2026-51023
GHSA-f3wj-pr2w-q3fm
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB