CVE-2026-86059

Executive Summary

CVE-2026-86059 is an information disclosure vulnerability in Dokploy, a free self-hostable Platform as a Service (PaaS), affecting all versions prior to 0.29.13. Organization members who lack explicit Git provider access can retrieve plaintext Git provider credentials — including GitHub App private keys, OAuth tokens, client secrets, webhook secrets, and app passwords — because protected backend procedures return full provider rows without applying per-member access controls (getAccessibleGitProviderIds) or an organization check. With a CVSS 3.1 base score of 9.6, the flaw allows a low-privileged authenticated member to bypass per-member provider assignment and abuse the exposed credentials to access private repositories or manipulate external workflows.

Technical Analysis

Dokploy organizes tenants into organizations and links them to external Git providers (GitHub, GitLab, Gitea, Bitbucket). The application is intended to restrict which provider credentials a given member can reach via per-member assignment logic. According to the NVD description, four protected procedures — github.one, gitlab.one, gitea.one, and bitbucket.one — return "full provider rows" without applying getAccessibleGitProviderIds or an organization check. The result is a broken access control (authorization) failure that manifests as sensitive data exposure, classified CWE-200.

The secondary exposure path is the application.one route, which returns nested GitHub, GitLab, Gitea, and Bitbucket relations sourced from findApplicationById. Those nested objects include GitHub App private keys, OAuth tokens, client secrets, webhook secrets, and app passwords — and are returned "even when hasGitProviderAccess is false." In other words, the access-control predicate (hasGitProviderAccess) exists and is evaluated, but does not gate the serialization of the sensitive nested relations.

Root cause class: the application enforces provider-level authorization for interactive UI actions but fails to enforce the same authorization at the data-access/fetch layer. Any member with application read access, or any member who can supply a provider identifier, can reach the underlying records. The trust boundary that must be protected is the plaintext credential material stored for each provider; the vulnerable flow leaks it directly to a lower-privileged principal.

Concretely, the vulnerable properties are:

• Missing authorization filter (getAccessibleGitProviderIds) on the .one provider-query procedures.
• Missing organization scoping on the same procedures.
• Missing or incorrect enforcement of hasGitProviderAccess on nested provider relations returned by findApplicationById.

No public proof-of-concept, Nuclei template, or exploit code is available. The mechanics above are stated at the level provided in the NVD description; no function names, endpoints, or parameters beyond those quoted are asserted.

Exploitation Scenarios

No public PoC available; attack chain is inferred from the vulnerability class (broken access control leading to credential disclosure).

1. Reconnaissance / target identification. The attacker identifies a self-hosted Dokploy instance (public-facing PaaS control panel) and obtains a low-privileged account as a member of an existing organization. Membership alone is sufficient — the attacker does not need Git provider assignment or elevated roles. Shodan-style discovery of exposed Dokploy instances via HTTP title, body markers, and favicon hash supports mass identification.

2. Triggering the flaw. Using the authenticated member session, the attacker invokes the protected provider-query procedures (github.one, gitlab.one, gitea.one, bitbucket.one) or the application.one route backed by findApplicationById. Because these procedures do not apply getAccessibleGitProviderIds or an organization check, the responses include complete provider records with plaintext secrets rather than a filtered, member-scoped view. For the application.one path, the attacker needs only application read access or a valid provider identifier; the nested Git provider relations are still returned even though hasGitProviderAccess is false.

3. Payload / execution method (vulnerability-class level). This is a data-disclosure attack, not code execution: the "payload" is a legitimate-looking authenticated read request to the affected procedures. The authorization bypass occurs server-side as the procedure serializes full provider rows to the caller.

4. Post-exploitation impact. The attacker extracts GitHub App private keys, OAuth tokens, client secrets, webhook secrets, and app passwords. These credentials can be used to access private repositories (source code, CI configuration, infrastructure-as-code secrets) and to manipulate external Git workflows (webhooks, OAuth app actions, app installations). Because the CVSS vector specifies Scope:Changed, compromises can pivot from Dokploy into external SCM platforms and their downstream pipelines, and because Integrity impact is High, the attacker may push, alter, or tamper with code and workflow definitions outside the Dokploy trust boundary.

Impact Assessment

CVSS 3.1 base score: 9.6 (CRITICAL). Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N.

