CVE-2026-45631: Dokploy Takeover Risk
Critical CVSS (10.0) reachable over network.
TL;DR - CVE-2026-45631 is a critical, unauthenticated Dokploy vulnerability caused by a predictable Better Auth secret. - Dokploy
0.27.0through0.29.2are affected; upgrade to0.29.3or later and rotate secrets. - No confirmed in-the-wild exploitation or CISA KEV listing was identified, but internet-exposed instances require immediate attention.
Summary
CVE-2026-45631 is a critical Dokploy vulnerability that enables unauthenticated attackers to forge email-verification JSON Web Tokens (JWTs), obtain administrative access, and use Dokploy’s built-in SSH terminal to execute commands on the underlying host.
Dokploy is an open-source, self-hostable platform-as-a-service product used to deploy and manage applications. The issue is rated CVSS 10.0, or critical. The retrieved NVD information does not provide a reliable CVSS vector string, so individual vector components should not be inferred beyond the documented unauthenticated attack path and potential host-level command execution.
Administrators tracking broader critical vulnerability activity can also review this critical cyber risk digest.
| Field | Value |
|---|---|
| CVE | CVE-2026-45631 |
| Product | Dokploy dokploy |
| CVSS | 10.0, Critical |
| Attack vector | Network-based; unauthenticated access is described |
| Authentication required | None |
| Privileges required | None to initiate the attack |
| Impact | Administrative access and host command execution |
| Affected versions | >= 0.27.0 and < 0.29.3 |
| Fixed version | 0.29.3 |
| Patch available | Yes |
| CWE | CWE-798, Use of Hard-coded Credentials |
| CISA KEV | No listing identified |
Administrators should treat any affected Dokploy instance with an internet-accessible management interface as high risk. The absence of confirmed exploitation does not reduce the technical impact: a known fallback secret creates a direct path from unauthenticated network access to administrative control and command execution.
Analyst’s Take: Patch internet-facing Dokploy instances first, then rotate credentials accessible from those hosts. The absence of a confirmed campaign or CISA KEV listing does not change the fact that the documented fallback secret connects unauthenticated access to administrative command execution.
Root Cause
The root cause is a hardcoded fallback value for the BETTER_AUTH_SECRET used by Dokploy’s Better Auth integration:
better-auth-secret-123456789
Authentication systems use signing secrets to validate that tokens were issued by a trusted application. If every vulnerable installation can fall back to a known value, an attacker can generate tokens that appear cryptographically valid to the application. The problem is not merely weak password policy; it undermines the trust boundary used by the authentication workflow.
According to the vulnerability description, the predictable secret can be used to forge email-verification JWTs. Those forged tokens can support automatic administrative sign-in. Once an attacker is recognized as an administrator, Dokploy’s built-in SSH terminal provides a route to execute commands on the host.
The impact chain is significant:
- The attacker reaches the Dokploy authentication surface without credentials.
- The attacker forges an email-verification JWT using the known fallback secret.
- Dokploy accepts the forged token and permits administrative sign-in.
- The attacker accesses the built-in terminal.
- Commands execute on the Dokploy host, potentially exposing deployed workloads, credentials, containers, and cloud resources.
The issue is categorized as CWE-798: Use of Hard-coded Credentials. Defenders should not assume that manually setting a separate application secret is sufficient unless the installation is upgraded and its secret-management configuration is verified. A vulnerable application may still contain or use the unsafe fallback path.
Who’s Exposed
The affected product is Dokploy dokploy. Based on the available advisory information, the affected range is:
| Product | Affected range | Fixed version |
|---|---|---|
Dokploy dokploy |
>= 0.27.0 and < 0.29.3 |
0.29.3 |
In practical terms, Dokploy versions 0.27.0, 0.27.x, 0.28.x, and 0.29.0 through 0.29.2 should be considered affected. The prescribed remediation is to upgrade to Dokploy 0.29.3 or later. The available research does not establish that every earlier or later release is affected outside the stated range, so administrators should use the vendor’s release and deployment documentation when validating versions.
Exposure is highest when the Dokploy management interface is reachable from the public internet. Internet accessibility is not required for impact if an attacker can reach the service through a compromised internal network, VPN, cloud security-group path, reverse proxy, or another trusted access route. Self-hosted deployments should also be assessed for indirect exposure through public DNS records, load balancers, ingress controllers, and firewall rules.
Dokploy hosts may contain or provide access to deployment credentials, container registries, source-control tokens, cloud API keys, database passwords, SSH keys, environment variables, and application source code. Organizations should assess not only the Dokploy service itself but also every workload and external system managed from the affected host.
Severity Breakdown
CVE-2026-45631 has a reported CVSS score of 10.0, placing it in the critical severity category. The available NVD response did not include a CVSS vector string. Therefore, a complete vector breakdown, including the exact values for scope, confidentiality, integrity, and availability, cannot be reported reliably.
The known technical characteristics explain the critical assessment:
| Severity characteristic | Assessment |
|---|---|
| Authentication | No authentication is required to begin the attack |
| Network reachability | The attack is performed against the Dokploy service over the network |
| Secret protection | A predictable hardcoded fallback is used for token signing |
| Access gained | Administrative sign-in may be forged |
| Post-authentication capability | Built-in SSH terminal permits host command execution |
| Potential impact | Host, deployed workloads, and accessible credentials may be compromised |
The vulnerability should be prioritized based on exploitability and asset exposure rather than CVSS alone. An instance bound only to a protected management network presents less immediate exposure than one published directly to the internet, but both remain affected until upgraded.
The combination of authentication bypass and command execution means that traditional perimeter controls may provide only partial protection. A web application firewall might not recognize a forged token as malicious because the request can resemble a legitimate authentication flow. Network restriction, upgrade, secret rotation, and post-compromise investigation should therefore be applied together.
Exploitation Status
No reliable evidence reviewed for this assessment confirms active exploitation of CVE-2026-45631 in the wild. The CVE is also not listed in the CISA Known Exploited Vulnerabilities catalog based on the available data. There is no CISA date added, due date, or ransomware-campaign designation for this CVE.
A public exploit or independent proof of concept is likewise not confirmed in the reviewed sources. The vendor and NVD references describe the vulnerability and remediation, and the hardcoded secret is documented, but those references should not be treated as proof that a separate weaponized exploit is publicly available.
| Question | Current assessment |
|---|---|
| Is exploitation confirmed in the wild? | No reliable confirmation identified |
| Is CVE-2026-45631 in CISA KEV? | No |
| Is an independent public PoC confirmed? | No confirmed PoC in the reviewed sources |
| Is exploitation technically plausible? | Yes, because the fallback secret and attack path are documented |
| Required operational response | Immediate patching and exposure review |
The lack of confirmed exploitation should not be interpreted as a safe-to-wait signal. A known signing secret and an unauthenticated route to administrative command execution make this vulnerability attractive for opportunistic scanning. Defenders should assume that public-facing affected instances may be discovered and targeted, even though a specific campaign has not been confirmed.
Sources
The primary CVE record is the NVD entry for CVE-2026-45631:
Vendor-maintained remediation and advisory references include:
Dokploy’s product and instance documentation provides deployment context and information about authentication-secret configuration:
CISA KEV status should be checked against the current catalog during triage:
Based on the reviewed sources, CVE-2026-45631 is a critical unauthenticated authentication-bypass-to-host-command-execution vulnerability. Dokploy versions 0.27.0 through 0.29.2 should be upgraded to 0.29.3 or later immediately, followed by secret and credential rotation and a focused compromise assessment.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Begin by inventorying Dokploy deployments and identifying versions from 0.27.0 through 0.29.2. Check container image tags, deployment manifests, package metadata, release information, and the running service rather than relying solely on documentation or an asset-management record. Pay particular attention to instances behind reverse proxies or shared ingress infrastructure.
For potentially exposed systems, investigate authentication events involving unusual email-verification activity, administrator sign-ins without a corresponding normal enrollment process, new administrator accounts, and access to the built-in terminal. Correlate application logs with reverse-proxy, firewall, container-runtime, SSH, and host process telemetry. A successful attack may leave evidence outside the Dokploy application log, especially if the attacker used the terminal to launch commands or access containers.
Technical Notes
Log field names vary by Dokploy version and deployment architecture, so the following searches are starting points rather than guaranteed vendor-specific signatures. Search reverse-proxy and application logs for authentication and verification routes, then correlate the source address and timestamp with administrator sessions:
grep -Ei \
'email.?verif|verify|jwt|token|login|sign.?in|admin|terminal|ssh' \
/var/log/nginx/access.log /var/log/nginx/error.log 2>/dev/null
If logs are collected in a structured store, an example Splunk-style query is:
index=web OR index=dokploy
(
uri_path="*verify*" OR
uri_path="*login*" OR
uri_path="*terminal*" OR
uri_path="*ssh*"
)
| stats count min(_time) as first_seen max(_time) as last_seen
values(uri_path) as paths
values(user) as users
by src_ip, http_status
| where paths!="-"
Review for suspicious sequences: an unauthenticated verification request, rapid administrative sign-in, immediate terminal access, and commands or child processes launched by the Dokploy container or host service. The exact endpoint names and log fields are not established in the available research, so absence of a matching string is not evidence that the system was not accessed.
On the host, inspect process creation, shell history where available, container execution records, modified files, new SSH keys, and outbound connections. Look for unexpected commands launched by the Dokploy service account, including shells, download utilities, interpreters, archive tools, and credential-discovery activity. Preserve logs and disk evidence before rebuilding if incident response is required.
Remediation Steps
Upgrade every affected Dokploy deployment to version 0.29.3 or later. The fixed version is the minimum target identified in the available advisory material. Do not stop at changing the fallback secret on an unpatched installation; the application must be updated so the vulnerable authentication behavior is removed or corrected.
The precise Dokploy upgrade command depends on how the instance was installed. For Docker Compose deployments, update the Dokploy image reference in the deployment configuration to 0.29.3 or a later approved release, then recreate the service:
# Review the current deployment before changing it
docker compose config
docker compose images
# After updating the Dokploy image tag in compose.yaml or .env:
docker compose pull dokploy
docker compose up -d --force-recreate dokploy
# Confirm the running image and health state
docker compose ps
docker inspect "$(docker compose ps -q dokploy)" \
--format '{{.Config.Image}}'
The service name or image name may differ by installation. Administrators should follow their deployment’s documented upgrade procedure and verify that the running container, not merely the configuration file, reports 0.29.3 or later.
After upgrading, generate and configure a strong, unique authentication secret through the supported Dokploy secret-management mechanism. Dokploy documentation indicates that older installations may not have the dokploy_auth_secret Docker secret. Review the instance configuration and migrate older deployments to the current secret-management model rather than relying on the vulnerable fallback.
A generic Docker secret workflow may resemble the following, but administrators must adapt it to the official Dokploy deployment definition and avoid replacing a secret without understanding its effect on existing sessions:
openssl rand -base64 48 > dokploy_auth_secret
chmod 600 dokploy_auth_secret
# Use the generated value with the supported Dokploy secret
# configuration, then redeploy the service.
docker compose up -d --force-recreate dokploy
Do not paste generated secrets into shell history, tickets, public repositories, or unencrypted configuration. Because changing a signing secret may invalidate sessions or tokens, schedule the operation and require administrators to authenticate again.
Treat affected internet-facing systems as potentially compromised. Rotate credentials accessible from the Dokploy host, including deployment keys, cloud credentials, registry passwords, source-control tokens, API keys, database passwords, SSH keys, and application secrets. Review administrator accounts, revoke unknown sessions, inspect deployed workloads, and compare host and application files against known-good versions.
Reduce attack surface after remediation. Place the Dokploy management interface behind a trusted network boundary, VPN, identity-aware proxy, or restrictive firewall policy. Limit administrative access to required operators, enable centralized authentication and logging where supported, and maintain an inventory of Dokploy versions and exposed management endpoints. Organizations reviewing host and automation security can also consult this runner hardening guide.