☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Dokploy logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 8 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H 🐛 CWE-269
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-45790

CVE-2026-45790 Vulnerability in Dokploy
📅 PUBLISHED: 2026-08-17 00:00 UTC 🔄 UPDATED: 2026-09-23 20:16 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.28%
👁️
0.28% probability
7.1× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1098
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
Country: Global License: Open Source
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 8.0
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: L Privileges Required Low
UI: R User Interaction Required
S: U Scope Unchanged
C: H Confidentiality High
I: H Integrity High
A: H Availability High
8.0
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-45790 describes a critical improper privilege management vulnerability affecting Dokploy, a free self-hostable Platform as a Service (PaaS), in versions prior to 0.29.6. This flaw allows a low-privileged user to escalate their privileges to an owner role, or a privileged self-hosted user to create an account with an arbitrary role, ultimately leading to permanent organization takeover due to the inability to demote owner roles. The vulnerability is assigned a CVSS v3.1 score of 8.0 (High).

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

Dokploy versions prior to 0.29.6 are susceptible to a privilege escalation and account takeover vulnerability (CWE-269: Improper Privilege Management). This vulnerability manifests through two distinct but related attack vectors, both leading to the creation or assignment of an undemotable "owner" role.

The first vector resides within the organization.inviteMember tRPC procedure, located in the file apps/dokploy/server/api/routers/organization.ts. This procedure, intended for inviting new members to an organization, fails to adequately enforce privilege separation. Specifically, a user possessing the member:create permission, which is typically considered a low-level administrative permission, can exploit this procedure to invite a new or existing account and assign it the highly privileged owner role. The critical flaw here is the inadequate validation of the requested role against the inviter's permissions.

The second vector is found in packages/server/src/services/user.ts. This component allows a privileged self-hosted user to create new user accounts and assign them an arbitrary role. This implies a lack of granular permission checks or robust input validation during the account creation process, enabling the self-hosted user to bypass intended role restrictions.

The severe impact stems from Dokploy's design where accounts assigned the owner role cannot be subsequently demoted. This characteristic, combined with the ability to illicitly assign this role, allows for permanent organization takeover. Once an attacker gains an owner account, they possess complete control over the Dokploy instance and its hosted services, with no straightforward mechanism for legitimate administrators to revoke these elevated privileges.

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H reflects the vulnerability's characteristics:

  • AV:N (Attack Vector: Network): The vulnerability is exploitable over the network, indicating remote access is possible.
  • AC:L (Attack Complexity: Low): Exploiting this flaw does not require specialized conditions or sophisticated techniques.
  • PR:L (Privileges Required: Low): Only a low-privileged user (specifically, one with member:create permission or a privileged self-hosted user) is needed to initiate the attack.
  • UI:R (User Interaction: Required): This typically refers to user interaction on the victim's part (e.g., clicking a malicious link, accepting an invite) or the attacker interacting with the application's interface/API. In the inviteMember scenario, it could refer to the invited user accepting the role.
  • S:U (Scope: Unchanged): The vulnerability does not change the security scope of the affected component.
  • C:H (Confidentiality Impact: High): Complete loss of confidentiality, as the attacker gains full access to all data.
  • I:H (Integrity Impact: High): Complete loss of integrity, allowing the attacker to modify or delete any data or configurations.
  • A:H (Availability Impact: High): Complete loss of availability, as the attacker can disable or disrupt services.

Exploitation Scenarios

