UpHeron
All vulnerabilities

Servers and applications

GHSA-h52x-gwf8-4h58

Cross-organization project takeover via `project.update`

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)Mass assignment (CWE-915)
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

The project.update endpoint lets the caller set organizationId. The permission check looks at the project's current organization, and only after that does the update write whatever fields were sent, including the new organizationId.

So anyone who can update a project can move it into any other organization. There is no approval step on the receiving side, and no transfer feature in the product that this would be part of. The field is simply writable because the update schema accepts every column on the projects table.

I verified this on dokploy.com with two free accounts of my own: one API request moved a project from account A's organization into account B's organization. B was never asked. I moved it back afterwards.

A project in Dokploy contains environments, services, environment variables (secrets), domains, mounts, and schedules. Whoever owns the project's organization can read all of it.

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