EUVD-2026-29340Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N
Network-reachable API with low complexity, but attacker must be admin of one organization (PR:H); crossing into another org's data is a scope change (S:C) with high confidentiality and integrity impact and no availability effect.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
3DescriptionGitHub Advisory
Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.5, Vaultwarden does not enforce that a groups_users.users_organizations_uuid entry belongs to the same organization as groups.groups_uuid, or a collections_groups.collections_uuid entry belongs to the same organization as collections_groups.groups_uuid. Multiple organization group-management endpoints accept arbitrary MembershipId and CollectionId values and persist them directly without verifying org consistency. This lets an attacker who is Admin in Organization A, and only a low-privileged member in Organization B bind their Org B membership UUID into an Org A group, then use that foreign group relationship to gain unauthorized access to Org B vault data. With an accessAll=true Org A group, the attacker can make /api/sync and /api/ciphers enumerate Org B ciphers. Once those unauthorized sync results reveal Org B collection IDs, the attacker can also bind those foreign collection IDs to the Org A group and turn the same flaw into write access over Org B items. This vulnerability is fixed in 1.35.5.
AnalysisAI
Cross-organization authorization bypass in Vaultwarden (the Rust-based, self-hosted Bitwarden-compatible server) prior to 1.35.5 lets an attacker who holds Admin rights in one organization pivot into a second organization where they are only a low-privileged member. Because group-management endpoints persist arbitrary MembershipId and CollectionId values without checking org consistency (CWE-285), the attacker can bind their foreign Org B membership into an accessAll Org A group and read - then write - Org B vault data via /api/sync and /api/ciphers. A POC is referenced in the SSVC data (publicly available exploit code exists); it is not in CISA KEV and EPSS is very low (0.03%), consistent with a targeted, multi-step abuse rather than mass exploitation.
Technical ContextAI
Vaultwarden stores organization membership and collection relationships in relational tables including groups, groups_users, collections_groups, and users_organizations. The flaw is a broken-authorization / missing consistency check: the code does not verify that a groups_users.users_organizations_uuid belongs to the same organization as the target groups.groups_uuid, nor that a collections_groups.collections_uuid belongs to the same organization as collections_groups.groups_uuid. Multiple group-management endpoints accept attacker-supplied MembershipId and CollectionId values and write them straight into these join tables. This is CWE-285 (Improper Authorization): the server trusts caller-supplied UUIDs as authoritative rather than validating them against the acting organization's scope. The affected component is dani-garcia/vaultwarden (CPE cpe:2.3:a:dani-garcia:vaultwarden:*), all versions below 1.35.5.
RemediationAI
Primary fix: upgrade to Vaultwarden 1.35.5, which enforces that group_user and collection_group relationships belong to the same organization (Vendor-released patch: 1.35.5, per GHSA-569v-845w-g82p). Because the container image is the usual deployment path, pull the 1.35.5 (or later) image and redeploy; there is no configuration-only workaround that restores org-consistency checks. If you cannot patch immediately, reduce exposure by limiting who can hold Admin on any organization on a shared instance and by avoiding hosting mutually-distrusting organizations on the same Vaultwarden instance until upgraded - separating tenants onto isolated instances removes the cross-org pivot at the cost of operational overhead. After patching, audit existing group memberships and collection-group bindings for cross-organization UUIDs that may have been planted before the fix, since upgrading stops new abuse but does not necessarily unwind relationships already persisted. Refer to the advisory at https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-569v-845w-g82p.
More in Vaultwarden
View allTwo-factor authentication bypass in Vaultwarden 1.34.3 and earlier allows authenticated attackers to circumvent 2FA prot
Vaultwarden versions prior to 1.35.4 fail to properly enforce collection management permissions, allowing authenticated
Vaultwarden versions before 1.35.4 contain a privilege escalation vulnerability that allows authenticated Manager-level
Session hijacking via a broken SSO/OAuth authorization flow affects Vaultwarden (the Rust-based Bitwarden-compatible ser
Improper authorization in Vaultwarden (self-hosted Bitwarden-compatible server) before 1.35.5 lets an authenticated user
Authentication bypass (account takeover) in Vaultwarden before 1.36.0 allows an attacker who controls a federated identi
vaultwarden is an unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs. Rated high sev
Brute-force protection bypass in Vaultwarden (the Rust Bitwarden-compatible server) before 1.35.4 lets unauthenticated r
Vaultwarden's SSO discovery endpoint exposed real organization SSO metadata - including organizationIdentifier values -
Insufficient session expiration in Vaultwarden prior to 1.35.5 allows an attacker holding a previously obtained refresh
Vaultwarden versions prior to 1.35.3 allow authenticated organization members to bypass collection-level access controls
Server-side request forgery (SSRF) in Vaultwarden's icon fetching endpoint allows blind internal network and port discov
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today