CVE-2026-100541 in OpenClaw
Summary
by MITRE • 09/26/2026
OpenClaw's Matrix integration (npm package @openclaw/matrix) versions >= 2026.2.2 and < 2026.8.1 lowercase complete Matrix user IDs — including historical localparts and the case-sensitive server-name portion — when deriving the OpenClaw authorization identity. As a result, distinct authenticated Matrix accounts can normalize to the same authorization identity. A Matrix participant controlling a colliding account identifier (a protocol-valid identifier that differs from the configured one only by characters OpenClaw case/Unicode folds; display-name matching is not required) can inherit allowlist, owner-command, exec-approval, or plugin-approval authority configured for another account. The issue is fixed in 2026.8.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in OpenClaw's Matrix integration module represents a critical identity normalization flaw that undermines the fundamental principle of least privilege and access control integrity within the application. Specifically, versions of the @openclaw/matrix npm package ranging from 2026.2.2 up to but not including 2026.8.1 exhibit improper handling of Matrix user identifiers during the authentication process. The core technical defect lies in the case-insensitive normalization of complete Matrix User IDs, which includes both the localpart and the server-name portion of the identifier. In standard Matrix protocol operations, while some components may be case-insensitive for display purposes, the actual unique identification often relies on exact string matching or specific canonicalization rules that preserve case sensitivity to ensure uniqueness. By lowercasing these identifiers indiscriminately before deriving the authorization identity, the system fails to distinguish between distinct accounts that differ only by character casing or Unicode folding properties. This creates a scenario where two different Matrix user IDs can map to the same internal authorization principal, effectively collapsing separate security boundaries into a single shared identity context.
The operational impact of this vulnerability is severe, as it allows for privilege escalation through account collision attacks. A malicious actor who controls a colliding account identifier—one that matches the target victim's configured ID when both are converted to lowercase—can inherit all permissions associated with the victim’s authorization profile. This includes high-privilege capabilities such as allowlist management, execution of owner-level commands, approval for arbitrary code execution via exec functions, and plugin installation or modification approvals. Since display-name matching is not required for this collision to occur, an attacker does not need social engineering success in terms of impersonating a user's visible name; they only need to register or control a Matrix account with the appropriate casing variation. This bypasses standard authentication checks because the system perceives the attacker as the legitimate authorized user based on the flawed normalized identity string rather than verifying strict cryptographic proof against the original case-sensitive identifier.
From an industry standards perspective, this vulnerability aligns closely with CWE-287: Improper Authentication and CWE-693: Protection Mechanism Failure. The root cause is a failure to correctly implement unique user identification during the authentication phase, leading to identity confusion that facilitates unauthorized access. In terms of the MITRE ATT&CK framework, this behavior maps to T1078: Valid Accounts, specifically where an attacker leverages valid credentials but exploits implementation flaws in how those accounts are processed by the application logic to gain elevated privileges. It also touches upon aspects of T1548: Abuse Elevation Control Mechanism, as the attacker abuses the identity normalization mechanism to bypass intended access controls and assume roles reserved for specific users. The lack of case-sensitive verification constitutes a significant deviation from secure coding practices that mandate strict equality checks for sensitive identifiers unless explicitly documented otherwise by the underlying protocol specifications with appropriate safeguards against collision attacks.
Mitigation strategies must prioritize immediate patching as well as architectural review of identity handling processes. The primary remediation is to upgrade the @openclaw/matrix package to version 2026.8.1 or later, where this normalization flaw has been corrected to ensure that user identities are handled with appropriate case sensitivity and uniqueness guarantees. For organizations unable to patch immediately due to dependency constraints, temporary mitigations should include enforcing strict input validation on any external identity inputs if they influence internal authorization decisions, although in this specific integration scenario, the fix must reside within the package itself as it handles incoming Matrix events. Additionally, security teams should audit existing configurations for any accounts that might be susceptible to collision attacks by reviewing user ID patterns and ensuring no two active users have identifiers that are case-insensitive duplicates of each other. Long-term architectural improvements involve implementing canonicalization routines that adhere strictly to RFC standards for the relevant protocols and conducting regular code reviews focused on identity management logic to prevent similar normalization errors in future development cycles.