[GH-ISSUE #515] Admin page is available even without ADMIN_TOKEN #323

Closed
opened 2026-03-03 01:27:59 +03:00 by kerem · 4 comments
Owner

Originally created by @poblabs on GitHub (Jun 27, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/515

I admit I'm a bit new to bitwarden_rs, so I'm still trying to figure it out. I'm running this in a docker container on my Synology and it's working great.

I do not have the ADMIN_TOKEN, nor DISABLE_ADMIN_TOKEN environment variables specified, yet /admin is available to me without authentication.

Anything I'm missing? I would assume that page would be disabled if I wasn't explicitly defining something with those environment variables.

Here's the version from the header of the admin page: Version: 1.9.1-3fb63bbe

Originally created by @poblabs on GitHub (Jun 27, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/515 I admit I'm a bit new to bitwarden_rs, so I'm still trying to figure it out. I'm running this in a docker container on my Synology and it's working great. I **do not** have the `ADMIN_TOKEN`, nor `DISABLE_ADMIN_TOKEN` environment variables specified, yet `/admin` is available to me without authentication. Anything I'm missing? I would assume that page would be disabled if I wasn't explicitly defining something with those environment variables. Here's the version from the header of the admin page: `Version: 1.9.1-3fb63bbe`
kerem 2026-03-03 01:27:59 +03:00
Author
Owner

@mprasil commented on GitHub (Jun 27, 2019):

which docker image are you using - based on the version hash, it seems to be the latest version of bitwardenrs/server, is that right? Can you describe steps to reproduce it?

Have you at any stage set the admin token via the admin interface? These settings are saved into a configuration file, so your ADMIN_TOKEN can be still set there even if you removed the environment variable.

<!-- gh-comment-id:506430457 --> @mprasil commented on GitHub (Jun 27, 2019): which docker image are you using - based on the version hash, it seems to be the latest version of `bitwardenrs/server`, is that right? Can you describe steps to reproduce it? Have you at any stage set the admin token via the admin interface? These settings are saved into a configuration file, so your ADMIN_TOKEN can be still set there even if you removed the environment variable.
Author
Owner

@poblabs commented on GitHub (Jun 27, 2019):

which docker image are you using - based on the version hash, it seems to be the latest version of bitwardenrs/server, is that right?

That's right. I downloaded it last night. The version hash looks like your latest server commit hash.

Can you describe steps to reproduce it?

I installed the image, started a container, and was able to browse to http://<IP>/admin without any challenge. No variables are defined which would enable the admin page (according to the wiki docs).

EDIT: After answering the questions below, perhaps the variables are cached/saved.

Have you at any stage set the admin token via the admin interface?

Yes, I set it once to test it out. Ran into some issues, so I stopped the container, removed the variable, restarted the container. So this makes sense - however if the variable is saved in a cache file, I question why I'm not being challenged?

Note: I also did set DISABLE_ADMIN_TOKEN as well at one point - but I have since removed it. Where I feel I should be right now is with a disabled admin page.

Where are these variables cached? I'll be curious to try and find/remove them and see how it goes.

<!-- gh-comment-id:506433019 --> @poblabs commented on GitHub (Jun 27, 2019): > which docker image are you using - based on the version hash, it seems to be the latest version of bitwardenrs/server, is that right? That's right. I downloaded it last night. The version hash looks like your latest server commit hash. > Can you describe steps to reproduce it? ~~I installed the image, started a container, and was able to browse to `http://<IP>/admin` without any challenge. No variables are defined which would enable the admin page (according to the wiki docs).~~ **EDIT**: After answering the questions below, perhaps the variables are cached/saved. > Have you at any stage set the admin token via the admin interface? Yes, I set it once to test it out. Ran into some issues, so I stopped the container, removed the variable, restarted the container. So this makes sense - however if the variable is saved in a cache file, I question why I'm not being challenged? Note: I also did set `DISABLE_ADMIN_TOKEN` as well at one point - but I have since removed it. Where I feel I should be right now is with a disabled admin page. Where are these variables cached? I'll be curious to try and find/remove them and see how it goes.
Author
Owner

@mprasil commented on GitHub (Jun 28, 2019):

The settings done in the admin interface are by default stored in the data folder into config.json file. They do override any environment variable settings, so if there's something there, removing ADMIN_TOKEN won't do anything really.

<!-- gh-comment-id:506722321 --> @mprasil commented on GitHub (Jun 28, 2019): The settings done in the admin interface are by default stored in the data folder into `config.json` file. They do override any environment variable settings, so if there's something there, removing `ADMIN_TOKEN` won't do anything really.
Author
Owner

@poblabs commented on GitHub (Jun 28, 2019):

Ok, thanks. In my config.json I see "disable_admin_token": true,. Setting this to false disabled the admin page. I guess I'm all set. Thanks for the insight.

<!-- gh-comment-id:506738905 --> @poblabs commented on GitHub (Jun 28, 2019): Ok, thanks. In my config.json I see ` "disable_admin_token": true,`. Setting this to false disabled the admin page. I guess I'm all set. Thanks for the insight.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#323
No description provided.