☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-39925

CVE-2024-39925 Unauthorized Access in Vaultwarden
📅 PUBLISHED: 2024-09-13 00:00 UTC 🔄 UPDATED: 2026-09-23 20:38 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.57%
👁️
0.57% probability
14.3× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
SOON
PENDING NVD
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-39925 identifies a critical access control and cryptographic key management vulnerability in Vaultwarden (formerly Bitwarden_RS) version 1.30.3. The core issue is the lack of an offboarding process for organization members. When a member leaves an organization, the shared organization encryption key is not rotated. This allows a departing member to retain a copy of the key. Furthermore, the application fails to adequately protect encrypted data stored on the server, enabling an authenticated user to potentially access encrypted data of any organization if they know the corresponding organizationId. A user whose access has been revoked but who still possesses the organization key can decrypt this leaked data, leading to a complete breach of confidentiality for all organization vaults.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is inherent in the Vaultwarden application itself, which is a self-hosted, open-source password manager written in Rust. The flaw is in the application's business logic and data access controls, not in a specific dependency. However, the security of the entire deployment relies on the integrity of the Vaultwarden binary and its configuration. Administrators must ensure they are using a trusted source for the Vaultwarden image or binary and verify its checksum.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or error. Based on the description, a reasonable CVSS v3.1 vector would be:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

  • Attack Vector (AV): Network - The vulnerability can be exploited remotely over the network.
  • Attack Complexity (AC): Low - No special conditions are required; the attacker simply needs to be an authenticated user.
  • Privileges Required (PR): Low - The attacker needs to be an authenticated user of the Vaultwarden instance.
  • User Interaction (UI): None - No interaction from another user is required.
  • Scope (S): Unchanged - The vulnerability does not affect resources beyond the Vaultwarden application.
  • Confidentiality (C): High - The attacker can gain access to all encrypted vault data of any organization.
  • Integrity (I): None - The attacker cannot modify data.
  • Availability (A): None - The attacker cannot disrupt service.

Threat Level: Critical (Estimated Score: 7.7)

Deep Dive & Mechanics

The vulnerability is a combination of two distinct flaws:

  1. Lack of Key Rotation on Member Departure: When a user is removed from an organization, the shared organization key (org_key) is not rotated. This key is used to encrypt and decrypt the organization's vault items. The departing member retains a copy of this key in their local client or session data.

  2. Inadequate Server-Side Data Protection: The Vaultwarden server stores encrypted organization data (vault items) in a way that is accessible to any authenticated user who knows the organizationId. The application does not properly enforce that the requesting user is a current member of the organization before returning the encrypted data.

Attack Flow:

  1. Reconnaissance: An attacker, who is an authenticated user of the Vaultwarden instance, enumerates or guesses organizationId values. This could be done by observing API responses, inspecting client-side code, or brute-forcing UUIDs.
  2. Data Exfiltration: The attacker sends a request to the Vaultwarden API endpoint that serves encrypted organization data, using a known or guessed organizationId. The server returns the encrypted vault items without verifying the attacker's membership in that organization.
  3. Decryption: If the attacker is a former member of the target organization (and thus possesses the org_key), they can decrypt the exfiltrated data. If the attacker is not a former member, they cannot decrypt the data, but the confidentiality of the encrypted data is still compromised.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable code pattern and the expected fix.

Vulnerable Code Pattern (Conceptual):

// Vulnerable endpoint: GET /api/organizations/{org_id}/vault-items
async fn get_organization_vault_items(
    user: AuthenticatedUser,
    org_id: Path<String>,
    // ... database connection
) -> Result<Json<Vec<VaultItem>>, Error> {
    // BUG: No check if user is a current member of the organization
    let items = db.get_encrypted_vault_items_for_organization(&org_id).await?;
    Ok(Json(items))
}

Expected Patched Code Pattern (Conceptual):

// Patched endpoint: GET /api/organizations/{org_id}/vault-items
async fn get_organization_vault_items(
    user: AuthenticatedUser,
    org_id: Path<String>,
    // ... database connection
) -> Result<Json<Vec<VaultItem>>, Error> {
    // FIX: Verify user is a current member of the organization
    if !db.is_user_member_of_organization(&user.id, &org_id).await? {
        return Err(Error::Forbidden("User is not a member of this organization"));
    }
    let items = db.get_encrypted_vault_items_for_organization(&org_id).await?;
    Ok(Json(items))
}

Additionally, the offboarding process should be fixed to rotate the organization key:

