All vulnerabilities

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
Weakness
Authorization bypass through a user-controlled key (IDOR) (CWE-639)
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.

From Dokploy/dokploy's security advisory. Shortened; the full text is there.

Affected software

SoftwareAffected versions
DokployServers and applications · github:dokploy/dokploy
  • Every version before 0.31.1

References