UpHeron
All vulnerabilities

Servers and applications

GHSA-8rch-pggc-942j

`ai.deploy` does not validate serverId - members can deploy to other organizations' servers

Severity
Critical 9.9
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)Missing authorization (CWE-862)
Attack
Over the network · Needs a user account · No user action needed
Attacker can
Read data · Change data · Take it down
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Sources
Project advisories (GitHub)

Description

ai.deploy checks that the caller can create services in the given project, but never checks that serverId belongs to the caller's organization. The compose row is stored with whatever serverId was sent, and compose.deploy then runs the supplied docker-compose on that server.

Tested on dokploy.com: as a member of org B, I passed the serverId of a server attached to org A. The compose deployed and ran on org A's host. I bind-mounted / and wrote a file to /tmp on the host, running as root.

On cloud serverId is required, so this is the normal path, not an edge case.

routers/ai.ts:341-366:

createComposeByTemplate inserts the row as-is (services/compose.ts:97). configFiles also go to createMount with a raw filePath that is not confined to the app directory.

Server IDs are not guessable, but they show up in normal API responses (serverId is on service/network rows) and in the other missing-authorization endpoints I reported separately.

From Dokploy/dokploy's security advisory.

Affected software

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

References