// Expected fix in the user removal function
async fn remove_user_from_organization(
    admin_user: AuthenticatedUser,
    org_id: Path<String>,
    user_to_remove: Path<String>,
    // ... database connection
) -> Result<(), Error> {
    // ... remove user ...
    // FIX: Rotate the organization key
    let new_org_key = generate_new_encryption_key();
    db.update_organization_key(&org_id, &new_org_key).await?;
    // Re-encrypt all vault items with the new key
    db.re_encrypt_organization_vault_items(&org_id, &new_org_key).await?;
    Ok(())
}

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

  1. Deploy Vaultwarden 1.30.3 using Docker: docker run -d --name vaultwarden -p 80:80 vaultwarden/server:1.30.3
  2. Create two user accounts: attacker@test.com and victim@test.com.
  3. Create an organization "TestOrg" and add both users.
  4. As victim@test.com, add some sensitive vault items to the organization.
  5. As an admin, remove attacker@test.com from the organization.

Exploitation Steps:

  1. As attacker@test.com, authenticate and obtain a session token.
  2. Enumerate organization IDs. This can be done by observing the network traffic when the organization list is loaded, or by brute-forcing UUIDs.
  3. Send a GET request to the API endpoint to fetch encrypted vault items for the target organization:
    curl -H "Authorization: Bearer <attacker_token>" \
         "https://vaultwarden.example.com/api/organizations/<org_id>/vault-items"
    
  4. The server returns the encrypted vault items. Since the attacker still has the organization key from their previous membership, they can decrypt the data using the Vaultwarden client or a custom script.

Blue Team (Defensive)

Detection:

  • Monitor for API requests to /api/organizations/{org_id}/vault-items from users who are not members of that organization.
  • Alert on any successful retrieval of organization vault items by a user who was recently removed from that organization.
  • Monitor for unusual patterns of organizationId enumeration (e.g., rapid sequential requests to different IDs).

Mitigation:

  • Immediately rotate the organization key for any organization that has had a member depart since the vulnerable version was deployed.
  • Implement strict access control checks on all organization-related API endpoints.
  • Consider implementing a "just-in-time" key delivery mechanism where the organization key is only provided to currently active members.

Indicators of Compromise (IOCs)

  • Network:
    • API requests to /api/organizations/{org_id}/vault-items where the org_id does not correspond to any organization the user is a member of.
    • Unusual volume of requests to organization-related endpoints from a single user.
  • Logs:
    • Vaultwarden access logs showing 403 Forbidden errors on organization endpoints, followed by successful 200 OK responses for the same endpoint.
    • Audit logs showing a user accessing organization data after their membership was revoked.
  • System:
    • Unexpected decryption of organization vault data by a user who is not a current member.

Detection Engineering

YARA Rule

rule Detect_Vaultwarden_Key_Leak_Exploit {
    meta:
        description = "Detects attempts to exploit CVE-2024-39925 by accessing organization vault items without proper membership"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-39925"
    strings:
        $api_endpoint = "/api/organizations/" ascii wide nocase
        $vault_items = "/vault-items" ascii wide nocase
        $org_id_pattern = /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/ ascii wide
    condition:
        all of ($api_endpoint, $vault_items) and $org_id_pattern
}

Sigma Rule

title: Vaultwarden Unauthorized Organization Vault Access
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to exploit CVE-2024-39925 by accessing organization vault items without proper membership
author: Valters IT
date: 2024/01/01
logsource:
    category: webserver
    product: vaultwarden
detection:
    selection:
        cs-method: 'GET'
        cs-uri-stem|contains: '/api/organizations/'
        cs-uri-stem|endswith: '/vault-items'
    condition: selection
falsepositives:
    - Legitimate access by organization members
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-39925 Vaultwarden Unauthorized Organization Vault Access"; flow:to_server; content:"GET"; http_method; content:"/api/organizations/"; http_uri; content:"/vault-items"; http_uri; pcre:"/\/api\/organizations\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\/vault-items/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Rotate Organization Keys: For any organization that has had a member depart since the vulnerable version was deployed, manually rotate the organization key. This can be done by creating a new organization and migrating data, or by using a script to re-encrypt all vault items with a new key.
  2. Restrict API Access: Implement a Web Application Firewall (WAF) or reverse proxy rule to block requests to /api/organizations/{org_id}/vault-items from users who are not members of the specified organization. This is a temporary workaround.
  3. Audit User Access: Review all organization memberships and remove any users who should not have access.

Long-Term Fix:

  • Patch Application: Monitor the Vaultwarden project for an official patch. Once released, upgrade to the patched version immediately.
  • Implement Key Rotation: The Vaultwarden development team must implement a secure offboarding process that rotates the organization key whenever a member is removed.
  • Enforce Access Controls: The application must verify that the requesting user is a current member of the organization before returning any encrypted data.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. All information is provided for educational and defensive purposes only. Unauthorized exploitation of this vulnerability is illegal.

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-39925/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.