Exploitation of CVE-2026-45790 leads to permanent organization takeover in Dokploy instances. No public Proof-of-Concept (PoC) is currently available; the attack chain is inferred directly from the detailed vulnerability description.

  1. Reconnaissance/Target Identification:

    • An attacker first identifies a Dokploy PaaS instance, possibly via Shodan dorks like Dokploy or title:Dokploy.
    • The attacker then needs to gain initial access as a low-privileged user within an organization or identify an existing user with the member:create permission. Alternatively, if operating in a self-hosted environment, they would require privileged access to the Dokploy server itself to leverage the packages/server/src/services/user.ts flaw directly.
  2. Triggering the Specific Flaw Class:

    • Scenario A: Exploiting organization.inviteMember (Requires member:create permission):
      • A user with member:create permission leverages the organization.inviteMember tRPC procedure.
      • Instead of inviting a user with a standard member role, the attacker manipulates the request to explicitly assign the owner role to the newly invited account (which can be an account controlled by the attacker or a new account created for this purpose). The flaw lies in the backend failing to validate that the inviting user (with member:create permission) is authorized to assign the owner role.
    • Scenario B: Exploiting packages/server/src/services/user.ts (Requires privileged self-hosted access):
      • A privileged self-hosted user directly interacts with the backend functionality exposed by packages/server/src/services/user.ts.
      • During the account creation process, the attacker explicitly specifies the owner role for the new account, bypassing the intended privilege checks. This direct manipulation of user creation logic allows for the arbitrary assignment of any role, including the highest privilege owner role.
  3. Payload/Execution Method:

    • The "payload" in both scenarios is the successful invocation of the vulnerable procedures (organization.inviteMember or the user creation logic in packages/server/src/services/user.ts) with a crafted request that includes the owner role assignment.
    • For the organization.inviteMember scenario, this would involve sending an API call (likely via tRPC) that includes the target account identifier and the owner role.
    • For the self-hosted scenario, this could involve direct manipulation of backend services, potentially through administrative interfaces or API calls, to create a user with the specified owner role.
  4. Post-Exploitation Impact:

    • Upon successful exploitation, an account under the attacker's control is granted the owner role within the targeted Dokploy organization.
    • Since owner roles cannot be demoted, the attacker gains permanent, full administrative control over the organization. This includes management of all deployments, users, configurations, and data within the Dokploy PaaS instance.
    • The attacker can then perform various malicious activities such as data exfiltration, service disruption, deployment of malicious applications, or further lateral movement within connected systems.

Impact Assessment

The impact of CVE-2026-45790 is severe, directly leading to a complete compromise of confidentiality, integrity, and availability (C:H, I:H, A:H) for affected Dokploy organizations.

Business Impact: An organization takeover in a PaaS environment like Dokploy means an attacker gains control over all hosted applications, databases, and infrastructure managed by Dokploy. This can result in:

  • Data Breach: Access to all sensitive data stored within the PaaS, including application data, user credentials, and intellectual property.
  • Service Disruption: The attacker can delete or modify critical deployments, rendering applications unavailable or corrupt.
  • Reputational Damage: A public breach or service outage can severely damage an organization's reputation, leading to loss of customer trust and potential legal liabilities.
  • Financial Loss: Costs associated with incident response, forensic analysis, data recovery, and potential regulatory fines.
  • Supply Chain Risk: If the Dokploy instance is used to host applications for other customers or integrate with other systems, the compromise could lead to broader supply chain attacks.

Affected Systems: All Dokploy PaaS instances running versions prior to 0.29.6 are vulnerable. The self-hostable nature means many different organizations could be operating unpatched instances, potentially without vendor support or awareness.

Blast Radius: The blast radius is extensive. An attacker gaining an owner role effectively becomes the super-administrator for the entire Dokploy organization. This implies control over:

  • All deployed applications and their underlying infrastructure.
  • All secrets, environment variables, and configurations.
  • User accounts and permissions for the entire organization.
  • Ability to create, modify, or delete any resource managed by Dokploy.
  • Potentially, access to connected cloud provider resources if Dokploy integrates tightly with them (e.g., deploying to AWS, GCP, Azure). The PR:L (Low Privileges Required) aspect means that even a low-level internal user or an attacker who gains minimal access can escalate to full control, significantly widening the attack surface. The UI:R (User Interaction Required) might slightly constrain the attack, but the severity of the outcome remains very high.

Detection Guidance

Sigma Rule

title: Dokploy Privilege Escalation Attempt (CVE-2026-45790)
id: 5e6f7g8h-9i0j-1k2l-3m4n-5o6p7q8r9s0t
status: experimental
description: Detects attempts to invite or create users with 'owner' role in Dokploy, indicating potential CVE-2026-45790 exploitation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-45790
author: Valtersit Threat Intelligence
date: 2024/07/30
logsource:
  product: dokploy
  service: application_logs