• Attack Vector (N): exploitable remotely over the network against the Dokploy API.
• Attack Complexity (L): no special preconditions or race conditions; a straightforward authenticated read succeeds.
• Privileges Required (L): a valid low-privileged organization member account is sufficient.
• User Interaction (N): no victim interaction required.
• Scope (C): Changed — compromise of Dokploy can affect resources in other security authorities (external Git providers and their pipelines).
• Confidentiality (H): full plaintext credentials and repository metadata exposed.
• Integrity (H): exposed tokens/keys permit modification of external repositories and workflow manipulation.
• Availability (N): no direct availability impact from the disclosure itself.

Business impact: any organization running Dokploy < 0.29.13 with one or more connected Git providers is at risk. A single member account (including contractor/multi-tenant scenarios) can harvest credentials that unlock private source code, CI/CD secrets, and SaaS integrations. Blast radius extends beyond the Dokploy instance into every repository and automated workflow authenticated by the leaked credentials, making this a high-severity supply-chain and IP-loss risk. Multi-tenant and shared PaaS deployments have the largest exposure.

Detection Guidance

Sigma Rule

title: Dokploy Unauthorized Git Provider Credential Retrieval (CVE-2026-86059)
id: 8a3f1c2e-7b64-4f1a-9d2e-cve202686059
status: experimental
description: Detects low-privileged organization members retrieving full Git provider rows via Dokploy provider-query or application procedures without per-member Git provider access.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-86059
author: valtersit.com
logsource:
  product: dokploy
  service: web
detection:
  selection_proc:
    cs-method: 'GET'
    url|contains:
      - 'github.one'
      - 'gitlab.one'
      - 'gitea.one'
      - 'bitbucket.one'
      - 'application.one'
  selection_unauthz:
    hasGitProviderAccess: 'false'
  selection_cred_fields:
    response_body|contains:
      - 'privateKey'
      - 'clientSecret'
      - 'webhookSecret'
      - 'appPassword'
      - 'accessToken'
  condition: selection_proc and (selection_unauthz or selection_cred_fields)
fields:
  - src_ip
  - user
  - url
  - hasGitProviderAccess
falsepositives:
  - Legitimate provider administrators with valid provider assignments
level: critical
tags:
  - attack.t1078
  - attack.t1213
  - cve.2026.86059

YARA Rule

rule CVE_2026_86059_Dokploy_Credential_Disclosure
{
    meta:
        description = "Detects Dokploy responses/config containing plaintext Git provider secrets tied to CVE-2026-86059"
        cve = "CVE-2026-86059"
        author = "valtersit.com"
        date = "2026-01-01"
        severity = "critical"
    strings:
        $p1 = "getAccessibleGitProviderIds" nocase
        $p2 = "hasGitProviderAccess" nocase
        $p3 = "findApplicationById" nocase
        $n1 = "github.one" nocase
        $n2 = "gitlab.one" nocase
        $n3 = "gitea.one" nocase
        $n4 = "bitbucket.one" nocase
        $s1 = "privateKey" nocase
        $s2 = "clientSecret" nocase
        $s3 = "webhookSecret" nocase
        $s4 = "appPassword" nocase
        $s5 = "accessToken" nocase
    condition:
        (any of ($p1, $p2, $p3) or any of ($n1, $n2, $n3, $n4)) and
        (2 of ($s*))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-86059 Dokploy Git Provider Credential Disclosure Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"github.one"; http.uri; content:"gitlab.one"; http.uri; content:"gitea.one"; http.uri; content:"bitbucket.one"; http.uri; content:"application.one"; pcre:"/(github|gitlab|gitea|bitbucket|application)\.one/"; classtype:attempted-recon; sid:2026860591; rev:1; metadata:cve CVE-2026-86059, severity critical;)

Note: Suricata content matching above uses non-anchored OR-style alternatives for documentation; deployment should split into one rule per procedure (github.one, gitlab.one, gitea.one, bitbucket.one, application.one) for reliable detection. Response-side detection of exposed secret fields (privateKey, clientSecret, webhookSecret) should be added with flow:established,to_client and http.response_body inspection.

Elastic Detection

