Browse Source
A type-5 cipher whose sshKey object carries null (or non-string) values in privateKey, publicKey or keyFingerprint was accepted and stored, but clients drop the malformed payload on read: the save looks successful and the key material silently disappears. Bitwarden's own server rejects the same request with a validation error, so a client that is correct against cloud gets silent data loss against Vaultwarden. Require all three members to be present as non-empty strings before persisting a type-5 cipher, matching the cloud behavior described in #7514. This is a presence check only — key material itself is not parsed or validated. Fixes #7514 Signed-off-by: Yunare Maia <yunare@gmail.com>pull/7636/head
1 changed files with 19 additions and 5 deletions
Loading…
Reference in new issue