All vulnerabilities

Servers and applications

GHSA-q2x3-gch7-6g53

Cross-organization API key via better-auth /api/auth/api-key/create (client-set metadata.organizationId)

Severity
Medium 5.4
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 some data · Change some data
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Sources
Project advisories (GitHub)

Description

The better-auth apiKey plugin's own HTTP endpoint POST /api/auth/api-key/create is enabled. It accepts client-supplied metadata, and Dokploy trusts metadata.organizationId to pick the organization context for the key. The tRPC wrapper user.createApiKey checks that the caller is a member of that organization; the native endpoint does not. Any authenticated user can mint a key bound to an organization they do not belong to. validateRequest then builds a session with activeOrganizationId set to that organization and role defaulting to "member" even though no membership row exists. Every protectedProcedure that scopes data only by ctx.session.activeOrganizationId then serves the foreign organization's data.

  • Attacker has any account on the instance (here: a plain member of organization B only).
  • Attacker knows the victim organization id (org ids are not secret in the sense of being access-controlled; how hard they are to obtain was not assessed).
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