Description

Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.6, Dokploy's user.update procedure in apps/dokploy/server/api/routers/user.ts updates account.password without deleting other rows from session, allowing a compromised better-auth.session_token session to remain valid for up to three days after a password change. This issue is fixed in version 0.29.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-17T22:17:14.333Z",
  "pubdate": "2026-08-17T22:17:14.333Z",
  "executiveSummary": "A session invalidation vulnerability exists in Dokploy prior to version 0.29.6 within the user update procedure located at apps/dokploy/server/api/routers/user.ts. The vulnerability involves the failure to properly terminate existing user sessions upon updating the account password.\nWhen a user updates their password, the underlying better-auth.session_token session remains active and valid for up to three days, failing to purge associated session rows from the database.\nThis flaw impacts self-hosted Dokploy deployments and carries significant risk implications in scenarios where an attacker has already compromised a user's session token.\nAn attacker possessing a pre-existing, compromised session token can maintain unauthorized access to the affected account and underlying PaaS infrastructure even after the legitimate user performs a password reset to remediate the initial compromise.\nExploitation requires the prior compromise of a valid session token and leverages the inherent timeout window of the lingering better-auth.session_token.\nThe issue is fully resolved in version 0.29.6 by ensuring that session records are properly purged or invalidated when credential updates occur.",
  "technicalDetails": "The vulnerability resides in the user account update mechanism implemented in Dokploy, specifically within the user.update procedure located at apps/dokploy/server/api/routers/user.ts.\nThe root cause of the vulnerability is an incomplete state transition during the password modification lifecycle. While the account.password field is successfully updated with the new credential hash in the database, the procedure fails to invalidate or delete existing active sessions associated with the user account from the session storage backend utilized by better-auth.\nThe vulnerable component is the server-side tRPC router handling user modifications, specifically failing to interact with the session management subsystem to revoke active tokens upon critical security events such as credential changes.\nAffected versions include all Dokploy releases prior to version 0.29.6.\nAuthentication requirements dictate that an adversary must first obtain a valid better-auth.session_token belonging to the target user through antecedent attack vectors such as cross-site scripting (XSS), network sniffing, session hijacking, or exposure via insecure logging.\nPrivilege requirements depend on the role of the compromised session, ranging from standard user privileges to administrative access within the Dokploy PaaS environment.\nNetwork exposure is inherent to self-hosted Dokploy instances accessible via network interfaces where web applications and API routers are exposed to clients.\nThe step-by-step attack flow proceeds as follows: First, an attacker intercepts or steals a valid better-auth.session_token for a target user. Second, the legitimate user detects suspicious activity or routinely updates their password via the Dokploy web interface, triggering the vulnerable user.update procedure in apps/dokploy/server/api/routers/user.ts. Third, the backend updates the account.password attribute but leaves all existing session rows intact in the session table. Fourth, the attacker continues to issue HTTP requests to the Dokploy API using the stale better-auth.session_token. Fifth, the application accepts the persistent token as valid, bypassing the security intent of the password change.\nThe post-exploitation impact allows an unauthorized actor to maintain persistent, unauthorized access to the self-hosted PaaS environment for up to three days post-remediation, facilitating ongoing resource manipulation, application deployment compromise, or lateral movement within the underlying host infrastructure."
}