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 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 used by individuals, families, and small organizations who prefer to self-host their password management infrastructure rather than use the official Bitwarden cloud service. Vaultwarden is not affiliated with Bitwarden Inc., but it works with the official Bitwarden clients, which makes it a popular choice for self-hosting.
Technical Information
Root Cause: Missing Organization Scoping on Group Relationships
The vulnerability comes from a failure to enforce organization consistency across two 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
These tables have foreign key constraints, but no composite constraint ensures that the membership or collection referenced in a join-table row belongs to the same organization as the group. The group management API endpoints make this worse. They forward attacker-controlled MembershipId and CollectionId values directly into the add_update_group() function without calling find_by_uuid_and_org() to check that those IDs belong to the group's organization.
The flaw is classified as CWE-285 (Improper Authorization).
Attack Flow
The attacker needs 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. Any authenticated user can do this without special privileges.
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, and puts their Org B membership UUID in 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 follow the groups_users relationship, find the attacker's Org B membership linked to an access_all = true group, and wrongly treat that link 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 include Org B collection IDs. The attacker updates the Org A group to put those foreign collection IDs in the collections array. Because 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 is changed (S:C) because the attacker crosses the organization isolation boundary and affects a security scope beyond the one they are authorized to administer.
Patch Information
@BlackDex developed the fix for CVE-2026-43912, and it shipped in Vaultwarden 1.35.5, released on April 12, 2026. The core patch landed through Pull Request #7032 ("Misc org fixes"), merged on March 29, 2026 (merge commit 787822854cb73aeb8375a4e69ea188aa5f02db02). The PR changed 12 files, adding 340 lines and removing 191.
The PR description says 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 address the two design bugs that combined to make 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 check that every supplied MembershipId has an org_uuid matching the target group's organization, and that every supplied CollectionId belongs to the same organization. If the request contains any foreign ID, the server rejects it 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, in src/db/models/cipher.rs, src/db/models/collection.rs, and src/db/models/group.rs, now include a join condition requiring groups.organizations_uuid to equal the relevant users_organizations.org_uuid. Even if a stale or malformed cross-organization groups_users row exists in the database, access evaluation no longer honors it. The Cipher::find_by_user() query, the CollectionGroup::find_by_user() helper, and the collection writability/manageability checks all now enforce same-organization matching.
With this defense-in-depth approach, either of the two fixes alone would block the attack chain. The release notes for 1.35.5 list GHSA-569v-845w-g82p among the security fixes in the release.
Affected Systems and Versions
All Vaultwarden versions prior to 1.35.5 are affected. That covers the 1.35.x line through 1.35.4 and every earlier release branch. Version 1.35.5 fixes the vulnerability. At the time of writing, the latest available release is 1.36.0.
The vulnerability affects only 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.
The security advisory documents no configuration workarounds or temporary mitigations. The only remediation is to apply the patch.
Vendor Security History
Vaultwarden has had a cluster of authorization and authentication vulnerabilities in 2025 and 2026, many of them 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 repeated cross-organization authorization bypasses (CVE-2025-24365, CVE-2026-26012, and now CVE-2026-43912) suggest that organization isolation has been a persistent weak spot in the codebase. Administrators who self-host Vaultwarden should apply its security updates with the same urgency as updates to any other credential management infrastructure.
