CVE-2026-43917
Stored XSS in Dokploy Self-Hosted PaaS
Publication date: 2026-05-29
Last updated on: 2026-05-29
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| dokploy | dokploy | to 0.19.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-43917 is a Cross-Organization Insecure Direct Object Reference (IDOR) vulnerability in the Dokploy application affecting versions 0.19.0 and earlier.
The issue arises because the protectedProcedure middleware only verifies that a user is authenticated but does not enforce organization scoping. This means that multiple endpoints fail to check whether the requested resource belongs to the user's active organization.
As a result, authenticated users can access, modify, or delete resources belonging to other organizations by exploiting this lack of proper authorization checks.
- Affected endpoints include over 25 functions across various modules such as deployment.ts, rollbacks.ts, backup.ts, volume-backups.ts, cluster.ts, and mount.ts.
The root cause is that each endpoint must individually verify that the resource's organization matches the session's activeOrganizationId, which was not implemented correctly.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows authenticated users to access, modify, or delete resources belonging to other organizations, leading to breaches of confidentiality, integrity, and availability.
Such unauthorized cross-organization access and data manipulation can result in violations of data protection regulations and standards like GDPR and HIPAA, which require strict controls on data access and integrity.
Specifically, the exposure of sensitive information (e.g., Docker Swarm join tokens) and the ability to disrupt services may lead to non-compliance with these regulations' requirements for protecting personal and organizational data.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized access and manipulation of resources belonging to other organizations.
- Confidentiality breaches: attackers can access sensitive data such as Docker Swarm join tokens and other organization-specific information.
- Integrity violations: attackers can modify or delete resources like deployments, backups, and cluster configurations.
- Availability disruptions: attackers can disrupt services by killing deployments or removing critical resources.
Overall, this can compromise the security and stability of the affected organizations' environments.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by verifying whether the Dokploy application endpoints properly enforce organization scoping checks after user authentication.
Specifically, you should check if the endpoints validate that the resource's organization matches the session's activeOrganizationId.
Detection can involve reviewing application logs or monitoring API calls to see if requests are accessing resources across organizations without proper authorization.
Since the issue is in the application logic, network-level commands alone may not fully detect exploitation, but you can monitor for suspicious API calls to affected endpoints such as allByType, killProcess, removeDeployment, delete, create, update, remove, manualBackupPostgres, MySql, Mariadb, Mongo, Compose, WebServer, listBackupFiles, list, one, delete, update, runManually, restoreVolumeBackupWithLogs, getNodes, removeWorker, addWorker, addManager, and create in mount.ts.
Suggested commands include using API request logging or intercepting tools (e.g., curl, Postman) to test if resources from other organizations can be accessed or manipulated by an authenticated user.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to ensure that every affected endpoint in the Dokploy application enforces organization scoping by validating that the resource's organization matches the session's activeOrganizationId.
Specifically, add organizationId validation after every find*ById() call in the affected endpoints, following the pattern used by correctly secured endpoints.
Until a patch is applied, restrict access to the affected endpoints to trusted users only and monitor for suspicious activity involving cross-organization resource access.
Applying the official fix or upgrade from the Dokploy maintainers as soon as it becomes available is recommended to fully resolve the issue.