¿Es seguro Vaultwarden? Cómo reforzarlo

¿Es seguro Vaultwarden? Respuesta breve

Vaultwarden es seguro en el aspecto más importante: cada elemento de la bóveda se cifra en el dispositivo antes de llegar al servidor. El servidor almacena el contenido cifrado de la bóveda junto con los metadatos de la cuenta en texto plano. Si alguien copia toda la base de datos, todavía necesita las claves de cifrado de la bóveda para leer su contenido, pero obtiene de inmediato las direcciones de correo electrónico de las cuentas y las pistas de las contraseñas.

Esa respuesta depende de muchos factores, y los puntos débiles son los que usted configura. Un panel de administración protegido sólo por un token fácil de adivinar. Un puerto del contenedor publicado en todo Internet. Un config.json en texto plano. Un archivo tar de copia de seguridad almacenado en el directorio personal del mismo equipo. Ninguno de esos problemas está relacionado con la criptografía. Todos ellos explican por qué se vacían bóvedas autohospedadas.

Todo lo siguiente presupone que ya tiene una instalación operativa. Si todavía no tiene una, configúrela primero con la guía de instalación de Vaultwarden en una VPS y después siga esta lista en orden.

Lo que realmente almacena el servidor

Vaultwarden implementa el modelo de datos de Bitwarden. El nombre, el nombre de usuario, la contraseña, las notas y las URI de un elemento de la bóveda se cifran en el cliente con una clave de elemento generada aleatoriamente antes de enviar cualquier solicitud. La clave simétrica del usuario o de la organización protege esa clave; la clave derivada de la contraseña protege la clave simétrica del usuario. El contenido de los archivos adjuntos usa una clave de adjunto independiente, protegida por la clave del elemento. El servidor recibe datos opacos asociados a un UUID (identificador único universal).

Algunos datos no son texto cifrado. Debe saber exactamente cuáles:

• La dirección de correo electrónico de la cuenta y la pista de la contraseña maestra, en texto plano.
• La configuración y la sal de la KDF (función de derivación de claves), porque el cliente las necesita para reconstruir la clave durante el siguiente inicio de sesión.
• Un hash del hash de la contraseña maestra que envía el cliente, almacenado en el servidor y utilizado para autenticar el inicio de sesión.
• Metadatos: pertenencia a organizaciones, nombres de dispositivos y horas del último inicio de sesión.
• El secreto TOTP para el inicio de sesión con autenticación de dos factores. Se almacena sin cifrar en la tabla twofactor porque el servidor tiene que calcular el código esperado y compararlo con el suyo. No es el mismo secreto TOTP (contraseña de un solo uso basada en el tiempo) que almacena dentro de un elemento de la bóveda, que se cifra como cualquier otro campo.

La carpeta de datos es pequeña. En una instalación de Docker, corresponde a la ruta que montó en /data.

sudo ls -l /vw-data/

db.sqlite3 contiene casi todo el estado. attachments/ contiene los archivos cargados en directorios con UUID, fuera de las tablas de la base de datos. sends/ contiene los archivos adjuntos de Send y está destinada a ser temporal. icon_cache/ se puede eliminar sin consecuencias. rsa_key.pem y sus archivos asociados firman los JWT (tokens web JSON) de los usuarios con una sesión iniciada, por lo que una copia de esa clave privada puede utilizarse para falsificar una sesión de acceso a la bóveda. config.json almacena la configuración guardada mediante la página de administración, incluidas las credenciales SMTP en texto plano y el valor configurado del token de administración. Si sigue las instrucciones sobre Argon2 que aparecen a continuación, se almacenará el hash del token de administración en lugar de la contraseña en texto plano.

Por tanto, el modelo de amenazas práctico se centra en el acceso al sistema de archivos, no en la criptografía de red. El acceso de lectura a ese único directorio expone las direcciones de correo electrónico de todos los usuarios, sus secretos de 2FA para el inicio de sesión, una clave capaz de falsificar sesiones y una copia sin conexión de todas las bóvedas para atacarlas sin límite de tiempo. Todos los pasos siguientes tienen como objetivo impedir el acceso a ese directorio.

