Security: GitHub provider secrets returned in plaintext from application.one / github.one API responses
Summary
The Dokploy API returns GitHub App credentials — private key, client secret, and webhook secret — in plaintext within the response body of routine read end
points (e.g. application.one, and any endpoint that hydrates the associated github provider record). Any user or token with read access to an application can there
fore exfiltrate the credentials needed to impersonate the GitHub App and forge/replay webhook deliveries.
This is a privilege-escalation and credential-exposure issue: read access to an application should not equal full takeover of the connected GitHub App.
Impact
An actor with a Dokploy API token (or session) scoped only to read applications can:
- Recover the GitHub App private key → mint installation tokens → read/write any repository the App is installed on (code, issues, PRs, releases, secrets the App
can touch).
- Recover the client secret → complete OAuth flows as the App against any user who authorizes it.
- Recover the webhook secret → forge signed webhook payloads to any Dokploy endpoint (or downstream consumer) that verifies HMAC against this secret, triggering a
rbitrary deployments / pipeline actions.
Severity: High — full compromise of the connected GitHub App from a low-privilege Dokploy read.
Reproduction
- Configure a GitHub provider in Dokploy and connect an application to it.
- Authenticate to the Dokploy API with any token that has read access to the application (member-level is sufficient).
- Call
application.one (or fetch the application via the UI's underlying tRPC call) for that application ID.
- Observe that the response payload includes the full
github provider object with githubPrivateKey, githubClientSecret, and githubWebhookSecret fields populat
ed in cleartext.
The same fields are also returned by direct provider-read endpoints (github.one, github.githubProviders).
Expected behavior
Secret material should never be returned in API responses used for general read/hydration. Specifically:
githubPrivateKey, githubClientSecret, and githubWebhookSecret (and the equivalent fields on GitLab / Bitbucket / Gitea providers) should be redacted by defau
lt — e.g. returned as null, "***", or omitted from the serializer.- A separate, explicitly-scoped endpoint (e.g.
github.revealSecret) should be required to retrieve secret values, gated by:
- An elevated permission distinct from "read application," and
- A fresh re-auth or step-up (password / 2FA) confirmation, and
- Audit logging of every reveal.
- The same redaction should apply in any nested hydration paths (
application.one, compose.one, project trees, search responses, etc.).
Security: GitHub provider secrets returned in plaintext from
application.one/github.oneAPI responsesSummary
The Dokploy API returns GitHub App credentials — private key, client secret, and webhook secret — in plaintext within the response body of routine read end
points (e.g.
application.one, and any endpoint that hydrates the associatedgithubprovider record). Any user or token with read access to an application can therefore exfiltrate the credentials needed to impersonate the GitHub App and forge/replay webhook deliveries.
This is a privilege-escalation and credential-exposure issue: read access to an application should not equal full takeover of the connected GitHub App.
Impact
An actor with a Dokploy API token (or session) scoped only to read applications can:
can touch).
rbitrary deployments / pipeline actions.
Severity: High — full compromise of the connected GitHub App from a low-privilege Dokploy read.
Reproduction
application.one(or fetch the application via the UI's underlying tRPC call) for that application ID.githubprovider object withgithubPrivateKey,githubClientSecret, andgithubWebhookSecretfields populated in cleartext.
The same fields are also returned by direct provider-read endpoints (
github.one,github.githubProviders).Expected behavior
Secret material should never be returned in API responses used for general read/hydration. Specifically:
githubPrivateKey,githubClientSecret, andgithubWebhookSecret(and the equivalent fields on GitLab / Bitbucket / Gitea providers) should be redacted by default — e.g. returned as
null,"***", or omitted from the serializer.github.revealSecret) should be required to retrieve secret values, gated by:application.one,compose.one, project trees, search responses, etc.).