CVE-2026-43917 Overview
CVE-2026-43917 affects Dokploy, a free, self-hostable Platform as a Service (PaaS). The vulnerability exists in the protectedProcedure middleware in versions 0.19.0 and earlier. The middleware verifies that a user is authenticated but does not enforce organization scoping. Authenticated users from one organization can interact with resources belonging to other organizations across numerous endpoints. This is classified as an Insecure Direct Object Reference flaw under [CWE-639].
Critical Impact
Authenticated tenants can read, modify, and delete deployments, backups, volumes, cluster nodes, and mounts owned by other organizations sharing the same Dokploy instance.
Affected Products
- Dokploy 0.19.0
- Dokploy versions prior to 0.19.0
- Self-hosted Dokploy PaaS deployments with multiple organizations
Discovery Timeline
- 2026-05-29 - CVE CVE-2026-43917 published to NVD
- 2026-05-29 - Last updated in NVD database
Technical Details for CVE-2026-43917
Vulnerability Analysis
Dokploy uses a tRPC-style protectedProcedure middleware to gate access to authenticated routes. The middleware confirms a valid session exists but does not compare the requested resource's organizationId against the session's activeOrganizationId. Each downstream endpoint is responsible for performing that check, and many endpoints omit it. An authenticated user who knows or guesses a resource identifier can call these endpoints and operate on resources belonging to another tenant.
The affected endpoints span several router files. In deployment.ts, the allByType, killProcess, and removeDeployment procedures expose deployment data and runtime control. In rollbacks.ts, the delete procedure allows removal of rollback records. In backup.ts, create, one, update, remove, manualBackupPostgres, manualBackupMySql, manualBackupMariadb, manualBackupMongo, manualBackupCompose, manualBackupWebServer, and listBackupFiles are exposed. In volume-backups.ts, list, one, delete, update, runManually, and restoreVolumeBackupWithLogs are affected. In cluster.ts, getNodes, removeWorker, addWorker, and addManager permit cluster manipulation. The create procedure in mount.ts is also affected.
Root Cause
The root cause is missing authorization. The shared middleware short-circuits at authentication and never enforces multi-tenant isolation. Individual procedures do not validate that the target resource's organization matches the caller's active organization, which violates the principle of complete mediation.
Attack Vector
An attacker needs a valid Dokploy account on a shared instance and the identifier of a target resource. The attacker invokes any affected endpoint over the network with that identifier. The server processes the request because the session is authenticated, returning data or executing the requested action against the cross-tenant resource. No user interaction from the victim is required.
Verified code examples are not available for this advisory. Refer to the GitHub Security Advisory GHSA-f8wj-5c4w-frhg for the maintainer's technical description.
Detection Methods for CVE-2026-43917
Indicators of Compromise
- Application logs showing tRPC calls to deployment.allByType, backup.listBackupFiles, or cluster.getNodes where the resource's organizationId differs from the caller's activeOrganizationId.
- Unexpected invocations of killProcess, removeDeployment, or volume-backups.delete from accounts that do not own the targeted resources.
- Cluster membership changes through addWorker, addManager, or removeWorker originating from users outside the cluster's owning organization.
Detection Strategies
- Instrument the protectedProcedure middleware to log the session activeOrganizationId alongside the resolved resource's organizationId on every call, and alert on mismatches.
- Review historical access logs for the affected procedures in deployment.ts, backup.ts, volume-backups.ts, cluster.ts, rollbacks.ts, and mount.ts to identify prior cross-tenant access.
- Correlate database write events for backups, mounts, and cluster nodes against the issuing user's organization membership.
Monitoring Recommendations
- Forward Dokploy application and audit logs to a centralized SIEM for cross-tenant correlation and retention.
- Build dashboards that surface per-user volumes of calls to backup, volume, and cluster mutation endpoints.
- Alert on unauthenticated-to-authenticated transitions followed by immediate access to resources outside the user's primary organization.
How to Mitigate CVE-2026-43917
Immediate Actions Required
- Upgrade Dokploy to a release later than 0.19.0 that includes the fix referenced in advisory GHSA-f8wj-5c4w-frhg.
- Restrict account creation on shared Dokploy instances and audit existing organization memberships.
- Rotate any secrets, backup credentials, or deployment tokens that may have been exposed through the affected endpoints.
Patch Information
Dokploy maintainers have published guidance in the GitHub Security Advisory GHSA-f8wj-5c4w-frhg. Operators should apply the fixed version and verify that every affected procedure now compares the resource's organizationId against the session's activeOrganizationId before executing.
Workarounds
- Operate single-tenant Dokploy instances per organization until the patch is applied to eliminate cross-tenant exposure.
- Place the Dokploy API behind a reverse proxy that enforces per-organization path or header restrictions where feasible.
- Disable or network-restrict the affected backup, volume-backups, cluster, and mount routes until upgrade is complete.
# Configuration example
# Verify the running Dokploy version and upgrade beyond 0.19.0
docker inspect dokploy --format '{{ .Config.Image }}'
docker pull dokploy/dokploy:latest
docker compose up -d dokploy
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