detection:
  selection_invite_member:
    event_type: 'user_invite' # Assuming Dokploy logs user invitations
    procedure: 'organization.inviteMember' # Based on NVD description
    invited_role: 'owner'
  selection_create_user:
    event_type: 'user_creation' # Assuming Dokploy logs user creation
    source_file: 'packages/server/src/services/user.ts' # Based on NVD description, if logged
    assigned_role: 'owner'
  condition: selection_invite_member or selection_create_user
level: high
tags:
  - attack.privilege_escalation
  - attack.account_manipulation
  - cve.2026.45790
  - paas_security

YARA Rule

rule CVE_2026_45790_Dokploy_PrivEsc {
  meta:
    author = "Valtersit Threat Intelligence"
    date = "2024-07-30"
    description = "Detects files potentially related to CVE-2026-45790 in Dokploy."
    severity = "HIGH"
    reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-45790"
    cve = "CVE-2026-45790"
    mitre_tactic = "T1098 - Account Manipulation"
  strings:
    $s1 = "organization.inviteMember" ascii nocase
    $s2 = "apps/dokploy/server/api/routers/organization.ts" ascii nocase
    $s3 = "packages/server/src/services/user.ts" ascii nocase
    $s4 = "owner role" ascii nocase
    $s5 = "member:create permission" ascii nocase
    $s6 = "Dokploy is a free, self-hostable Platform as a Service" ascii nocase
    $vulnerable_version_string = "0.29." ascii wide

  condition:
    (uint16(0) == 0x5a4d and filesize < 50MB) and (
      (1 of ($s1, $s2)) or
      ($s3) or
      ($s4) or
      ($s5) or
      ($s6)
    )
}

Suricata IDS Rule

# Rule for detecting potential API calls related to owner role manipulation in Dokploy
alert http any any -> any any (msg:"VALTERSIT_CVE-2026-45790 Dokploy Owner Role Invite/Creation Attempt"; flow:established,to_server; content:"/api/"; http_uri; content:"owner"; http_client_body; pcre:"/\"owner\":\s*(true|\"[owner]\"|[\d]+)/P"; classtype:attempted-admin; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-45790; sid:20264579001;)
# Note: tRPC uses various protocols. This HTTP rule is a best-effort for JSON-based APIs.
# Actual tRPC traffic might require more specific protocol parsers or deeper inspection
# if it uses custom binary protocols or WebSockets with specific subprotocols.
# The `/api/` URI is a common convention, but specific tRPC endpoints for Dokploy are not detailed.

Elastic Detection

{
  "query": {
    "bool": {
      "should": [
        {
          "bool": {
            "filter": [
              { "match": { "event.category": "iam" } },
              { "match": { "event.action": "user_invite" } },
              { "wildcard": { "dokploy.api.procedure": "*organization.inviteMember*" } },
              { "match": { "dokploy.user.invited_role": "owner" } }
            ]
          }
        },
        {
          "bool": {
            "filter": [
              { "match": { "event.category": "iam" } },
              { "match": { "event.action": "user_create" } },
              { "wildcard": { "dokploy.source.file.path": "*packages/server/src/services/user.ts*" } },
              { "match": { "dokploy.user.assigned_role": "owner" } }
            ]
          }
        }
      ],
      "minimum_should_match": 1
    }
  },
  "fields": ["@timestamp", "event.category", "event.action", "user.name", "dokploy.user.invited_role", "dokploy.user.assigned_role", "dokploy.api.procedure", "dokploy.source.file.path"],
  "sort": [{ "@timestamp": { "order": "desc" } }]
}

Note: This Elastic query assumes Dokploy logs are ingested with a schema that includes fields like event.category, event.action, and custom fields for Dokploy-specific details such as dokploy.api.procedure, dokploy.source.file.path, and user role information.

Splunk SPL Query

(index="dokploy_logs" sourcetype="dokploy_api" (api_procedure="organization.inviteMember" invited_role="owner") OR (source_file="packages/server/src/services/user.ts" assigned_role="owner"))
| table _time, user, api_procedure, source_file, invited_role, assigned_role, client_ip
| rename client_ip AS "Source IP"
| sort -_time

Note: This Splunk query assumes Dokploy logs are collected, parsed, and indexed with fields such as api_procedure, invited_role, source_file, assigned_role, user, and client_ip. Adjust index and sourcetype as per your environment.

Wazuh OSSEC Rule

