# CVE-2026-27898: vaultwarden — Fixed in 1.35.4 🦀 🦀 crates.io Not in CISA KEV MEDIUM severity # CVE-2026-27898 — vaultwarden MEDIUM CVE-2026-27898 is a medium-severity (CVSS 5.4) CWE-639 vulnerability in vaultwarden. A fix is available for vaultwarden — see the affected versions and patch details below. Vaultwarden: Unauthorized Access via Partial Update API on Another User’s Cipher Also known as[GHSA-w9f8-m526-h7fh](/vulnerability/GHSA-w9f8-m526-h7fh) Published Mar 4, 2026 Updated Oct 28, 2026 Affected 1 pkg Patched 1 / 1 Exploits None indexed Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### No confirmed exploitation observed yet - CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27898. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.2%probability of exploitation in next 30 days Lower Risk\-0.00% Lower risk than most CVEs9th percentile — riskier than 9% of all scored CVEsHighest risk 0.00%0.24%0.49%0.73%0.0%0.2%May 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 1 pkg affected 🦀`vaultwarden` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems. ## Description ### Summary In the test environment, it was confirmed that an authenticated regular user can specify another user’s `cipher_id` and call: ``` PUT /api/ciphers/{id}/partial ``` Even though the standard retrieval API correctly denies access to that cipher, the partial update endpoint returns **200 OK** and exposes `cipherDetails` (including `name`, `notes`, `data`, `secureNote`, etc.). ### Description `put_cipher_partial` retrieves the target Cipher but does **not perform ownership or access control checks** before returning `to_json`. Authorization checks present in the normal update API are missing here. src/api/core/ciphers.rs:717 ``` let Some(cipher) = Cipher::find_by_uuid(&cipher_id, &conn).await else { err!("Cipher doesn't exist") }; if let Some(ref folder_id) = data.folder_id { if Folder::find_by_uuid_and_user(folder_id, &headers.user.uuid, &conn).await.is_none() { err!("Invalid folder", "Folder does not exist or belongs to another user"); } } // Move cipher cipher.move_to_folder(data.folder_id.clone(), &headers.user.uuid, &conn).await?; // Update favorite cipher.set_favorite(Some(data.favorite), &headers.user.uuid, &conn).await?; Ok(Json(cipher.to_json(&headers.host, &headers.user.uuid, None, CipherSyncType::User, &conn).await?)) ``` By comparison, the standard update API includes an explicit authorization check: src/api/core/ciphers.rs:688 ``` if !cipher.is_write_accessible_to_user(&headers.user.uuid, &conn).await { err!("Cipher is not write accessible") } ``` The `to_json` method does not abort processing when access restrictions are not met; instead, it proceeds to construct and return a detailed response. src/db/models/cipher.rs:175 ``` let (read_only, hide_passwords, _) = if sync_type == CipherSyncType::User { match self.get_access_restrictions(user_uuid, cipher_sync_data, conn).await { Some((ro, hp, mn)) => (ro, hp, mn), None => { error!("Cipher ownership assertion failure"); (true, true, false) } } } else { (false, false, false) }; ``` src/db/models/cipher.rs:335 ``` let mut json_object = json!({ "object": "cipherDetails", "id": self.uuid, "type": self.atype, ... "name": self.name, "notes": self.notes, "fields": fields_json, "data": data_json, ... }); ``` ### Preconditions - The attacker possesses a valid regular-user JWT (Bearer token). - The attacker knows the target (victim) `cipher_id`. ### Steps to Reproduce 1. Prepare the attacker JWT and victim `cipher_id` (preconditions). 2. Baseline check: confirm that standard retrieval is denied. image 3. Execute the vulnerable API. Confirm that **200 OK** is returned and that `cipherDetails` includes fields such as `id`, `name`, `notes`, `secureNote`, etc. image ### Potential Impact - Unauthorized disclosure of other users’ cipher information (confidentiality breach). - Creation of unauthorized associations within the attacker’s user context (e.g., `favorite` or folder operations). - The response from `/api/ciphers//partial` includes `attachments[].url`. In filesystem (FS) deployments, this returns a tokenized endpoint such as: ``` /attachments//?token=... ``` In object storage deployments, it returns a short-lived pre-signed URL. As a result, an attacker can use these URLs to directly download attachment data that they are not authorized to access. This can lead to disclosure of sensitive information stored in the Vault, including personal data and authentication credentials. Such exposure may further result in account compromise, lateral movement, and other secondary impacts. ## Affected Packages 1 total 1 fixed Ecosystem Package Vulnerable range Fix 🦀crates.io `vaultwarden` all versions 1.35.4`cargo update -p vaultwarden --precise 1.35.4` ## Affected Products 1 product · 1 configurations Application `vaultwarden`dani-garcia < 1.35.4 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vaultwarden, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update vaultwarden to 1.35.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27898 is resolved across your whole dependency graph. 3. ### Workarounds Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used. ## Frequently Asked Questions \## Summary In the test environment, it was confirmed that an authenticated regular user can specify another user’s \`cipher\_id\` and call: \`\`\` PUT /api/ciphers/{id}/partial \`\`\` Even though the standard retrieval API correctly denies access to that cipher, the partial update endpoint returns \*\*200 OK\*\* and exposes \`cipherDetails\` (including \`name\`, \`notes\`, \`data\`, \`secureNote\`, etc.). ## Description \`put\_cipher\_partial\` retrieves the target Cipher but does \*\*not perform ownership or access control checks\*\* before returning \`to\_json\`. Authorization checks present in the normal update API a O3 Security · Impact-Aware SCA ### Is CVE-2026-27898 in your dependencies? Find it across crates.io, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)