UpHeron
All vulnerabilities

Servers and applications

GHSA-f6j7-hvv3-8jwm

"Access to API" permission not enforced server-side in user.createApiKey

Severity
Medium 4.3
Published
12 Nov 2026
Last changed
12 Nov 2026
Added to UpHeron
12 Nov 2026
Fixed in
0.31.1
Weakness
Incorrect authorization (CWE-863)
Attack
Over the network · Needs a user account · No user action needed
Attacker can
Change some data
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Sources
Project advisories (GitHub)

Description

The per-member "Access to API" toggle (canAccessToAPI, resolved as api: ["read"]) only hides the API keys UI. user.createApiKey is a plain protectedProcedure with no permission check, and API-key authentication does not check api: read either. A member whose admin has explicitly denied API access can still mint a non-expiring API key and use it.

  • Attacker is a member of an organization with "Access to API" disabled (the default for new members).
  • user.getPermissions for the member: api: {"read": false}.
  • user.createApiKey succeeded and returned a key with expiresAt: null.
  • The key authenticated REST calls with the member's permissions (e.g. user.get, server.getServerMetrics).
  • After the member signed out (session cookie now returns Unauthorized), the key still worked.
  • An admin cannot actually prevent a member from getting programmatic API access.
  • The member obtains a long-lived credential that is independent of their session. Using it does not go through the 2FA challenge.
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