CVE-2026-43912: Vaultwarden Auth Bypass Vulnerability

CVE-2026-43912 Overview

Vaultwarden, a Bitwarden-compatible server implementation written in Rust, contains a broken access control vulnerability in versions prior to 1.35.5. The flaw resides in group-management endpoints that fail to enforce organization boundaries when persisting MembershipId and CollectionId values. An authenticated attacker holding Admin rights in one organization and low-privileged membership in a second organization can bind foreign membership UUIDs into groups they control. This cross-organization confusion grants unauthorized read access to vault items in the victim organization through /api/sync and /api/ciphers. The same flaw allows the attacker to escalate to write access by binding foreign collection IDs into an accessAll=true group.

Critical Impact

An Admin in one Vaultwarden organization can read and modify vault data belonging to a separate organization where they hold only low-privileged membership, breaking tenant isolation.

Affected Products

• Dani-garcia Vaultwarden versions prior to 1.35.5
• Self-hosted Vaultwarden deployments serving multiple organizations
• Multi-tenant Bitwarden-compatible Rust server instances

Discovery Timeline

• 2026-05-11 - CVE-2026-43912 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43912

Vulnerability Analysis

The vulnerability is an authorization bypass classified under [CWE-285] Improper Authorization. Vaultwarden organizes vault data into organizations, groups, members, and collections. Group membership is stored in groups_users with a users_organizations_uuid foreign key, while collection-to-group mappings live in collections_groups. Vaultwarden does not validate that the users_organizations_uuid belongs to the same organization as the groups_uuid it is being attached to. The same check is missing between collections_groups.collections_uuid and collections_groups.groups_uuid. Group-management endpoints accept these identifiers from the client and persist them without consistency checks.

Root Cause

Multiple organization group-management handlers trust client-supplied MembershipId and CollectionId values. The server writes these rows directly into the relational store without joining against the parent organization. As a result, references that point across organization boundaries become valid records, and downstream authorization logic treats them as legitimate group bindings.

Attack Vector

The attacker first creates or controls a group in Organization A with accessAll=true. They then call a group-management endpoint to add their Organization B MembershipId to that Org A group. Subsequent calls to /api/sync and /api/ciphers enumerate Org B ciphers because the access-check logic follows the forged group relationship. Once Org B collection UUIDs are revealed, the attacker binds those CollectionId values into the same Org A group, gaining write access over Org B items. The attack requires network access and authenticated high-privilege credentials in the attacker-controlled organization, with no user interaction in the victim organization.

See the GitHub Security Advisory GHSA-569v-845w-g82p for the upstream technical write-up.

Detection Methods for CVE-2026-43912

Indicators of Compromise

• Rows in groups_users where users_organizations_uuid resolves to a different organization than the parent groups.organization_uuid.
• Rows in collections_groups where collections_uuid belongs to a different organization than the linked group.
• Unexpected /api/sync or /api/ciphers responses returning ciphers from organizations the requesting account is not a full member of.

Detection Strategies

• Run integrity queries against the Vaultwarden database to identify cross-organization references in groups_users and collections_groups.
• Inspect application logs for repeated PUT or POST requests to /api/organizations/{org_id}/groups/* endpoints originating from a single user across multiple organizations.
• Alert on accounts that hold Admin rights in one organization while simultaneously holding low-privilege membership in others, then issue group-modification API calls in short succession.

Monitoring Recommendations

• Enable verbose request logging on the Vaultwarden reverse proxy and forward to a central SIEM for correlation of cross-organization API patterns.
• Track baseline volumes of /api/sync responses per account and alert on sudden growth in returned cipher counts.
• Audit group membership and collection assignment changes on a recurring schedule and reconcile against expected organizational structure.

How to Mitigate CVE-2026-43912

Immediate Actions Required

• Upgrade Vaultwarden to version 1.35.5 or later on all self-hosted instances.
• Audit existing groups_users and collections_groups tables for cross-organization references and remove invalid rows.
• Rotate organization-level secrets and review access logs for unauthorized cipher access during the exposure window.

Patch Information

The fix is published in Vaultwarden 1.35.5, which adds organization consistency checks to the group-management endpoints. Refer to the Vaultwarden GitHub Security Advisory for release details and patch commits.

Workarounds

• Restrict Admin role assignments so users do not simultaneously hold Admin privileges in one organization and membership in unrelated organizations on the same instance.
• Disable group features for affected organizations until the upgrade to 1.35.5 is applied.
• Segregate sensitive organizations onto dedicated Vaultwarden instances to remove the shared-tenancy attack surface.

# Upgrade Vaultwarden container to the patched release
docker pull vaultwarden/server:1.35.5
docker stop vaultwarden
docker rm vaultwarden
docker run -d --name vaultwarden \
  -v /vw-data/:/data/ \
  -p 80:80 \
  vaultwarden/server:1.35.5