CVE-2026-45790
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).
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.
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:createpermission 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
inviteMemberscenario, 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.
Reconnaissance/Target Identification:
- An attacker first identifies a Dokploy PaaS instance, possibly via Shodan dorks like
Dokployortitle: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:createpermission. Alternatively, if operating in a self-hosted environment, they would require privileged access to the Dokploy server itself to leverage thepackages/server/src/services/user.tsflaw directly.
- An attacker first identifies a Dokploy PaaS instance, possibly via Shodan dorks like
Triggering the Specific Flaw Class:
- Scenario A: Exploiting
organization.inviteMember(Requiresmember:createpermission):- A user with
member:createpermission leverages theorganization.inviteMembertRPC procedure. - Instead of inviting a user with a standard member role, the attacker manipulates the request to explicitly assign the
ownerrole 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 (withmember:createpermission) is authorized to assign theownerrole.
- A user with
- 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
ownerrole 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 privilegeownerrole.
- A privileged self-hosted user directly interacts with the backend functionality exposed by
- Scenario A: Exploiting
Payload/Execution Method:
- The "payload" in both scenarios is the successful invocation of the vulnerable procedures (
organization.inviteMemberor the user creation logic inpackages/server/src/services/user.ts) with a crafted request that includes theownerrole assignment. - For the
organization.inviteMemberscenario, this would involve sending an API call (likely via tRPC) that includes the target account identifier and theownerrole. - 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
ownerrole.
- The "payload" in both scenarios is the successful invocation of the vulnerable procedures (
Post-Exploitation Impact:
- Upon successful exploitation, an account under the attacker's control is granted the
ownerrole 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.
- Upon successful exploitation, an account under the attacker's control is granted the
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. TheUI: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
- Access Review: Immediately review all existing user accounts within Dokploy organizations, especially those with
ownerroles. Verify their legitimacy and ensure no unauthorizedowneraccounts have been created. - Restrict Permissions: If feasible, identify and temporarily restrict users with
member:createpermission 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. - 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
ownerrole. Alert on any such activities. - 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
- 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
- Regular Updates: Establish a routine for regularly applying security updates and patches for Dokploy and its underlying infrastructure.
- 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.
- Principle of Least Privilege: Continuously enforce the principle of least privilege for all users, applications, and services interacting with Dokploy.
- 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.
- 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.
- 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
- National Vulnerability Database (NVD) - CVE-2026-45790:
- Dokploy GitHub Repository (Likely Source of Fix):
- https://github.com/dokploy/dokploy (Monitor releases for 0.29.6 or later)
- CWE-269: Improper Privilege Management:
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.