Introduction
A missing organization consistency check in Vaultwarden's group management API allows an attacker with Admin rights in one organization to silently gain read and write access to vault data belonging to a completely separate organization on the same instance. For self hosted Vaultwarden deployments where multiple organizations coexist, this vulnerability (CVE-2026-43912, CVSS 8.7 High) breaks the fundamental tenant isolation boundary that organizations rely on to keep their secrets separate.
Vaultwarden is an unofficial, community maintained Bitwarden compatible server written in Rust, formerly known as bitwarden_rs. It is widely adopted by individuals, families, and small organizations who prefer to self host their password management infrastructure rather than use the official Bitwarden cloud service. While not affiliated with Bitwarden Inc., Vaultwarden's compatibility with official Bitwarden clients makes it a popular choice in the self hosting ecosystem.
Technical Information
Root Cause: Missing Organization Scoping on Group Relationships
The vulnerability stems from a failure to enforce organization consistency across two critical database relationships. Vaultwarden's schema includes the following relevant tables:
groups: each group belongs to a single organization viagroups.organizations_uuidgroups_users: links groups to user memberships viagroups_users.users_organizations_uuidcollections_groups: links groups to collections viacollections_groups.collections_uuid
While foreign key constraints exist on these tables, there is no composite constraint ensuring that the membership or collection referenced in a join table row actually belongs to the same organization as the group. The group management API endpoints compound this by forwarding attacker controlled MembershipId and CollectionId values directly into the add_update_group() function without calling find_by_uuid_and_org() to verify organizational parity.
This is classified under CWE-285 (Improper Authorization).
Attack Flow
The exploitation chain requires the attacker to hold Admin privileges in at least one organization (Org A) and standard membership in the target organization (Org B) on the same Vaultwarden instance. The attack proceeds as follows:
Step 1: Enumerate the target membership UUID. The attacker reads their own Org B membership UUID from the normal profile or sync API response. This is a standard, non privileged operation available to any authenticated user.
Step 2: Create a cross organization group binding. The attacker uses their Admin privileges in Org A to create (or update) a group with accessAll set to true, injecting their Org B membership UUID into the group's user list. The API payload looks like this:
{ "name" : " cross-org-pivot ", "accessAll" : true, "externalId" : null, "collections" : [], "users" : [ " <ATTACKER_MEMBERSHIP_ID_IN_ORG_B> " ] }
Because the endpoint does not verify that the supplied membership ID belongs to Org A, the server persists a groups_users row linking an Org A group to an Org B membership.
Step 3: Exploit the sync endpoint for unauthorized read access. The attacker calls GET /api/sync. The server's cipher visibility queries traverse the groups_users relationship and, finding the attacker's Org B membership linked to an access_all = true group, wrongly treats this as authorization to include Org B ciphers in the sync response. The attacker now has full read access to Org B vault data.
Step 4: Escalate to write access via collection binding. The unauthorized sync results reveal Org B collection IDs. The attacker updates the Org A group to include those foreign collection IDs in the collections array. Since the collections_groups table also lacks organization scoping, the server persists these cross organization collection bindings. The attacker can now write to Org B items through the same foreign group relationship.
The CVSS 3.1 vector is AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N. The scope change (S:C) reflects that the attacker crosses the organization isolation boundary, impacting a security scope beyond the one they are authorized to administer.
Patch Information
The fix for CVE-2026-43912 was developed by @BlackDex and shipped in Vaultwarden 1.35.5, released on April 12, 2026. The core patch landed through Pull Request #7032 ("Misc org fixes"), which was merged on March 29, 2026 (merge commit 787822854cb73aeb8375a4e69ea188aa5f02db02). The PR touched 12 files, adding 340 lines and removing 191.
The PR description states that the change "Fixed several Organization endpoints and Queries regarding groups, collections and membership validation" and also "Split vault purge for org and personal vaults for better validation." These changes directly address the two compounding design bugs that made the cross organization privilege escalation possible.
The patch addresses both layers of the vulnerability:
API layer input validation (write paths): The group create, update, and member replacement endpoints in src/api/core/organizations.rs now validate that every supplied MembershipId has an org_uuid matching the target group's organization, and every supplied CollectionId likewise belongs to the same org. If any foreign ID is provided, the request is rejected instead of persisting a cross organization relationship into groups_users or collections_groups. This closes the injection vector entirely.
Query layer authorization hardening (read/write paths): The database model queries that derive cipher visibility and collection access, spanning src/db/models/cipher.rs, src/db/models/collection.rs, and src/db/models/group.rs, were updated to add a join condition requiring groups.organizations_uuid to equal the relevant users_organizations.org_uuid. This means that even if a stale or malformed cross organization groups_users row exists in the database, it will no longer be honored during access evaluation. The Cipher::find_by_user() query, the CollectionGroup::find_by_user() helper, and the collection writability/manageability checks all now enforce same organization matching.
This defense in depth approach ensures that even one of the two fixes alone would block the attack chain. The release notes for 1.35.5 explicitly list GHSA-569v-845w-g82p as one of the security fixes included in the release.
Affected Systems and Versions
All Vaultwarden versions prior to 1.35.5 are affected. This includes the entire 1.35.x line through 1.35.4, as well as all earlier release branches. The vulnerability is fixed in version 1.35.5. The latest available release at the time of writing is 1.36.0.
The vulnerability specifically affects multi organization deployments where at least one user holds Admin privileges in one organization and membership in another. Single organization instances are not exploitable through this vector, though upgrading is still strongly recommended.
No configuration workarounds or temporary mitigations are documented in the security advisory. The only remediation is to apply the patch.
Vendor Security History
Vaultwarden has experienced a cluster of authorization and authentication vulnerabilities between 2025 and 2026, many of which were resolved in the 1.35.x release train:
| CVE | Summary | Affected Versions | Fixed In |
|---|---|---|---|
| CVE-2025-24365 | Attacker can obtain owner rights of another organization if they know the victim organization ID and own a different organization | Prior to 1.33.0 | 1.33.0 |
| CVE-2026-26012 | Regular organization member can retrieve all ciphers within an organization regardless of collection permissions | Prior to 1.35.3 | 1.35.3 |
| CVE-2026-27801 | 2FA bypass when performing protected actions, allowing authenticated attackers to access API keys or delete vaults | 1.34.3 and prior | 1.35.0 |
| CVE-2026-31835 | WebAuthn authentication flow updates persistent credential metadata before signature validation, leading to persistent DoS of WebAuthn 2FA | 1.35.4 and earlier | 1.35.5 |
The recurring pattern of cross organization authorization bypasses (CVE-2025-24365, CVE-2026-26012, and now CVE-2026-43912) suggests that organization isolation has been a persistent challenge in the codebase. Self hosting administrators should treat Vaultwarden security updates with the same urgency as any other credential management infrastructure.