<group name="syslog,dokploy_app,">
  <rule id="100001" level="12">
    <if_sid>2500</if_sid> <!-- Generic log analysis rule -->
    <match>dokploy</match>
    <description>Dokploy Privilege Escalation (CVE-2026-45790) - Owner Role Assignment</description>
    <group>attack,privilege_escalation,account_manipulation,</group>
  </rule>

  <rule id="100002" parent="100001" level="14">
    <field name="dokploy.api.procedure">organization.inviteMember</field>
    <field name="dokploy.user.invited_role">owner</field>
    <description>Dokploy: User invited with 'owner' role via organization.inviteMember.</description>
    <group>high_severity,cve_2026_45790,</group>
  </rule>

  <rule id="100003" parent="100001" level="14">
    <field name="dokploy.source.file.path">packages/server/src/services/user.ts</field>
    <field name="dokploy.user.assigned_role">owner</field>
    <description>Dokploy: Privileged self-hosted user created account with 'owner' role.</description>
    <group>high_severity,cve_2026_45790,</group>
  </rule>

  <!-- File integrity monitoring for vulnerable files (if modified outside of patching) -->
  <rule id="100004" level="7">
    <if_sid>550</if_sid> <!-- FIM event for file modifications -->
    <match>apps/dokploy/server/api/routers/organization.ts|packages/server/src/services/user.ts</match>
    <description>Dokploy: Modification to critical organization/user management files.</description>
    <group>fim,dokploy_integrity,</group>
  </rule>
</group>

Note: These Wazuh rules require prior log parsing to extract Dokploy-specific fields like dokploy.api.procedure, dokploy.user.invited_role, dokploy.source.file.path, and dokploy.user.assigned_role. File integrity monitoring (FIM) rule requires configuration for the relevant paths.

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED — no patch evidence from any tracked source, however, the NVD description explicitly states a fix in version 0.29.6. This indicates a vendor-provided fix exists.

Immediate Mitigations

  1. Access Review: Immediately review all existing user accounts within Dokploy organizations, especially those with owner roles. Verify their legitimacy and ensure no unauthorized owner accounts have been created.
  2. Restrict Permissions: If feasible, identify and temporarily restrict users with member:create permission to prevent them from inviting new members or modifying roles, until the patch can be applied. This is a disruptive measure and should be assessed for business impact.
  3. Enhanced Logging & Monitoring: Implement rigorous logging and monitoring specifically for user creation, invitation, and role assignment events within Dokploy. Focus on any attempts to assign or create accounts with the owner role. Alert on any such activities.
  4. Least Privilege Enforcement: Ensure that all users and service accounts operate with the absolute minimum set of privileges required for their function. Regularly audit and revoke excessive permissions.

Patch/Upgrade Steps

  1. Upgrade to Version 0.29.6: The vendor has released a fix in Dokploy version 0.29.6. All affected Dokploy instances (versions prior to 0.29.6) should be upgraded to 0.29.6 or a later secure version as soon as possible.
    • Refer to the official Dokploy documentation or release notes for the precise upgrade procedure.
    • Perform thorough testing in a staging environment before deploying the patch to production.

Long-Term Hardening

  1. Regular Updates: Establish a routine for regularly applying security updates and patches for Dokploy and its underlying infrastructure.
  2. Input Validation & Authorization Checks: Ensure robust input validation and authorization checks are implemented throughout the application, especially for sensitive operations like user creation, role assignment, and inviting members.
  3. Principle of Least Privilege: Continuously enforce the principle of least privilege for all users, applications, and services interacting with Dokploy.
  4. Comprehensive Auditing: Maintain detailed audit logs for all administrative actions, user authentication events, and changes to critical configurations. Regularly review these logs for suspicious activities.
  5. Multi-Factor Authentication (MFA): Implement mandatory MFA for all Dokploy user accounts, particularly for administrative roles, to add an additional layer of security against unauthorized access.
  6. Security Awareness Training: Educate users, especially those with administrative privileges, about the risks of phishing, social engineering, and the importance of secure password practices.

References

  1. National Vulnerability Database (NVD) - CVE-2026-45790:
  2. Dokploy GitHub Repository (Likely Source of Fix):
  3. CWE-269: Improper Privilege Management:
👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

Dokploy
Dokploy PaaS
title:Dokploy
Powered by Dokploy
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-45790/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.