CVE-2024-39924: Vaultwarden Privilege Escalation Flaw

CVE-2024-39924 Overview

CVE-2024-39924 is a privilege escalation vulnerability in Vaultwarden (formerly Bitwarden_RS) version 1.30.3. The flaw resides in the endpoint that modifies emergency access metadata. Authentication and authorization checks fail to validate whether a caller is permitted to alter sensitive fields on their granted emergency access record.

An attacker granted emergency access to a target vault can change the access type from view-only to takeover and reduce the wait_time_days value. The result is full control over the victim's vault without waiting for the approval window intended by the vault owner.

Critical Impact
An emergency-access grantee can escalate to full vault takeover and bypass the configured wait period, compromising all stored credentials.

Affected Products

Vaultwarden 1.30.3 (dani-garcia/vaultwarden)
Deployments running the vulnerable emergency_access.rs handler at commit range preceding 1.32.0
Self-hosted Bitwarden-compatible servers built on Vaultwarden 1.30.3

Discovery Timeline

2024-09-13 - CVE-2024-39924 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-39924

Vulnerability Analysis

Vaultwarden implements Bitwarden's emergency access feature, which allows a vault owner to designate a trusted contact who can request access after a configured waiting period. The owner defines two critical parameters: the access type (view or takeover) and wait_time_days before access activates.

The vulnerable handler in src/api/core/emergency_access.rs (lines 115-148) processes updates to emergency access metadata. It authenticates the caller but does not verify that the caller is the granter. A grantee can therefore submit a modified payload against their own emergency access record and rewrite fields that only the granter should control. This maps to [CWE-276] Incorrect Default Permissions and represents a broken access control condition.

Because emergency access is designed to eventually yield full vault contents, elevating from View to Takeover grants read and write access to all items. Reducing wait_time_days to zero removes the temporal safeguard that would otherwise alert the owner.

Root Cause

The root cause is a missing authorization check on the update handler. The endpoint accepts the emergency access identifier from the request and updates the record without confirming the caller's role is Grantor. Field-level restrictions on type and wait_time_days are also absent, so grantee-supplied values overwrite granter-owned properties.

Attack Vector

Exploitation requires a network-reachable Vaultwarden instance and a valid account that has been granted emergency access to a target vault. The attacker sends an authenticated PUT request to the emergency access update endpoint, replacing the type field with the takeover value and setting wait_time_days to a minimal value. The attacker then invokes the standard emergency-access initiation flow, which now completes without the intended delay and yields full vault access.

Refer to the MGMSP CVE Analysis on Authentication and the vulnerable code in Vaultwarden 1.30.3 for the specific handler logic.

Detection Methods for CVE-2024-39924

Indicators of Compromise

Unexpected PUT requests to /api/emergency-access/{id} where the caller is the grantee rather than the grantor
Emergency access records where type transitions from View (1) to Takeover (2) without a corresponding action from the vault owner
wait_time_days values reduced to 0 or 1 on existing emergency access grants
Emergency access initiation events that complete faster than the originally configured wait period

Detection Strategies

Parse Vaultwarden application logs for update requests to emergency access endpoints and correlate the acting user against the record's grantor identifier
Query the emergency_access table for records whose updated_at timestamp changed without a matching audit entry from the grantor account
Alert on emergency access takeover completions that occur within the same session as a metadata update request

Monitoring Recommendations

Forward Vaultwarden reverse-proxy access logs and application logs to a central SIEM for correlation
Baseline normal emergency access lifecycle events (invite, accept, confirm, initiate, approve) and alert on out-of-order sequences
Monitor administrative panels for changes to emergency access configurations and export the audit trail regularly

How to Mitigate CVE-2024-39924

Immediate Actions Required

Upgrade all Vaultwarden instances to version 1.32.0 or later, which contains the authorization fix
Audit existing emergency access grants and revoke any that show unexpected type or wait_time_days values
Rotate credentials stored in vaults whose emergency access records were modified by grantees
Restrict network exposure of the Vaultwarden API to trusted networks or place it behind an authenticating reverse proxy

Patch Information

The issue is resolved in Vaultwarden Release 1.32.0. The patched handler validates that the caller is the grantor before allowing modifications to type and wait_time_days on emergency access records. Administrators should pull the updated container image or binary and redeploy.

Workarounds

Disable the emergency access feature by removing existing emergency access invitations until the server is patched
Restrict access to the /api/emergency-access/ route paths at the reverse-proxy layer for untrusted clients
Require administrator review before accepting new emergency access grants on high-value vaults

bash

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