Corrija primero el token de administración

/admin es un panel de control completo: lista de usuarios, invitaciones, eliminación y todos los ajustes de ejecución. Está protegido por un único secreto compartido y nada más. No hay nombre de usuario. No hay autenticación de dos factores por usuario.

Las guías antiguas indican generar ADMIN_TOKEN con openssl rand -base64 48. Funciona, pero deja el secreto en texto plano allí donde se configure. Vaultwarden también acepta una cadena PHC de Argon2 (password hashing competition), por lo que el valor almacenado es un hash. Genere una contra un contenedor en ejecución:

docker exec -it vaultwarden /vaultwarden hash

O sin tocar el contenedor en ejecución:

docker run --rm -it vaultwarden/server /vaultwarden hash

Solicita la contraseña dos veces y después muestra una línea que comienza por $argon2id$. En una instalación bare metal, ejecute ./vaultwarden hash. Si prefiere usar directamente la CLI de argon2, el proyecto documenta los parámetros mínimos de OWASP:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Ahora viene el problema que puede costar una hora. Una cadena PHC contiene muchos caracteres $, y Docker Compose interpreta $ como interpolación de variables. Si la pega sin escapar en un bloque environment:, el valor que llega al contenedor queda alterado, por lo que /admin rechaza un token que sabe que es correcto. Hay dos formas seguras. En docker-compose.yml, duplique cada $:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

En un archivo .env no es necesario escapar nada, pero debe usar comillas simples:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Después, limite la frecuencia de acceso al panel y acorte su sesión:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Esto permite una ráfaga de tres solicitudes de inicio de sesión de administración por IP de cliente y después repone el límite a razón de una solicitud cada cinco minutos. Las contraseñas correctas e incorrectas cuentan por igual, porque el limitador se ejecuta antes de comprobar la contraseña. Las solicitudes que superan el límite reciben HTTP 429 con Too many requests, try again later.. La sesión de administración caduca 20 minutos después del inicio de sesión, tanto si sigue usando el panel como si no, porque la actividad no prolonga la sesión.

Mejor aún: desactive la página. La mayoría de las instancias la necesitan una vez para configurar SMTP e invitar a los primeros usuarios, pero nunca más. Para desactivarla, no establezca ni ADMIN_TOKEN ni DISABLE_ADMIN_TOKEN, elimine cualquier clave "admin_token" de config.json y vuelva a crear el contenedor. Eliminar la clave del archivo es importante porque la página de administración escribe allí los ajustes, y lo que aparece en config.json tiene prioridad sobre el entorno. Retirar sólo la variable deja la página abierta.

Cerrar el registro antes de que alguien encuentre el dominio

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED tiene el valor predeterminado true. Si lo deja así, cualquiera que acceda al dominio obtiene una cuenta y sus datos quedan en el mismo db.sqlite3 que los suyos. Establézcalo en false y añada usuarios mediante invitaciones desde la página de administración. SMTP envía el correo de invitación. Si no está configurado, el servidor registra una invitación para esa dirección. INVITATIONS_ALLOWED también tiene el valor predeterminado true y permite que los administradores de la organización inviten a otras personas. Esto es adecuado si confía en sus usuarios. En una instancia para un solo usuario, debe estar establecido en false. Si sólo deben registrarse determinados dominios, SIGNUPS_DOMAINS_WHITELIST=example.com es más restrictivo que el registro abierto, pero mucho menos seguro que las invitaciones.

SHOW_PASSWORD_HINT tiene el valor predeterminado false y debe permanecer así. Si está activado y no ha configurado SMTP, al introducir una dirección de correo válida en el formulario de inicio de sesión se muestra la pista de la contraseña maestra de esa cuenta. Esto expone la pista y confirma que la dirección existe.

Si su instancia tuvo el registro abierto durante algún tiempo, abra la página de administración y revise la lista de usuarios antes de dar por hecho que sólo existe su cuenta.

El puerto que no pretendía publicar

