Servers and applications
GHSA-jph3-c3v5-2v4j
Incomplete deployment IDOR fix exposes unowned logs and records
- Severity
- Medium 5.3
- Published
- 12 Nov 2026
- Last changed
- 12 Nov 2026
- Added to UpHeron
- 12 Nov 2026
- Fixed in
- 0.31.1
- Attack
- Over the network · Needs a user account · No user action needed
- Attacker can
- Read some data · Change some data · Slow it down
- CVSS vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N- Sources
- Project advisories (GitHub)
Description
Deployment logs and deletion should require access to the service or server that owns the deployment, including when ownership is reachable only through a backup, preview, volume backup, or schedule.
Dokploy's deployment handlers authorize rows only when applicationId or composeId is set directly, plus one special case for schedules with serverId.
Deployments created for preview builds, database backups, volume backups, server setup, and application/Compose schedules do not store those direct IDs. Their owner is reachable through previewDeploymentId, backupId, volumeBackupId, serverId, or the schedule's application/Compose relation. deployment.readLogs and deployment.removeDeployment never resolve those relationships, so any authenticated caller with a deployment ID reaches the log reader or deletion sink without an authorization check. For a direct server deployment, readLogs then trusts deployment.serverId and reads the foreign log over SSH.
Affected software
| Software | Affected versions |
|---|---|
DokployServers and applications · github:dokploy/dokploy |
|
References
- GitHub Advisory Database https://github.com/advisories/GHSA-jph3-c3v5-2v4j
- github.com https://github.com/Dokploy/dokploy/security/advisories/GHSA-jph3-c3v5-2v4j