Bug Description
Cipher::to_json() in src/db/models/cipher.rs returns Result<Value, Error>, but the match arm for unknown atype values calls panic!("Wrong type") rather than returning a proper Err.
Affected code (around line 395–402):
let key = match self.atype {
1 => "login",
2 => "secureNote",
3 => "card",
4 => "identity",
5 => "sshKey",
_ => panic!("Wrong type"), // ← panics instead of returning Err
};
Why This Matters
Because the whole function signature is -> Result<Value, crate::Error>, the intent is clearly to propagate failures to callers — but a panic! bypasses that entirely and terminates the Rocket worker thread (or the whole process, depending on the panic hook).
A cipher with an unexpected atype can end up in the database via:
- Direct database edits / migrations
- Corruption or a future Bitwarden protocol extension that adds a new type before vaultwarden is updated
When a user with such a cipher calls /sync, vaultwarden crashes instead of returning a 500/error response, which also affects all other concurrent users on the same instance.
Expected Behavior
Return an Err (using the existing err! macro already used elsewhere in the same file) so the error is logged and the request fails gracefully without crashing the server.
Suggested Fix
_ => err!(format!("Cipher {} has an invalid type {}", self.uuid, self.atype)),
I have a PR ready with this one-line fix.
Bug Description
Cipher::to_json()insrc/db/models/cipher.rsreturnsResult<Value, Error>, but the match arm for unknownatypevalues callspanic!("Wrong type")rather than returning a properErr.Affected code (around line 395–402):
Why This Matters
Because the whole function signature is
-> Result<Value, crate::Error>, the intent is clearly to propagate failures to callers — but apanic!bypasses that entirely and terminates the Rocket worker thread (or the whole process, depending on the panic hook).A cipher with an unexpected
atypecan end up in the database via:When a user with such a cipher calls
/sync, vaultwarden crashes instead of returning a 500/error response, which also affects all other concurrent users on the same instance.Expected Behavior
Return an
Err(using the existingerr!macro already used elsewhere in the same file) so the error is logged and the request fails gracefully without crashing the server.Suggested Fix
I have a PR ready with this one-line fix.