La imagen de Docker escucha en el puerto 80 dentro del contenedor. Una instalación en el sistema base usa ROCKET_PORT=8000 de forma predeterminada. El comando de ejecución documentado lo publica así:

--publish 127.0.0.1:8000:80

El prefijo 127.0.0.1: es el punto clave. Si escribe -p 8000:80, Docker enlaza 0.0.0.0 y lo hace escribiendo reglas DNAT (traducción de direcciones de red de destino) en la tabla nat. Estas reglas se evalúan antes de las cadenas filter que gestiona ufw. Por eso ufw status informa de que el puerto está denegado, mientras el puerto responde normalmente desde Internet. El mecanismo completo se explica en la guía sobre los puertos de Docker que evitan ufw.

Compruebe qué está escuchando realmente:

sudo ss -tlnp | grep 8000

El resultado correcto es una sola línea enlazada a 127.0.0.1:8000. Una línea enlazada a 0.0.0.0:8000 significa que vault está expuesto directamente. Corrija la asignación y vuelva a crear el contenedor, porque la asociación de puertos se fija cuando se crea el contenedor y docker compose restart no la cambiará:

docker compose up -d --force-recreate

En las guías antiguas todavía aparece otro puerto: 3012, el puerto independiente de WebSocket. La compatibilidad con este puerto se eliminó en Vaultwarden 1.31.0 porque el tráfico de notificaciones pasó al puerto HTTP principal. WEBSOCKET_ENABLED y WEBSOCKET_PORT están obsoletos desde 1.29.0 y se ignoran. La opción actual es ENABLE_WEBSOCKET, cuyo valor predeterminado es true. Si el firewall o el archivo compose todavía abre 3012, ciérrelo.

Termine TLS en un proxy inverso, no en Rocket

Vaultwarden puede gestionar TLS (seguridad de la capa de transporte) directamente mediante Rocket, su framework web, pero el proyecto desaconseja hacerlo en producción. El soporte TLS integrado de Rocket carece de compatibilidad estricta con SNI (indicación del nombre del servidor). Por eso también se recomienda acceder a la instancia mediante un nombre de host y nunca mediante una dirección IP sin más. Los rangos de IP públicas se analizan constantemente. Un almacén que responde en una dirección IP es un almacén que se detecta.

Estas son las partes relevantes de un bloque de servidor de nginx:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx establece client_max_body_size en 1m de forma predeterminada. Sin una sobrescritura, sólo fallan los cuerpos de petición que superan ese límite. nginx devuelve HTTP 413 al cliente y registra client intended to send too large body: ... bytes. La carga rechazada no llega a Vaultwarden. Las cabeceras Upgrade y Connection transportan el handshake de WebSocket hasta /notifications/hub. Si las elimina, el almacén seguirá funcionando, pero las notificaciones de WebSocket dejarán de llegar a los clientes de navegador y de escritorio. Los clientes móviles usan notificaciones push configuradas por separado.

Caddy requiere menos configuración y obtiene el certificado por su cuenta:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Después, informe a Vaultwarden de esta configuración:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER ya tiene X-Real-IP como valor predeterminado. Por tanto, debe asegurarse de que el proxy establezca realmente esa cabecera. Vaultwarden también acepta la cabecera sólo desde las direcciones incluidas en IP_HEADER_TRUSTED_PROXIES, cuyo valor predeterminado es local: cualquier dirección que no sea global. Esto incluye un proxy en el mismo host o en la misma red de contenedores. Si el proxy se conecta desde una dirección pública, debe añadirla ahí. Si falta la cabecera o procede de una dirección no fiable, cada línea de registro y cada límite de tasa de inicio de sesión verá la dirección del propio proxy. Como resultado, los fallos de un atacante se contabilizan contra todos los usuarios de la instancia. Si usa IP_HEADER=X-Forwarded-For, 1.37.4 toma la dirección situada más a la derecha que no sea un proxy fiable. Por tanto, incluya todos los proxies de la cadena, incluido un CDN situado delante de nginx. Establezca también DOMAIN en la URL https real. Vaultwarden genera a partir de ella los enlaces de invitación y recuperación de cuentas, y las claves de seguridad WebAuthn están vinculadas a ese origen.

