CVE-2026-34044: Coolify Authentication Bypass Vulnerability

CVE-2026-34044 Overview

Coolify is an open-source, self-hostable platform for managing servers, applications, and databases. CVE-2026-34044 is an Insecure Direct Object Reference (IDOR) vulnerability [CWE-639] in the Logs::mount() component. The component looks up resources by Universally Unique Identifier (UUID) without scoping the query to the current team. An authenticated user can supply a victim resource UUID and read logs for applications owned by other teams. The issue affects Coolify versions prior to 4.0.0-beta.466 and is fixed in that release.

Critical Impact
Any authenticated Coolify user can read application logs belonging to other tenants by supplying a known resource UUID, breaking multi-tenant isolation and exposing sensitive operational data.

Affected Products

Coolify versions prior to 4.0.0-beta.466
Self-hosted Coolify deployments serving multiple teams
Coolify instances exposing the Livewire Logs and ExecuteContainerCommand components to authenticated users

Discovery Timeline

2026-07-07 - CVE-2026-34044 published to the National Vulnerability Database (NVD)
2026-07-09 - Last updated in NVD database

Technical Details for CVE-2026-34044

Vulnerability Analysis

Coolify implements multi-tenancy through the concept of teams, where each resource (application, service, database) belongs to a specific team. Access to resources should be constrained by team ownership. The Logs::mount() component in app/Livewire/Project/Shared/ accepts a resource UUID from request parameters and loads the corresponding model directly from the database. The query executes without applying a team ownership constraint, so any authenticated user can request logs for any UUID known to them. Because UUIDs may be leaked through URLs, screenshots, support channels, or enumeration of related endpoints, an attacker with a valid account can read logs from tenants they have no relationship with. The same defect appears in the ExecuteContainerCommand component, extending the impact beyond passive log disclosure.

Root Cause

The root cause is a missing authorization check on resource lookup. Eloquent queries such as Service::where('uuid', ...) and Application::where('uuid', ...) returned models regardless of the caller's team context. Coolify already provides an ownedByCurrentTeam() scope, but it was not applied consistently in these Livewire components. This is a textbook Insecure Direct Object Reference where authentication was enforced but authorization to the specific object was not.

Attack Vector

An attacker registers or already holds an account on the target Coolify instance. The attacker obtains or guesses a resource UUID belonging to a different team. The attacker then invokes the Livewire route backing Logs::mount() with parameters such as application_uuid, service_uuid, or stack_service_uuid set to the victim UUID. The server returns the mounted component with the victim's logs rendered. No user interaction from the victim is required.

php

// Patch: app/Livewire/Project/Shared/Danger.php
if ($this->resource === null) {
    if (isset($parameters['service_uuid'])) {
-        $this->resource = Service::where('uuid', $parameters['service_uuid'])->first();
+        $this->resource = Service::ownedByCurrentTeam()
+            ->where('uuid', $parameters['service_uuid'])->first();
    } elseif (isset($parameters['stack_service_uuid'])) {
-        $this->resource = ServiceApplication::where('uuid', $parameters['stack_service_uuid'])->first()
-            ?? ServiceDatabase::where('uuid', $parameters['stack_service_uuid'])->first();
+        $this->resource = ServiceApplication::ownedByCurrentTeam()
+            ->where('uuid', $parameters['stack_service_uuid'])->first()
+            ?? ServiceDatabase::ownedByCurrentTeam()
+            ->where('uuid', $parameters['stack_service_uuid'])->first();
    }
}

// Patch: app/Livewire/Project/Shared/ExecuteContainerCommand.php
if (data_get($this->parameters, 'application_uuid')) {
    $this->type = 'application';
-    $this->resource = Application::where('uuid', $this->parameters['application_uuid'])->firstOrFail();
+    $this->resource = Application::ownedByCurrentTeam()
+        ->where('uuid', $this->parameters['application_uuid'])->firstOrFail();
}
// Source: https://github.com/coollabsio/coolify/commit/6fbb5e626a82c576ae7a1a08b4e1d16aee2e82ed

Detection Methods for CVE-2026-34044

Indicators of Compromise

Livewire requests to Logs or ExecuteContainerCommand endpoints where the resource UUID in parameters does not belong to the authenticated user's team
Authenticated users generating log-view requests across an unusually broad set of application, service, or stack UUIDs
Access patterns showing a single account touching resources spread across many project or team identifiers

Detection Strategies

Enable application-level audit logging on Coolify and correlate the acting user's team with the team owning each requested UUID
Alert on any request where the resolved resource->team_id differs from the session's current_team_id
Review historical Livewire request logs for parameter names application_uuid, service_uuid, and stack_service_uuid accessed by non-owning users prior to upgrade

Monitoring Recommendations

Ship Coolify web server and application logs to a centralized logging or Security Information and Event Management (SIEM) platform for retention and correlation
Baseline normal per-user resource access volume and alert on statistical deviations
Monitor authentication and account-creation events on internet-exposed Coolify instances to detect adversary account provisioning

How to Mitigate CVE-2026-34044

Immediate Actions Required

Upgrade all Coolify instances to version 4.0.0-beta.466 or later without delay
Audit team membership and remove any unexpected or dormant user accounts, particularly on internet-exposed instances
Review historical logs for cross-team UUID access and treat any exposed application logs as potentially compromised, including any credentials or tokens they may have contained
Rotate secrets, API tokens, and credentials that may have appeared in application logs during the affected window

Patch Information

The fix is available in Coolify 4.0.0-beta.466. The patch applies the existing ownedByCurrentTeam() Eloquent scope to resource lookups in Logs::mount() and ExecuteContainerCommand, ensuring the query returns only resources owned by the requesting user's team. See the GitHub Security Advisory GHSA-565g-9j4m-wqmr, the fix commit 6fbb5e6, and the v4.0.0-beta.466 release notes for full technical detail.

Workarounds

Restrict Coolify instance access to trusted networks or Virtual Private Network (VPN) users until the patched version is deployed
Disable self-service registration and limit team membership to fully trusted operators as a temporary control
Place the Coolify web interface behind a reverse proxy that enforces strong authentication and per-user rate limiting to slow UUID enumeration attempts

bash

# Upgrade a self-hosted Coolify instance to the patched release
cd /data/coolify/source
curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o install.sh
bash ./install.sh

# Verify the running version is 4.0.0-beta.466 or later
docker exec coolify php artisan about | grep -i version