Dos CVEs críticos, una cadena de explotación completa
El 25 de septiembre de 2026 se publicaron simultáneamente dos avisos de seguridad para Dokploy, la herramienta de despliegue autoalojada alternativa a Heroku y Render. La combinación de ambos constituye la amenaza más grave que haya afectado al ecosistema PaaS autoalojado en 2026: ninguna cuenta requerida, root en el host en menos de un minuto, y toda instancia inferior a la versión 0.29.13 queda expuesta.
CVE-2026-45631 (CVSS 10.0) se refiere a un secreto JWT codificado en el código fuente. CVE-2026-72863 (CVSS 9.9) se refiere a manejadores WebSocket que autentican sin autorizar. Tomados por separado, cada uno es ya crítico. Encadenados, forman un ataque completo: el primero proporciona la identidad administrativa, el segundo proporciona la ejecución.
CVE-2026-45631 (CVSS 10.0): el secreto JWT codificado
El aviso GitHub GHSA-w3gm-rc4p-9rhj describe una vulnerabilidad de clase CWE-798 — uso de credenciales codificadas. Dokploy utiliza la librería better-auth para la gestión de sesiones y tokens JWT. En las versiones 0.27.0 a 0.29.2 inclusive, el valor por defecto de la variable BETTER_AUTH_SECRET se dejó como better-auth-secret-123456789 en el código fuente publicado en GitHub.
Este valor es el que firma todos los tokens JWT de administración de Dokploy. Quien lo conozca — y es público desde el primer commit de la versión 0.27.0 — puede falsificar un token JWT válido con derechos de administrador sin poseer ninguna cuenta en la instancia objetivo. La API de administración de Dokploy acepta entonces todas las solicitudes: lectura de todos los secretos de despliegue, ejecución de comandos vía API, modificación de configuraciones de servicios.
La puntuación CVSS 10.0 es el máximo absoluto de la escala. Refleja la ausencia total de cualquier barrera: el vector de ataque es la red, no se requiere interacción del usuario, no se necesita autenticación previa, y la confidencialidad, integridad y disponibilidad del host quedan completamente comprometidas.
Verificar si su instancia está expuesta a CVE-2026-45631
En el host de Dokploy, ejecute: grep BETTER_AUTH_SECRET /etc/dokploy/.env
Si el valor mostrado es better-auth-secret-123456789, si la variable está ausente del archivo, o si el archivo .env es anterior a la versión 0.29.3 sin haber sido regenerado: su instancia está expuesta. La versión del binario por sí sola no es suficiente — una actualización sin rotación del secreto deja el valor antiguo en su lugar.
CVE-2026-72863 (CVSS 9.9): escalada vía terminales WebSocket
El aviso GitHub GHSA-7r6p-v9gw-pwc8 describe un control de acceso insuficiente en los manejadores WebSocket que exponen los terminales Docker de Dokploy. La vulnerabilidad es de clase CWE-285 — autorización incorrecta.
Dokploy permite a cada usuario acceder a un terminal interactivo en sus contenedores vía WebSocket. La verificación implementada autenticaba al usuario — confirmaba la presencia de un token válido — pero no autorizaba: no verificaba que el servicio solicitado perteneciera efectivamente al usuario solicitante. Cualquier usuario con una cuenta válida, incluso sin derechos administrativos, podía por tanto abrir un terminal en cualquier contenedor de cualquier otro usuario.
El impacto real va más allá del contenedor. Dokploy se ejecuta con derechos root y monta el socket Docker del host (/var/run/docker.sock). Desde una shell dentro de un contenedor, el comando docker run --rm -v /:/host alpine chroot /host sh proporciona una shell root en el sistema de archivos del host. Todas las versiones inferiores a 0.29.13 están afectadas.
El escenario de ataque completo: de cero acceso a root
La cadena CVE-2026-45631 + CVE-2026-72863 constituye un ataque completo realizable desde cualquier red, sin cuenta preexistente, en dos pasos.
Paso 1 — Falsificar un token de administrador (CVE-2026-45631). El atacante conoce el valor better-auth-secret-123456789 del código fuente público. Genera un JWT firmado con este valor, reclamando el rol admin. La API de Dokploy acepta este token sin verificación adicional. El atacante dispone ahora de acceso administrativo completo: lista de todos los servicios, secretos de entorno, claves de despliegue.
Paso 2 — Acceder al terminal de un contenedor (CVE-2026-72863). Con el token admin falsificado, el atacante abre una conexión WebSocket hacia el terminal de un contenedor arbitrario. La ausente verificación de autorización deja pasar la solicitud. El atacante dispone de una shell dentro del contenedor.
Resultado — Root en el host. Con Dokploy ejecutándose como root con el socket Docker montado, el atacante pivota del contenedor al host. El sistema de archivos completo, los secretos de todos los proyectos alojados, las claves SSH y las variables de entorno de producción son accesibles. La operación no requiere ninguna interacción del operador ni ninguna cuenta preexistente.
Matriz de versiones y parches
Desplace la tabla
| CVE | CVSS | Versiones afectadas | Versión corregida | Acción requerida |
|---|---|---|---|---|
| CVE-2026-45631 | 10.0 — CRÍTICA | 0.27.0 – 0.29.2 | ≥ 0.29.3 | Actualizar + regenerar BETTER_AUTH_SECRET |
| CVE-2026-72863 | 9.9 — CRÍTICA | < 0.29.13 | ≥ 0.29.13 | Actualizar a 0.29.13 mínimo |
| Cadena completa | 10.0 efectiva | < 0.29.13 con secreto por defecto | ≥ 0.29.13 | Actualizar + rotación del secreto |
Diagnosticar su instancia antes de aplicar el parche
Antes de proceder con la actualización, evalúe con precisión la exposición de su instancia.
Verificar la versión instalada: docker exec dokploy cat /app/package.json | grep '"version"'
Si la versión mostrada es inferior a 0.29.13, su instancia es vulnerable a CVE-2026-72863. Si se encuentra entre 0.27.0 y 0.29.2, es vulnerable a ambas CVEs simultáneamente.
Verificar el valor del secreto JWT: grep BETTER_AUTH_SECRET /etc/dokploy/.env
Si el valor es better-auth-secret-123456789 o la variable está ausente, CVE-2026-45631 es activamente explotable en su instancia independientemente de la versión.
Verificar la exposición de red: si su interfaz Dokploy es accesible desde Internet sin restricción de IP (firewall, Cloudflare Access, VPN), la superficie de ataque es pública. Un atacante no necesita ningún acceso de red previo para explotar CVE-2026-45631.
Guía de actualización paso a paso a Dokploy 0.29.13
Copia de seguridad de configuración y datos
Antes de cualquier operación, cree una copia de seguridad completa.
# Copia de seguridad del directorio de configuración cp -r /etc/dokploy /etc/dokploy.bak-$(date +%Y%m%d-%H%M) # Copia de seguridad de la base de datos de Dokploy docker exec dokploy-postgres pg_dump -U dokploy dokploy > /root/dokploy-db-$(date +%Y%m%d).sqlConserve estas copias de seguridad fuera del host Dokploy — si la instancia está comprometida, las copias locales son accesibles al atacante.
Verificar la versión actual y el docker-compose.yml
Identifique el método de instalación y la versión fijada en su archivo Compose. La mayoría de instalaciones de Dokploy usan la imagen oficial
dokploy/dokploy. Si hay una etiqueta de versión fijada endocker-compose.yml, anótela.cat /etc/dokploy/docker-compose.yml | grep 'image:'Actualizar la imagen de Dokploy
Desde el directorio de configuración de Dokploy:
cd /etc/dokploy docker compose pullEste comando descarga la imagen
dokploy/dokploy:latesto la etiqueta fijada. Para fijar explícitamente la versión corregida, actualice la líneaimageendocker-compose.yml: reemplace la etiqueta existente pordokploy/dokploy:0.29.13antes de ejecutar el pull.Reiniciar los contenedores
cd /etc/dokploy docker compose down docker compose up -dEspere a que los contenedores alcancen el estado
healthyantes de continuar:docker compose psTanto Dokploy como su base de datos PostgreSQL deben mostrar
Upohealthy.Regenerar la variable BETTER_AUTH_SECRET
Este es el paso más importante y el más frecuentemente omitido. Una actualización sin rotación del secreto deja CVE-2026-45631 explotable. Genere un nuevo valor aleatorio criptográficamente seguro:
openssl rand -base64 48Copie el valor generado. Abra
/etc/dokploy/.envy reemplace la líneaBETTER_AUTH_SECRET=...con el nuevo valor. Si la variable está ausente del archivo, agréguela.Luego reinicie Dokploy para aplicar el cambio:
cd /etc/dokploy && docker compose down && docker compose up -dNota: la rotación del secreto invalida todas las sesiones activas. Los usuarios conectados deberán volver a iniciar sesión.
Verificar la versión después de la actualización
Confirme que la versión 0.29.13 o superior está en ejecución:
docker exec dokploy cat /app/package.json | grep '"version"'Verifique también que el secreto ha sido aplicado:
grep BETTER_AUTH_SECRET /etc/dokploy/.envEl valor ya no debe ser
better-auth-secret-123456789. Si lo sigue siendo, la rotación no fue aplicada — repita el paso anterior.
Medidas de endurecimiento post-parche
La actualización corrige ambas CVEs. Estas medidas adicionales reducen la superficie de ataque residual.
Restringir el acceso de red a la interfaz Dokploy. La interfaz de administración de Dokploy no tiene razón para ser accesible desde Internet. Limite el acceso al puerto 3000 (o el que utilice) a las IPs de su equipo mediante el firewall del host, o coloque Dokploy detrás de una VPN.
Activar la autenticación multifactor (MFA). Dokploy soporta TOTP desde la versión 0.28.0. Actívelo para todas las cuentas de administración.
Auditar los secretos de entorno de los proyectos. Dokploy almacena las variables de entorno de sus aplicaciones. Si la instancia estuvo expuesta durante la ventana de vulnerabilidad (versiones 0.27.0 a 0.29.12), considere que todos sus secretos de producción pueden haber sido leídos. Se recomienda rotación para claves API, tokens de base de datos y secretos de aplicación.
Socket Docker y principio de mínimo privilegio. El socket Docker montado como volumen es una superficie de ataque documentada y explotada en CVE-2026-72863. Dokploy lo necesita para funcionar, pero el acceso puede restringirse mediante políticas de proxy de socket Docker como Tecnativa/docker-socket-proxy para limitar las operaciones autorizadas.
¿Sigue siendo Dokploy confiable pese a estas CVEs?
Estas dos vulnerabilidades son graves, pero la respuesta de los mantenedores de Dokploy merece consideración antes de sacar conclusiones sobre la madurez del proyecto.
Los avisos se publicaron el 25 de septiembre de 2026. La corrección para CVE-2026-45631 estaba disponible en la versión 0.29.3, y la corrección para CVE-2026-72863 en la versión 0.29.13 — ambas en un plazo razonable tras la divulgación responsable. El proyecto mantiene un programa de seguridad mediante GitHub Security Advisories, lo que indica una madurez mínima en la gestión de vulnerabilidades.
Dokploy es un proyecto joven (primera versión estable en 2024) con una adopción rápida: más de 15.000 estrellas en GitHub y un ritmo de publicación sostenido. La presencia de un secreto codificado en las versiones iniciales refleja una deuda de seguridad típica de proyectos en fase de crecimiento rápido, donde la facilidad de instalación primó sobre el endurecimiento por defecto.
El proyecto sigue siendo una opción pertinente para equipos que quieran un PaaS autoalojado accesible, siempre que se sigan las actualizaciones de seguridad y se apliquen las medidas de endurecimiento descritas en este artículo.
Alternativas si considera migrar
Si estas vulnerabilidades le llevan a reevaluar su elección de PaaS autoalojado, aquí están las alternativas activas en este segmento.
Coolify es la alternativa más cercana en términos de funcionalidades. Código abierto, mantenido activamente, con un modelo de seguridad más maduro para la gestión de secretos (sin valor por defecto codificado documentado hasta la fecha). Su interfaz es más compleja pero su base de código es mayor y más auditada.
Caprover es una opción probada, más antigua y con un historial de seguridad más largo. Menos activo en nuevas funcionalidades pero más estable.
Portainer con stacks Docker sigue siendo un enfoque válido para equipos que no necesitan un PaaS completo. Portainer tiene sus propias CVEs históricas — notablemente en escalada de privilegios vía Docker API — pero la versión 3.x revisó su gestión de autorizaciones.
Cualquiera que sea la alternativa elegida, aplicar las mismas medidas de endurecimiento (acceso de red restringido, MFA, rotación regular de secretos) sigue siendo la línea base no negociable.
En un VPS de ServOrbit, el parche se reduce a dos comandos
Ejecutar docker compose pull && docker compose up -d desde /etc/dokploy, seguido de regenerar BETTER_AUTH_SECRET, aplica la corrección completa. En un VPS con acceso root, usted decide la ventana de mantenimiento sin depender de un proveedor. Si desplegó Dokploy mediante la plantilla ServOrbit, el archivo .env está en /etc/dokploy/ y el docker-compose.yml es el proporcionado por la plantilla.
Resumen: los puntos no negociables
CVE-2026-45631 (CVSS 10.0) y CVE-2026-72863 (CVSS 9.9) se encadenan en un ataque sin cuenta hasta root en el host. Cualquier instancia de Dokploy inferior a 0.29.13 con el secreto por defecto better-auth-secret-123456789 es compromisable desde cualquier red.
La corrección requiere dos pasos distintos y ambos obligatorios: la actualización a la versión 0.29.13 mínimo (docker compose pull && docker compose up -d), y la regeneración de BETTER_AUTH_SECRET en el archivo .env (openssl rand -base64 48). Uno sin el otro solo cierra la mitad de la superficie.
Tras la actualización, restrinja el acceso de red a la interfaz de administración, active el MFA, y si la instancia estuvo expuesta durante la ventana de vulnerabilidad, rote todos los secretos de las aplicaciones alojadas.
