Summary
Dokploy contains an authorization bypass that may allow an owner or administrator of one organization to operate on applications belonging to other tenants by supplying foreign application identifiers. Depending on the procedure invoked, this could expose or overwrite environment variables and build secrets, change application sources, or disrupt deployments.
Dokploy contains an authorization bypass that may allow an owner or administrator of one organization to operate on applications belonging to other tenants by supplying foreign application identifiers. Depending on the procedure invoked, this could expose or overwrite environment variables and build secrets, change application sources, or disrupt deployments.
Affected context
The issue occurs in multi-tenant Dokploy deployments where application-management procedures accept an applicationId and do not reliably verify that the referenced application belongs to the caller's organization. It may affect operations such as environment saving, Traefik configuration updates, deployment, and application stopping when tenant ownership is not enforced at the object-access boundary.
The issue occurs in multi-tenant Dokploy deployments where application-management procedures accept an applicationId and do not reliably verify that the referenced application belongs to the caller's organization. It may affect operations such as environment saving, Traefik configuration updates, deployment, and application stopping when tenant ownership is not enforced at the object-access boundary.
Exploit preconditions
- Attack surface: Authenticated application-management procedures exposed by the Dokploy control plane
- Required access: Owner or administrator privileges in at least one organization
- Trigger point: A procedure receives an applicationId associated with another tenant's application
- Why exploitation is possible: Authorization checks may validate the caller's role without binding the requested application to the caller's organization
- Attack surface: Authenticated application-management procedures exposed by the Dokploy control plane
- Required access: Owner or administrator privileges in at least one organization
- Trigger point: A procedure receives an applicationId associated with another tenant's application
- Why exploitation is possible: Authorization checks may validate the caller's role without binding the requested application to the caller's organization
Why this happens
The underlying bug is an object-level authorization failure. The applicationId supplied by the client is treated as sufficient to identify an authorized resource, while the server-side authorization decision does not consistently confirm that the resource belongs to the caller's tenant. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where a user-controlled identifier can be used to access or modify another user's or organization's object.
The underlying bug is an object-level authorization failure. The applicationId supplied by the client is treated as sufficient to identify an authorized resource, while the server-side authorization decision does not consistently confirm that the resource belongs to the caller's tenant. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where a user-controlled identifier can be used to access or modify another user's or organization's object.
Potential impact
- Cross-tenant modification of application environment variables
- Exposure or overwriting of build secrets
- Repointing of application source repositories or related sources
- Unintended deployment or stoppage of another tenant's application
- Service disruption and possible integrity loss for affected tenants
- Cross-tenant modification of application environment variables
- Exposure or overwriting of build secrets
- Repointing of application source repositories or related sources
- Unintended deployment or stoppage of another tenant's application
- Service disruption and possible integrity loss for affected tenants
General mitigation guidance
Mitigation generally focuses on enforcing tenant ownership for every resource operation rather than relying on identifiers or caller roles alone.
Common defensive patterns include:
- Resolve resources within the authenticated tenant context and reject foreign identifiers
- Apply centralized, server-side object-level authorization to every read and write procedure
- Avoid trusting client-supplied tenant, organization, or ownership fields
- Use deny-by-default authorization and least-privilege roles for administrative actions
- Prevent secrets and environment data from being returned or modified without explicit resource authorization
- Add authorization tests covering cross-tenant identifiers and sensitive lifecycle operations
Mitigation generally focuses on enforcing tenant ownership for every resource operation rather than relying on identifiers or caller roles alone.
Common defensive patterns include:
- Resolve resources within the authenticated tenant context and reject foreign identifiers
- Apply centralized, server-side object-level authorization to every read and write procedure
- Avoid trusting client-supplied tenant, organization, or ownership fields
- Use deny-by-default authorization and least-privilege roles for administrative actions
- Prevent secrets and environment data from being returned or modified without explicit resource authorization
- Add authorization tests covering cross-tenant identifiers and sensitive lifecycle operations
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and dynamic analysis of procedures that accept applicationId or similar object keys
- Code review checks verifying tenant ownership before every resource read or mutation
- Tests that replay authenticated requests with identifiers from another organization
- Audit-log rules for cross-tenant access attempts, unexpected application stops, deployments, or configuration changes
- Policy enforcement requiring centralized authorization middleware for multi-tenant resource operations
Automated application-security review tools may help identify direct object references that lack an ownership or tenant-scope check.
Organizations can look for this class of issue through:
- Static and dynamic analysis of procedures that accept applicationId or similar object keys
- Code review checks verifying tenant ownership before every resource read or mutation
- Tests that replay authenticated requests with identifiers from another organization
- Audit-log rules for cross-tenant access attempts, unexpected application stops, deployments, or configuration changes
- Policy enforcement requiring centralized authorization middleware for multi-tenant resource operations
Automated application-security review tools may help identify direct object references that lack an ownership or tenant-scope check.
