CVE-2026-34037 Overview
Coolify, an open-source self-hostable platform for managing servers, applications, and databases, contains a broken access control flaw in versions prior to 4.0.0-beta.464. The cloneTo() Livewire action in ResourceOperations.php authorizes the source resource but resolves destination resources with unscoped Eloquent lookups. An authenticated user can clone resources into destinations owned by other teams, enabling cross-tenant resource access. The flaw is categorized under [CWE-639: Authorization Bypass Through User-Controlled Key].
Critical Impact
An authenticated tenant can breach tenant isolation to access and manipulate resources belonging to other teams within the same Coolify instance.
Affected Products
- Coolify versions prior to 4.0.0-beta.464
- app/Livewire/Project/Shared/ResourceOperations.php component
- StandaloneDockerPolicy and related destination resolvers
Discovery Timeline
- 2026-07-07 - CVE-2026-34037 published to NVD
- 2026-07-07 - Last updated in NVD database
Technical Details for CVE-2026-34037
Vulnerability Analysis
The vulnerability resides in the resource cloning workflow of Coolify's Livewire UI layer. The cloneTo() action correctly invokes $this->authorize('update', $this->resource) on the source resource. However, it then resolves the destination (StandaloneDocker or SwarmDocker) using a global find($destination_id) call with no team scoping. Because the destination lookup ignores tenant boundaries, any authenticated user who can enumerate or guess a destination ID can direct the clone into another team's infrastructure.
Compounding the issue, the StandaloneDockerPolicyupdate, delete, and restore methods returned true unconditionally, effectively disabling policy-based tenant checks that would otherwise catch the misuse downstream.
Root Cause
The root cause is a combination of unscoped Eloquent queries and permissive authorization policies. Destination model lookups did not constrain results by team_id, and the corresponding policy methods short-circuited with return true, leaving no server-side enforcement of tenant ownership on the destination object.
Attack Vector
An authenticated low-privileged user issues a cloneTo Livewire request supplying a destination_id that belongs to another team's server. The source authorization check passes because the user owns the source. The unscoped find() returns the foreign destination, and the clone proceeds against infrastructure the user does not own.
// Security patch in app/Livewire/Project/Shared/ResourceOperations.php
{
$this->authorize('update', $this->resource);
- $new_destination = StandaloneDocker::find($destination_id);
+ $teamScope = fn ($q) => $q->where('team_id', currentTeam()->id);
+ $new_destination = StandaloneDocker::whereHas('server', $teamScope)->find($destination_id);
if (! $new_destination) {
- $new_destination = SwarmDocker::find($destination_id);
+ $new_destination = SwarmDocker::whereHas('server', $teamScope)->find($destination_id);
}
if (! $new_destination) {
return $this->addError('destination_id', 'Destination not found.');
Source: GitHub Commit 1759a163
The fix in StandaloneDockerPolicy.php reinstates real ownership checks:
// Security patch in app/Policies/StandaloneDockerPolicy.php
public function update(User $user, StandaloneDocker $standaloneDocker): bool
{
- return true;
+ return $user->teams->contains('id', $standaloneDocker->server->team_id);
}
public function delete(User $user, StandaloneDocker $standaloneDocker): bool
{
- return true;
+ return $user->teams->contains('id', $standaloneDocker->server->team_id);
}
public function restore(User $user, StandaloneDocker $standaloneDocker): bool
{
- return true;
+ return false;
}
Source: GitHub Commit 1759a163
Detection Methods for CVE-2026-34037
Indicators of Compromise
- Livewire requests to the ResourceOperations component with cloneTo actions where the acting user's team does not own the referenced destination_id.
- Application logs showing resource clone operations that create records under a team_id different from the initiating user's team.
- Unexpected new deployments, containers, or database resources appearing in tenant environments without matching audit entries from the owning team.
Detection Strategies
- Correlate Coolify web application logs with database write events to identify clone operations that cross team boundaries.
- Add a runtime assertion or audit hook that logs when the destination team_id differs from currentTeam()->id during clone actions.
- Review historical Livewire request payloads for anomalous destination_id values that do not match resources previously listed to that user.
Monitoring Recommendations
- Enable verbose logging on the Livewire endpoint handling Project/Shared/ResourceOperations and forward to a centralized log platform.
- Monitor for spikes in failed or successful clone actions per user and alert on cross-team resource creation.
- Track policy authorization outcomes in StandaloneDockerPolicy and SwarmDockerPolicy to surface previously permissive return true behavior in unpatched forks.
How to Mitigate CVE-2026-34037
Immediate Actions Required
- Upgrade Coolify to version 4.0.0-beta.464 or later without delay.
- Audit existing resources for records created via cloneTo where the source and destination team_id differ, and remove or reassign unauthorized artifacts.
- Rotate any secrets, environment variables, or credentials stored on servers that may have been touched by cross-tenant clone operations.
Patch Information
The fix is available in Coolify v4.0.0-beta.464. Details are documented in GHSA-ggrr-wrvr-x83v and the corresponding source commit. The patch scopes destination lookups with whereHas('server', fn ($q) => $q->where('team_id', currentTeam()->id)) and restores real team membership checks in the affected policies.
Workarounds
- Restrict Coolify instance access to a single trusted team until the patched release can be deployed.
- Place the Coolify management interface behind network controls that limit which authenticated users can reach the Livewire endpoints.
- Manually apply the upstream patch to ResourceOperations.php and StandaloneDockerPolicy.php if an immediate version upgrade is not possible.
# Upgrade Coolify to the patched release
cd /data/coolify
git fetch --tags
git checkout v4.0.0-beta.464
./upgrade.sh
# Verify the running version
docker exec coolify php artisan about | grep -i version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

