mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-05-24 09:03:15 -05:00
[GH-ISSUE #6562] Broken ciphers created when collection is read-only #15258
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @uedvt359 on GitHub (Dec 16, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6562
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Environment settings which are overridden: DOMAIN, SIGNUPS_ALLOWED, ORG_CREATION_USERS, INVITATIONS_ALLOWED, ADMIN_TOKEN, IP_HEADER, SSO_ENABLED, SSO_SIGNUPS_MATCH_EMAIL, SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION, SSO_CLIENT_ID, SSO_CLIENT_SECRET, SSO_AUTHORITY, SSO_SCOPES, SSO_MASTER_PASSWORD_POLICY, SSO_AUTH_ONLY_NOT_SESSION, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM
Config:
Vaultwarden Build Version
1.34.3-f9751a0a
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
n/a
Host/Server Operating System
Linux
Operating System Version
rhel9
Clients
CLI
Client Version
api requests
Steps To Reproduce
/api/ciphers/createendpoint, and setcollectionsto the uuid of the read-only collection from step 2Expected Result
cipher creation should fail, and no half-finished entries should be written to the database
Actual Result
cipher creation returns a 400 "No rights to modify the collection" error, but it creates an entry in the
cipherstable, with thedatacolumn being the empty string.later calls to
/api/syncthen cause an "Error parsing data field for " log message for each cipher that was attemted to get created in a read-only collection.Logs
Screenshots or Videos
No response
Additional Context
No response
@BlackDex commented on GitHub (Dec 20, 2025):
Well, it basically isn't a broken cipher created, but more that how we create a new cipher. It first gets stored, and after that shared/linked to the organization and checked if that the user is allowed to access the provided collection's.
So the cipher is ok, but only if it's linked to an org, which in this case isn't and still linked to the user, and therefor not able to be decrypted.
I have this fixed #6578 , that will warn earlier before even creating a new key.
@uedvt359 commented on GitHub (Dec 22, 2025):
Thanks for the quick fix!
Maybe we are talking about slightly different bugs? I definitely have completely broken entries in the database. Notice how
datadoes not contain any information (it's the empty string). if it were just an un-decryptable string, it should still store the encrypted JSON payload.@BlackDex commented on GitHub (Dec 22, 2025):
I doubt it actually.
I used the same API call, though i used the web-vault and adjusted the collection and did a resend.
So either you are not sending the correct parameters/form elements, or something else strange is happening.
Maybe if you can provide the HTTP request and response that might help.
But the bug that keeping a cipher in the database upon an permission error is solved. That shouldn't happen again.
@uedvt359 commented on GitHub (Dec 22, 2025):
i've attached a minimal reproducer. it uses https://pypi.org/project/python-vaultwarden/ to handle login and crypto, but the api call in question is made "manually".
@bsv9 commented on GitHub (Jan 22, 2026):
I am encountering the same issue in the latest version (1.35.2). Could you please advise on how to resolve the broken items?
@uedvt359 commented on GitHub (Jan 22, 2026):
so do I, with 1.35.2:
@BlackDex commented on GitHub (Jan 22, 2026):
I tested the script, and it works just fine.
If you provide invalid encrypted values, than all the clients are not able to decrypt those, and will error.
I'm not sure what you expect from us for this? We can't validate these values, nor will we ever do that.
So. just provide a valid encrypted cipher and all will work just fine.
@BlackDex commented on GitHub (Jan 22, 2026):
Also, i did also test a user which does not have access to the collection to write, but only read, and it is blocked from adding a cipher, so that works without issues.