Hay un detalle que suele pasarse por alto: la conexión WebSocket transmite el token de sesión en la cadena de consulta, como /notifications/hub?access_token=[JWT]. Esto hace que aparezca en texto claro en el registro de acceso del proxy. Oculte el parámetro access_token en el formato del registro o asegúrese de que esos registros no se envíen a ningún lugar que no controle.

Bloquear ataques de fuerza bruta en el endpoint de inicio de sesión

Los límites de velocidad están activados de forma predeterminada (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Ralentizan al atacante. No lo detienen. fail2ban sí lo hace, pero necesita que los inicios de sesión fallidos de Vaultwarden estén en un lugar que pueda leer. En Docker, la opción sencilla es usar un archivo de registro, y Vaultwarden no lo genera de forma predeterminada:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Un inicio de sesión con contraseña incorrecta genera una línea con este formato. Esta es la cadena que debe coincidir con el filtro:

[2026-08-07 09:14:22.000][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Escriba el filtro en /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Y la jail en /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
backend = pyinotify
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Si Vaultwarden se ejecuta como un servicio de systemd en lugar de un contenedor, puede omitir LOG_FILE: la wiki de fail2ban del proyecto lee el journal con backend = systemd y utiliza un journalmatch en la unidad de Vaultwarden en lugar de logpath.

Si mantuvo la página de administración, añada una segunda jail cuyo failregex sea ^.*Invalid admin token\. IP: <ADDR>.*$, porque los fallos de administración se registran con un mensaje diferente y el filtro de inicio de sesión nunca los detectará. Después, compruebe la configuración:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Una jail operativa muestra el archivo de registro en File list e informa de Currently failed: 0. Escriba una contraseña incorrecta tres veces desde otra red. El contador aumentará y la dirección aparecerá en Banned IP list. Si el contador nunca cambia, la causa habitual es logpath: debe ser la ruta del archivo en el host, no la ruta /data/... dentro del contenedor. La segunda causa habitual es un X-Real-IP ausente o no confiable, lo que hace que todos los bloqueos afecten a su propio proxy. El resto de la configuración, incluida la jail de SSH que ya debería estar ejecutándose, se explica en la guía de fail2ban para Ubuntu 24.04.

La contraseña maestra sigue siendo la protección de todo el sistema

El cifrado del lado del cliente significa que la contraseña maestra protege la clave simétrica del usuario. Una contraseña maestra corta en una instancia cuya base de datos ha copiado un atacante no está protegida por nada de lo indicado en esta publicación, porque el atacante puede atacar esa copia sin conexión, a la velocidad que permita su hardware. Ningún ajuste del servidor llega a la máquina del atacante.

PASSWORD_ITERATIONS=600000 se puede interpretar fácilmente de forma incorrecta. Establece las iteraciones del hash del lado del servidor aplicado al hash de inicio de sesión que envía el cliente, y la plantilla de configuración del proyecto indica que un valor modificado se aplica a los usuarios existentes en su siguiente inicio de sesión. No modifica el KDF del lado del cliente, que es el ajuste que determina el coste de un ataque sin conexión contra la bóveda. Este ajuste pertenece a cada cuenta y se cambia en Settings, Security, Keys, dentro de la bóveda web; al cambiarlo, se vuelve a cifrar la clave. La documentación de Bitwarden indica que sus clientes, desde 2026.2.1, aumentan automáticamente a 600,000 iteraciones cualquier ajuste de PBKDF2 inferior a ese valor cuando el usuario inicia sesión o desbloquea la bóveda con la contraseña maestra. A fecha de 10 de octubre de 2026, este comportamiento no está confirmado en un servidor Vaultwarden y nunca modifica los ajustes de Argon2id. Por tanto, alguien que se registró hace años puede seguir usando un ajuste de KDF antiguo y más bajo. Compruébelo e informe al usuario, porque el servidor no puede hacerlo por él.

Después, habilite la autenticación de dos factores para cada cuenta. No protege el texto cifrado, porque no participa en el cifrado de la bóveda. Sí impide que una contraseña robada sea suficiente para iniciar sesión y sincronizar una copia. Con el correo electrónico configurado, REQUIRE_DEVICE_EMAIL=true hace obligatorio el correo de inicio de sesión en un dispositivo nuevo: si el envío falla, el inicio de sesión falla. Si el servicio de correo está deshabilitado por completo, este ajuste no bloquea los inicios de sesión desde dispositivos nuevos.

Los backups son donde fallan los vaults autohospedados

Un tar czf de la carpeta de datos, dejado en un directorio personal del mismo VPS, anula todos los pasos anteriores. Ese archivo contiene db.sqlite3 con el texto cifrado de todos los usuarios, rsa_key.pem que permite falsificar sesiones de inicio de sesión y config.json con el valor configurado del token de administrador y la contraseña de SMTP. Seguir las instrucciones de Argon2 almacena un hash de la contraseña de administrador; la contraseña de SMTP permanece en texto plano. El acceso de lectura a ese único archivo expone metadatos de cuentas, secretos del servidor y datos cifrados del vault.

Dos reglas cubren este caso. Saque el archivo del servidor. Cífrelo antes de transferirlo.

También existe un problema de integridad. Copiar db.sqlite3 con cp mientras el servicio está en ejecución puede producir un archivo que se está escribiendo y no se podrá abrir. No lo descubrirá hasta la restauración. Use la instantánea propia de SQLite:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

La restauración, que es la parte que casi nadie prueba, se explica en la guía de backup y restauración de Vaultwarden.

Lo que deja de ofrecer frente a Bitwarden alojado

Una evaluación honesta. El servicio alojado de Bitwarden lo operan personas cuyo trabajo a tiempo completo es administrarlo y cuenta con auditorías de terceros publicadas. El autoalojamiento sustituye ese modelo por su propio ciclo de aplicación de parches.

Vaultwarden publica correcciones de seguridad como versiones normales, y lo hace con frecuencia. Comprobado el 2 de noviembre de 2026 en el feed de versiones del proyecto, la versión actual es la 1.37.5, publicada el 1 de noviembre de 2026. Sus notas cubren dos avisos de seguridad de gravedad Medium y recomiendan encarecidamente actualizar cuanto antes. Esta versión también es necesaria para activar o desactivar métodos de inicio de sesión en dos pasos en web vault 2026.7.1 y posteriores, y para tomar el control de una cuenta mediante acceso de emergencia en 2026.9.0 y posteriores. La versión anterior, 1.37.4, publicada el 5 de octubre de 2026, cubría siete avisos de seguridad; el más grave tenía una calificación High. Fue la cuarta versión desde 1.37.0, publicada el 24 de julio de 2026: 1.37.1 llegó el 29 de julio, 1.37.2 el 22 de agosto (necesaria para clientes con versión 2026.8.0 y posteriores) y 1.37.3 el 13 de septiembre. Esta última revoca los tokens de 2FA remember cuando cambian las credenciales o 2FA y limita la tasa de los endpoints de solicitud prelogin y auth. Si administra organizaciones con administradores en los que no confía plenamente, las notas de 1.37.4 también recomiendan rotar la clave de API de cada organización después de actualizar. 1.37.4 también cambia la dirección que se lee de X-Forwarded-For, como se explica en la sección anterior sobre el proxy inverso. Una instancia que configuró hace un año y olvidó sigue ejecutando código de hace un año. La etiqueta latest no basta por sí sola: un contenedor en ejecución conserva la imagen con la que se inició hasta que ejecuta docker compose pull y lo vuelve a crear. Configure actualizaciones desatendidas en Ubuntu para los paquetes del host y programe la actualización del contenedor en un recordatorio del calendario que realmente vaya a leer.

La conclusión que debería extraer un lector honesto es la siguiente: la criptografía sigue el diseño de Bitwarden y es sólida, pero el riesgo operativo recae por completo en usted. Si aplica los parches y mantiene una copia de seguridad en otra ubicación, una instancia de Vaultwarden en un VPS bajo su control es un lugar razonable para guardar sus contraseñas. Si no va a mantener esos dos hábitos, pague el servicio alojado y dedique su atención a otra cosa. La comparación función por función está en Vaultwarden comparado con Bitwarden autoalojado.

Refuerce el host subyacente al contenedor

Vaultwarden es un proceso más en un sistema Linux, y root en ese sistema puede leer /vw-data independientemente de la configuración de la aplicación. Ejecute el contenedor con un usuario sin privilegios mediante user: "1000:1000" en el archivo compose y asigne la propiedad de la carpeta de datos para que coincida. Monte como solo lectura todo lo que el contenedor no necesite modificar mediante :ro. Después cierre la puerta de entrada: Refuerzo de SSH en un VPS explica cómo usar el inicio de sesión exclusivamente con claves y deshabilitar la autenticación mediante contraseña. Esto evita el ataque básico que supera todas las medidas anteriores.

FAQ

¿Puede alguien leer mis contraseñas si roba la base de datos de Vaultwarden?

No directamente. Cada elemento de la bóveda se cifra en el cliente con una clave generada aleatoriamente, protegida mediante la clave simétrica del usuario o de la organización; la clave derivada de la contraseña protege la clave simétrica del usuario. db.sqlite3 contiene el contenido cifrado de la bóveda junto con metadatos de cuenta en texto claro. El atacante obtiene de inmediato la dirección de correo electrónico y la pista de contraseña de cada cuenta, la configuración de KDF, los metadatos de inicio de sesión y de dispositivos, y los secretos TOTP de inicio de sesión de la tabla twofactor, que se almacenan sin cifrar porque el servidor debe calcular el código esperado. También puede atacar el texto cifrado de la bóveda sin conexión durante todo el tiempo que quiera. Por eso, la longitud de la contraseña maestra es el factor que determina el resultado.

¿Debo usar ADMIN_TOKEN o desactivar por completo la página de administración?

Desactívela si puede, porque la mayoría de las instancias sólo la necesitan una vez para configurar SMTP e invitar a usuarios. Después no vuelven a necesitarla. Para desactivarla, no establezca ni ADMIN_TOKEN ni DISABLE_ADMIN_TOKEN, elimine cualquier clave "admin_token" de config.json y vuelva a crear el contenedor. Eliminar sólo la variable de entorno no basta, porque la configuración escrita por la página de administración se almacena en config.json y tiene prioridad. Si mantiene la página, almacene el token como un hash Argon2 generado por vaultwarden hash en lugar de una cadena aleatoria en texto claro, y establezca ADMIN_RATELIMIT_MAX_BURST=3.

Mi ADMIN_TOKEN es correcto, pero /admin lo rechaza. ¿Cuál es el problema?

Casi siempre se debe a la interpolación de $. Una cadena PHC de Argon2 contiene varios caracteres $, y Docker Compose los expande como variables dentro de un bloque docker-compose.yml environment:. Por eso, el contenedor recibe un valor alterado aunque el archivo parezca correcto. Duplique cada $ como $$ en el archivo compose, o mueva el valor a un archivo .env entre comillas simples, donde no es necesario escapar caracteres. Después vuelva a crear el contenedor, porque los cambios de entorno no se aplican al reiniciar.

¿Todavía necesito abrir el puerto 3012 para las notificaciones?

No. La compatibilidad con el tráfico WebSocket en el puerto 3012 se eliminó en Vaultwarden 1.31.0 porque las notificaciones pasaron al puerto HTTP principal. Además, WEBSOCKET_ENABLED y WEBSOCKET_PORT están obsoletos desde 1.29.0 y se ignoran. La configuración actual es ENABLE_WEBSOCKET, cuyo valor predeterminado es true. Cierre el puerto 3012 en el firewall y elimínelo del archivo compose. Después, compruebe que el proxy inverso reenvíe las cabeceras Upgrade y Connection, porque las notificaciones WebSocket del navegador y del cliente de escritorio dependen de ellas. Los clientes móviles usan notificaciones push configuradas por separado.