starred/vaultwarden
1
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-02-05 00:29:40 +03:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Server crash if an entry redirecting to a large file exists #531

New Issue
Closed
opened 2026-02-04 21:26:11 +03:00 by OVERLORD · 1 comment
OVERLORD commented 2026-02-04 21:26:11 +03:00
Owner
Copy Link

Originally created by @aschereT on GitHub (Dec 19, 2019).

Subject of the issue

Bitwarden server crashing when opening the Web Vault. The server's MEM usage would quickly skyrocket to several gigabytes, causing the server to run out of memory and crash.
I suspected one of my login items was causing this. I managed to narrow it down to a login with the url http://code.runnable.com, which redirects to a 1GB file. top in the container shows all the threads trying to download at the same time?

Let me know if there's anything else needed, or if something I forgot to add/was wrong!

Your environment

  • Bitwarden_rs version: 2.12.1
  • Install method: Docker image / Docker-compose
  • Clients used: Wb Vault
  • Reverse proxy and version: nginx (https://hub.docker.com/r/linuxserver/letsencrypt:latest as of today)
  • Version of mysql/postgresql: Default SQLite
  • Other relevant information:
    Server has CPU: Pentium G3258 and 7GB of RAM. Ubuntu Server 19.10.

Steps to reproduce

  1. Spin up bitwarden container
  2. Open an ssh session into the server and run docker stats
  3. Open an ssh session into the server and run docker exec -it bitwarden sh, then run top
  4. Open an ssh session into the server and be ready to run docker kill bitwarden
  5. Login to the web vault
  6. Add a login entry with http://code.runnable.com as the URL
  7. Watch bitwarden MEM usage rocket to the moon
  8. Kill it

Expected behaviour

Bitwarden uses MEM responsibly, and not try to download a 1GB file to memory with all of its threads.

Actual behaviour

Bitwarden takes over all the MEM and kills the server

Relevant logs

Screenshot from 2019-12-18 13-26-56
Image taken seconds before server goes MIA

Originally created by @aschereT on GitHub (Dec 19, 2019). <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unneccessary for your issue, feel free to remove them. Remember to hide/obfuscate personal and confidential information, such as names, global IP/DNS adresses and especially passwords, if neccessary. --> ### Subject of the issue Bitwarden server crashing when opening the Web Vault. The server's `MEM` usage would quickly skyrocket to several gigabytes, causing the server to run out of memory and crash. I suspected one of my login items was causing this. I managed to narrow it down to a login with the url `http://code.runnable.com`, which redirects to a 1GB file. top in the container shows all the threads trying to download at the same time? Let me know if there's anything else needed, or if something I forgot to add/was wrong! ### Your environment * Bitwarden_rs version: 2.12.1 * Install method: Docker image / Docker-compose * Clients used: Wb Vault * Reverse proxy and version: nginx (https://hub.docker.com/r/linuxserver/letsencrypt:latest as of today) * Version of mysql/postgresql: Default SQLite * Other relevant information: Server has CPU: Pentium G3258 and 7GB of RAM. Ubuntu Server 19.10. ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start bitwarden_rs? --> 1. Spin up bitwarden container 2. Open an ssh session into the server and run `docker stats` 3. Open an ssh session into the server and run `docker exec -it bitwarden sh`, then run top 4. Open an ssh session into the server and be ready to run `docker kill bitwarden` 5. Login to the web vault 6. Add a login entry with `http://code.runnable.com` as the URL 7. Watch bitwarden `MEM` usage rocket to the moon 8. Kill it ### Expected behaviour Bitwarden uses `MEM` responsibly, and not try to download a 1GB file to memory with all of its threads. ### Actual behaviour Bitwarden takes over all the `MEM` and kills the server ### Relevant logs <!-- Share some logfiles, screenshots or output of relevant programs with us. --> ![Screenshot from 2019-12-18 13-26-56](https://user-images.githubusercontent.com/12742227/71124622-1ccb7f00-219a-11ea-9dea-16a48c410740.png) <img width="1440" alt="Image taken seconds before server goes MIA" src="https://user-images.githubusercontent.com/12742227/71124993-ee9a6f00-219a-11ea-8580-c92d8dc9eee1.png">
OVERLORD commented 2026-02-04 21:26:18 +03:00
Author
Owner
Copy Link

@dani-garcia commented on GitHub (Dec 19, 2019):

Very interesting case! I never expected a URL to point to a huge file like that. I limited it now to 512 KB which should be more than enough to download any HTML page. (2545469713)

The images are being built now, and should be all finished by tomorrow. Thanks!

@dani-garcia commented on GitHub (Dec 19, 2019): Very interesting case! I never expected a URL to point to a huge file like that. I limited it now to 512 KB which should be more than enough to download any HTML page. (https://github.com/dani-garcia/bitwarden_rs/commit/25454697130a2bcbb76f7f29cdf8d1d382de96c7) The images are being built now, and should be all finished by tomorrow. Thanks!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
troubleshooting
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#531
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?