Sharing credentials to an organization might cripple the entry so that it is lost good #2223

New Issue

Closed

opened 2025-10-09 17:51:54 +03:00 by OVERLORD · 13 comments

OVERLORD commented 2025-10-09 17:51:54 +03:00

Owner

Copy Link

Originally created by @bassarf on GitHub.

As the headline describes I unfortunately found a way to cripple entries so that they are lost for good.
When you edit an item without synching after you shared that item on a different devices to an organization, every entry field in this item is filled with "[error: cannot decrypt]" and the item is broken from now on

Steps to reproduce

I used the web vault and the android app

1. create some test item (it doesn't really matter where)
2. sync the android app
3. login to the web vault and share this item to an organization and maybe a collection
4. without synching the android app open the item and make some edit (e.g. change the name of the item, or the username)
5. See how your item gets destroyed

I tried the same thing with the bitwarden web vault and at Step 5. instead of the item getting destroyed I get an error popup message saying:

An Error occured
Organization mismatch. Re-sync if you recently shared this item, then try again

and no changes to the item was made.

My guess is that, since organization items are encrypted differently, some check on the server side isn't made here and the app is not stopped and therefore trying something which it shouldn't

Worth mentioning

As you can cripple your items for good, I would categorize this as quite critical. And although it may not be a widespread issue, it is not a hypothetical either. I myself did cripple an item this way :-(
Since you cannot share items inside the app, I opened the web vault on my phone. Shared the item. After I closed the browser I decided to rename the item for better understanding (in the app) which broke it.

While troubleshooting this issue I also found that the web vault does not refresh as often as the original vault. (Having the vault open in a browser and adding an item on the phone, the item does show up without doing a manual refresh on the original server)

Originally created by @bassarf on GitHub. As the headline describes I unfortunately found a way to cripple entries so that they are lost for good. When you edit an item without synching after you shared that item on a different devices to an organization, every entry field in this item is filled with "[error: cannot decrypt]" and the item is broken from now on ### Steps to reproduce I used the web vault and the android app 1. create some test item (it doesn't really matter where) 1. sync the android app 1. login to the web vault and share this item to an organization and maybe a collection 1. without synching the android app open the item and make some edit (e.g. change the name of the item, or the username) 1. See how your item gets destroyed I tried the same thing with the bitwarden web vault and at Step 5. instead of the item getting destroyed I get an error popup message saying: > An Error occured > Organization mismatch. Re-sync if you recently shared this item, then try again and no changes to the item was made. My guess is that, since organization items are encrypted differently, some check on the server side isn't made here and the app is not stopped and therefore trying something which it shouldn't ### Worth mentioning As you can cripple your items for good, I would categorize this as quite critical. And although it may not be a widespread issue, it is not a hypothetical either. I myself did cripple an item this way :-( Since you cannot share items inside the app, I opened the web vault on my phone. Shared the item. After I closed the browser I decided to rename the item for better understanding (in the app) which broke it. While troubleshooting this issue I also found that the web vault does not refresh as often as the original vault. (Having the vault open in a browser and adding an item on the phone, the item does show up without doing a manual refresh on the original server)

OVERLORD added the bug label 2025-10-09 17:51:54 +03:00

OVERLORD closed this issue 2025-10-09 17:51:55 +03:00

OVERLORD commented 2025-10-09 17:51:57 +03:00

Author

Owner

Copy Link

@bassarf commented on GitHub:

Damnit. Closed the issue by accident

@bassarf commented on GitHub: Damnit. Closed the issue by accident

OVERLORD commented 2025-10-09 17:51:58 +03:00

Author

Owner

Copy Link

@dani-garcia commented on GitHub:

I think this is easy to solve, as far as I know, there is no way for an organization cipher to return to a user, so if the cipher in the database has an organization id, but the cipher data that the user sends in an update doesn't, then we can assume that the client is using outdated data and we can reject it.

I'll test it and see if that works.

@dani-garcia commented on GitHub: I think this is easy to solve, as far as I know, there is no way for an organization cipher to return to a user, so if the cipher in the database has an organization id, but the cipher data that the user sends in an update doesn't, then we can assume that the client is using outdated data and we can reject it. I'll test it and see if that works.

OVERLORD commented 2025-10-09 17:51:58 +03:00

Author

Owner

Copy Link

@mprasil commented on GitHub:

Thanks for submitting the issue, it looks like we need to check whether the client submitted cipher has the owner set to himself while the one in the DB is already owned by organization.

As a side note for the web vault refresh speed, you can enable websockets and that should make the Vault refresh instant.

@mprasil commented on GitHub: Thanks for submitting the issue, it looks like we need to check whether the client submitted cipher has the owner set to himself while the one in the DB is already owned by organization. As a side note for the web vault refresh speed, you can enable [websockets](https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-WebSocket-notifications) and that should make the Vault refresh instant.

OVERLORD commented 2025-10-09 17:51:58 +03:00

Author

Owner

Copy Link

@bassarf commented on GitHub:

Thanks for the quick response. I will checkout enabling websockets. Thanks for the hint

@bassarf commented on GitHub: Thanks for the quick response. I will checkout enabling websockets. Thanks for the hint

OVERLORD commented 2025-10-09 17:51:59 +03:00

Author

Owner

Copy Link

@dani-garcia commented on GitHub:

Ok, that fixed it for me. This is patched now in 484bf5b703. Can you test if this works for you?

@dani-garcia commented on GitHub: Ok, that fixed it for me. This is patched now in https://github.com/dani-garcia/bitwarden_rs/commit/484bf5b703fa85b61580ffb34f59768c4bd200b1. Can you test if this works for you?

OVERLORD commented 2025-10-09 17:52:00 +03:00

Author

Owner

Copy Link

@bassarf commented on GitHub:

I don't know how to test it easily. I have not set up anything else than the docker container for mprasil/bitwarden:raspberry. Is there an easy way to test this for me (without cloning and building my own image and setting up a testing environment)?

But I had a look at the code and without diving to much into everything, I think it looks good.
Since not only there is no way for an organization cipher to return to a user but also an item cannot be shared to more than one organization the cipher.organization_uuid.is_some() && data.OrganizationId.is_none() should be enough.

And just to be sure of my understanding of the code. The reverse check for: cipher.organization_uuid.is_none() && data.OrganizationId.is_some() would only make sense if an item would be able to be "unshared" and return to the user, correct?

in the original repository I found the following snippet ( 8596ba2caa/src/Api/Controllers/CiphersController.cs (L165) ):

var modelOrgId = string.IsNullOrWhiteSpace(model.OrganizationId) ? 
                (Guid?)null : new Guid(model.OrganizationId);
            if(cipher.OrganizationId != modelOrgId)
            {
                throw new BadRequestException("Organization mismatch. Re-sync if you recently shared this item, " +
                    "then try again.");
}

So its similar but there is a != check. Maybe one can switch the organization? Or maybe against two clients sharing the same item at the same time to different organizations.

@bassarf commented on GitHub: I don't know how to test it easily. I have not set up anything else than the docker container for `mprasil/bitwarden:raspberry`. Is there an easy way to test this for me (without cloning and building my own image and setting up a testing environment)? But I had a look at the code and without diving to much into everything, I think it looks good. Since not only there is no way for an organization cipher to return to a user but also an item cannot be shared to more than one organization the `cipher.organization_uuid.is_some() && data.OrganizationId.is_none()` should be enough. And just to be sure of my understanding of the code. The reverse check for: `cipher.organization_uuid.is_none() && data.OrganizationId.is_some()` would only make sense if an item would be able to be "unshared" and return to the user, correct? in the original repository I found the following snippet ( https://github.com/bitwarden/core/blob/8596ba2caa208109f54d98789e79fca356681451/src/Api/Controllers/CiphersController.cs#L165 ): ``` var modelOrgId = string.IsNullOrWhiteSpace(model.OrganizationId) ? (Guid?)null : new Guid(model.OrganizationId); if(cipher.OrganizationId != modelOrgId) { throw new BadRequestException("Organization mismatch. Re-sync if you recently shared this item, " + "then try again."); } ``` So its similar but there is a `!=` check. Maybe one can switch the organization? Or maybe against two clients sharing the same item at the same time to different organizations.

OVERLORD commented 2025-10-09 17:52:00 +03:00

Author

Owner

Copy Link

@bassarf commented on GitHub:

I was able to pull the new build. But unfortunately the issue is not fixed. Or rather: another issue occurs:
When trying so share a test-login to an organization through the web vault, I get an error message.
Instead of the item being shared I get the new "organization missmatch" error. Which is plausible since, the organizations do missmatch as soon as I want to share it.

@bassarf commented on GitHub: I was able to pull the new build. But unfortunately the issue is not fixed. Or rather: another issue occurs: When trying so share a test-login to an organization through the web vault, I get an error message. Instead of the item being shared I get the new "organization missmatch" error. Which is plausible since, the organizations do missmatch as soon as I want to share it.

OVERLORD commented 2025-10-09 17:52:00 +03:00

Author

Owner

Copy Link

@mprasil commented on GitHub:

I've triggered builds for docker images with the latest code. @bassarf there are some other builds in the pipe before the raspberry build so it will take a while, but in about 4h from now, you should be able to just pull and run the latest raspberry image and test if it works as expected. From a quick look at the code it seems like it should fix the problem you're observing.

@mprasil commented on GitHub: I've triggered builds for docker images with the latest code. @bassarf there are some other builds in the pipe before the raspberry build so it will take a while, but in about 4h from now, you should be able to just pull and run the latest raspberry image and test if it works as expected. From a quick look at the code it seems like it should fix the problem you're observing.

OVERLORD commented 2025-10-09 17:52:01 +03:00

Author

Owner

Copy Link

@dani-garcia commented on GitHub:

Currently there is no way to way to move a cipher between organizations or back to the user as far as I know. And yes, the reverse option would apply in an unshare scenario.

But it's true that a user could share the cipher to two organizations, I didn't consider that option. It would be quite improbable for a user to do that, but I changed the check to match what upstream is doing, which is probably a safer idea. (432be274ba)

I think we can consider this fixed, it may be a good idea to create a new release because this issue can be quite problematic.

Thanks for your report, @bassarf!

@dani-garcia commented on GitHub: Currently there is no way to way to move a cipher between organizations or back to the user as far as I know. And yes, the reverse option would apply in an unshare scenario. But it's true that a user could share the cipher to two organizations, I didn't consider that option. It would be quite improbable for a user to do that, but I changed the check to match what upstream is doing, which is probably a safer idea. (https://github.com/dani-garcia/bitwarden_rs/commit/432be274ba2aac070af1d91c684cb7b70014175f) I think we can consider this fixed, it may be a good idea to create a new release because this issue can be quite problematic. Thanks for your report, @bassarf!

OVERLORD commented 2025-10-09 17:52:01 +03:00

Author

Owner

Copy Link

@bassarf commented on GitHub:

[...] but I changed the check to match what upstream is doing, which is probably a safer idea.

I think so, too

Thanks for your report, @bassarf!

And thank you for your quick response and the quick fix of the issue.

you should be able to just pull and run the latest raspberry image and test if it works as expected.

Alright, thank you. I will test it in the next couple of days (hopefully), and report back if everything works for me.

@bassarf commented on GitHub: > [...] but I changed the check to match what upstream is doing, which is probably a safer idea. I think so, too > Thanks for your report, @bassarf! And thank _you_ for your quick response and the quick fix of the issue. > you should be able to just pull and run the latest raspberry image and test if it works as expected. Alright, thank you. I will test it in the next couple of days (hopefully), and report back if everything works for me.

OVERLORD commented 2025-10-09 17:52:02 +03:00

Author

Owner

Copy Link

@mprasil commented on GitHub:

The PR is now merged. I've tested the fix locally, I can see I'm now getting the error when trying to update the shared item without syncing first. I could also share items to org. Going to close this now. Feel free to reopen if you still spot any issue.

There are builds triggered, the raspberry image should be ready in about 4 hours.

@mprasil commented on GitHub: The PR is now merged. I've tested the fix locally, I can see I'm now getting the error when trying to update the shared item without syncing first. I could also share items to org. Going to close this now. Feel free to reopen if you still spot any issue. There are builds triggered, the raspberry image should be ready in about 4 hours.

OVERLORD commented 2025-10-09 17:52:02 +03:00

Author

Owner

Copy Link

@mprasil commented on GitHub:

I've submitted a PR to fix this. The code didn't handle the case when the cipher is actually shared, where it makes sense the org_ids won't match.

@mprasil commented on GitHub: I've submitted a PR to fix this. The code didn't handle the case when the cipher is actually shared, where it makes sense the org_ids won't match.

OVERLORD commented 2025-10-09 17:52:03 +03:00

Author

Owner

Copy Link

@bassarf commented on GitHub:

Just want to report back, that this issue, as well as #343 is solved for me.
But I created a new one ;-) #344 where a problem occurs when you create an item and during the initial creation process you assign a folder

@bassarf commented on GitHub: Just want to report back, that this issue, as well as #343 is solved for me. But I created a new one ;-) #344 where a problem occurs when you create an item and during the initial creation process you assign a folder

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

test_dylint

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels

better for forum

bug

bug

bug

documentation

duplicate

enhancement

future Vault

good first issue

help wanted

low priority

notes

pull-request

Mirrored from GitHub Pull Request

question

SSO

Third party

troubleshooting

troubleshooting

wontfix

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

OVERLORD

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#2223