sequence by user.name, source.ip with maxspan=1m
  [ network where
      http.request.method == "GET" and
      (
        url.path like "*github.one*" or
        url.path like "*gitlab.one*" or
        url.path like "*gitea.one*" or
        url.path like "*bitbucket.one*" or
        url.path like "*application.one*"
      ) ]
  [ file where
      rule.name : "CVE-2026-86059 Dokploy Git Provider Credential Disclosure" ]

Splunk SPL Query

index=proxy OR index=web
| eval url = coalesce(url, uri_path)
| where match(url, "(github|gitlab|gitea|bitbucket|application)\.one")
| rex field=url "(?<route>(github|gitlab|gitea|bitbucket|application)\.one)"
| stats count min(_time) as first_seen max(_time) as last_seen values(route) as routes by src_ip, user, status
| where status=200
| table first_seen, last_seen, src_ip, user, routes, count, status
| sort - count

Wazuh OSSEC Rule

<group name="dokploy,web,cve-2026-86059">
  <rule id="100959" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">github\.one|gitlab\.one|gitea\.one|bitbucket\.one|application\.one</field>
    <description>CVE-2026-86059: Potential unauthorized Dokploy Git provider credential retrieval by low-privileged member</description>
    <mitre>
      <id>T1078</id>
      <id>T1213</id>
    </mitre>
    <group>access_control,credential_access,</group>
  </rule>

  <rule id="100960" level="14">
    <if_sid>100959</if_sid>
    <field name="response_body">privateKey|clientSecret|webhookSecret|appPassword</field>
    <description>CVE-2026-86059: Dokploy response contains plaintext Git provider secrets (private keys/tokens)</description>
    <group>data_leak,credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations (until a verified fix is deployed):

• Restrict Dokploy management interfaces from untrusted networks; place the API/control plane behind VPN, IP allowlisting, or a reverse proxy with authentication.
• Enforce strict, minimal organization membership. Remove stale, contractor, or read-only accounts that do not require Git provider access, since a single low-privileged member is sufficient to trigger the flaw.
• Reduce the number of connected Git providers and scope existing provider credentials to the minimum required permissions. Prefer short-lived, fine-grained tokens over long-lived secrets and rotate all GitHub App private keys, OAuth client secrets, webhook secrets, and app passwords connected to Dokploy.
• Monitor/alert on github.one, gitlab.one, gitea.one, bitbucket.one, and application.one access from members without provider assignments (see detection rules above).
• Treat all currently stored provider credentials as potentially compromised and rotate them proactively.

2. Patch/upgrade steps:

• Upgrade Dokploy to version 0.29.13 or later, which per the NVD description resolves the issue. No vendor advisory URL or commit hash is tracked by available sources; confirm the release notes for 0.29.13 directly from the Dokploy project before deployment.
• After upgrading, verify that github.one, gitlab.one, gitea.one, bitbucket.one now apply getAccessibleGitProviderIds and organization checks, and that application.one/findApplicationById no longer returns provider secrets when hasGitProviderAccess is false.
• Rotate every provider credential again post-upgrade as a precaution.

3. Long-term hardening:

• Adopt defense-in-depth for authorization: enforce object-level access control at the data-access layer, not only in UI flows, so serialization cannot bypass checks.
• Apply least-privilege for connected SCM credentials and regularly review provider assignments per member and per organization.
• Enable audit logging on both Dokploy and the connected Git providers (GitHub/GitLab/Gitea/Bitbucket) to detect credential abuse and anomalous repository/workflow activity.
• Integrate CVE and dependency monitoring into change management to catch future Dokploy advisories early.

References

• NVD — CVE-2026-86059: https://nvd.nist.gov/vuln/detail/CVE-2026-86059
• Dokploy project (vendor): https://dokploy.com / https://github.com/Dokploy/dokploy
• CWE-200: Exposure of Sensitive Information to an Unauthorized Actor — https://cwe.mitre.org/data/definitions/200.html
• FIRST EPSS: not yet scored for CVE-2026-86059 (no EPSS value available at time of writing)
• CISA Known Exploited Vulnerabilities Catalog: CVE-2026-86059 is NOT listed (no known exploitation in the wild as of this report)

No public proof-of-concept, exploit code, or Nuclei template is available. No threat actor campaign or exploit-in-the-wild evidence is currently associated with CVE-2026-86059.