GHSA-W9F8-M526-H7FH
Vulnerability from github – Published: 2026-03-04 20:14 – Updated: 2026-03-04 20:14Summary
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
- Prepare the attacker JWT and victim
cipher_id(preconditions). -
Baseline check: confirm that standard retrieval is denied.
-
Execute the vulnerable API. Confirm that 200 OK is returned and that
cipherDetailsincludes fields such asid,name,notes,secureNote, etc.
Potential Impact
- Unauthorized disclosure of other users’ cipher information (confidentiality breach).
- Creation of unauthorized associations within the attacker’s user context (e.g.,
favoriteor folder operations). - The response from
/api/ciphers/<cipher_id>/partialincludesattachments[].url.
In filesystem (FS) deployments, this returns a tokenized endpoint such as:
/attachments/<cipher>/<file>?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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.35.3"
},
"package": {
"ecosystem": "crates.io",
"name": "vaultwarden"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.35.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27898"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T20:14:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nIn the test environment, it was confirmed that an authenticated regular user can specify another user\u2019s `cipher_id` and call:\n\n```\nPUT /api/ciphers/{id}/partial\n```\n\nEven 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.).\n\n\n\n## Description\n\n`put_cipher_partial` retrieves the target Cipher but does **not perform ownership or access control checks** before returning `to_json`.\nAuthorization checks present in the normal update API are missing here.\nsrc/api/core/ciphers.rs:717\n\n```rust\nlet Some(cipher) = Cipher::find_by_uuid(\u0026cipher_id, \u0026conn).await else {\n err!(\"Cipher doesn\u0027t exist\")\n};\n\nif let Some(ref folder_id) = data.folder_id {\n if Folder::find_by_uuid_and_user(folder_id, \u0026headers.user.uuid, \u0026conn).await.is_none() {\n err!(\"Invalid folder\", \"Folder does not exist or belongs to another user\");\n }\n}\n\n// Move cipher\ncipher.move_to_folder(data.folder_id.clone(), \u0026headers.user.uuid, \u0026conn).await?;\n\n// Update favorite\ncipher.set_favorite(Some(data.favorite), \u0026headers.user.uuid, \u0026conn).await?;\n\nOk(Json(cipher.to_json(\u0026headers.host, \u0026headers.user.uuid, None, CipherSyncType::User, \u0026conn).await?))\n```\n\nBy comparison, the standard update API includes an explicit authorization check:\nsrc/api/core/ciphers.rs:688\n\n```rust\nif !cipher.is_write_accessible_to_user(\u0026headers.user.uuid, \u0026conn).await {\n err!(\"Cipher is not write accessible\")\n}\n```\n\nThe `to_json` method does not abort processing when access restrictions are not met; instead, it proceeds to construct and return a detailed response.\nsrc/db/models/cipher.rs:175\n\n```rust\nlet (read_only, hide_passwords, _) = if sync_type == CipherSyncType::User {\n match self.get_access_restrictions(user_uuid, cipher_sync_data, conn).await {\n Some((ro, hp, mn)) =\u003e (ro, hp, mn),\n None =\u003e {\n error!(\"Cipher ownership assertion failure\");\n (true, true, false)\n }\n }\n} else {\n (false, false, false)\n};\n```\nsrc/db/models/cipher.rs:335\n\n```rust\nlet mut json_object = json!({\n \"object\": \"cipherDetails\",\n \"id\": self.uuid,\n \"type\": self.atype,\n ...\n \"name\": self.name,\n \"notes\": self.notes,\n \"fields\": fields_json,\n \"data\": data_json,\n ...\n});\n```\n\n\n## Preconditions\n\n* The attacker possesses a valid regular-user JWT (Bearer token).\n* The attacker knows the target (victim) `cipher_id`.\n\n\n## Steps to Reproduce\n\n1. Prepare the attacker JWT and victim `cipher_id` (preconditions).\n2. Baseline check: confirm that standard retrieval is denied.\n\u003cimg width=\"2014\" height=\"855\" alt=\"image\" src=\"https://github.com/user-attachments/assets/32b12cc9-3672-4a88-afd0-ef7715474662\" /\u003e\n\n\n3. Execute the vulnerable API. Confirm that **200 OK** is returned and that `cipherDetails` includes fields such as `id`, `name`, `notes`, `secureNote`, etc.\n\u003cimg width=\"2018\" height=\"1113\" alt=\"image\" src=\"https://github.com/user-attachments/assets/341b330c-8d55-4f06-a622-0d7da28f62fd\" /\u003e\n\n\n## Potential Impact\n\n* Unauthorized disclosure of other users\u2019 cipher information (confidentiality breach).\n* Creation of unauthorized associations within the attacker\u2019s user context (e.g., `favorite` or folder operations).\n* The response from `/api/ciphers/\u003ccipher_id\u003e/partial` includes `attachments[].url`.\n\nIn filesystem (FS) deployments, this returns a tokenized endpoint such as:\n\n```\n/attachments/\u003ccipher\u003e/\u003cfile\u003e?token=...\n```\n\nIn object storage deployments, it returns a short-lived pre-signed URL.\n\nAs a result, an attacker can use these URLs to directly download attachment data that they are not authorized to access.\n\nThis 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.",
"id": "GHSA-w9f8-m526-h7fh",
"modified": "2026-03-04T20:14:06Z",
"published": "2026-03-04T20:14:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-w9f8-m526-h7fh"
},
{
"type": "PACKAGE",
"url": "https://github.com/dani-garcia/vaultwarden"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vaultwarden has Unauthorized Access via Partial Update API on Another User\u2019s Cipher"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.