CVE-2026-27883: Coolify Authorization Bypass in Deployment API (4.0.0-beta.464)

Technical summary

The GET /api/v1/deployments/{uuid} endpoint in Coolify extracts a teamId from the JWT or session token and uses it to authenticate the request, but does not include it in the database query that retrieves deployment details. An attacker with valid credentials can enumerate or guess deployment UUIDs from other teams and retrieve their full configuration, logs, and metadata without authorization. The vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), a common pattern in multi-tenant systems where authorization checks are incomplete or inconsistent across API layers.

Business impact

In multi-team environments, this vulnerability allows credential-compromised users or insider threats to map the infrastructure landscape of competing teams or the broader organization. Exposure of deployment details may reveal cloud provider credentials, database connection strings, API keys, environment variables, and application architecture—all of which facilitate further compromise. For managed Coolify deployments serving multiple organizations, the blast radius is particularly concerning, as one customer's breach could expose infrastructure details across the customer base.

Affected systems

Coolify versions prior to 4.0.0-beta.464 are affected. All instances deployed in multi-team configurations are at risk. Single-user or single-team Coolify deployments have minimal exposure. The vulnerability affects the API layer and does not require server-side code execution or network access beyond standard HTTP; any authenticated user of the platform can trigger it.

Exploitability

Exploitation requires valid Coolify credentials—no public or guest authentication is needed. An attacker with a low-privilege user account, or one compromised from a partner organization, can immediately query the API to retrieve deployment details from other teams. No special tooling is required beyond curl or a standard API client. The barrier to exploitation is low, making this a concern in environments where credential reuse, shared testing accounts, or internal threat actors are realistic scenarios.

Remediation

Upgrade to Coolify 4.0.0-beta.464 or later. The fix implements proper team-scoping in the database query, ensuring the retrieved deployment belongs to the authenticated user's team. Organizations should review recent API access logs to detect whether the endpoint was queried for out-of-team UUIDs. If multi-team isolation is critical, consider temporarily restricting API access to trusted networks or implementing additional rate-limiting until patching is complete.

Patch guidance

Download and deploy Coolify 4.0.0-beta.464 from the official repository. Beta versions should be tested in a staging environment before production deployment, particularly in critical infrastructure contexts. Verify the patch by confirming that an authenticated user from Team A can no longer retrieve deployment details for Team B. Document the deployment date for compliance and incident response records.

Detection guidance

Monitor API access logs for GET requests to /api/v1/deployments/{uuid} endpoints where the requesting user's teamId does not match the deployment owner's teamId. Implement alerting on repeated enumeration attempts using sequential or non-existent UUIDs. Check for unusual patterns in API token usage across team boundaries. If centralized logging is unavailable, enable Coolify's verbose API logging and review for cross-team queries at regular intervals.

Why prioritize this

Although the CVSS score is 5 (Medium), the vulnerability should be prioritized based on organizational risk tolerance. In environments where team isolation is a primary security boundary—such as multi-customer SaaS platforms, agencies managing separate departments, or consultancies serving competing clients—this is a high-priority fix. The ease of exploitation, absence of weaponization barriers, and direct exposure of infrastructure credentials justify expedited patching. For single-team deployments, prioritization can be lower but should not be deferred indefinitely.

Risk score, explained

The CVSS 3.1 score of 5.0 reflects a network-exploitable, low-complexity vulnerability requiring low privilege (authenticated user) with limited confidentiality impact and no integrity or availability impact. The scope is changed (affecting resources outside the security scope of the vulnerable component—other teams). The score does not account for the criticality of data exposed (credentials, keys, architecture) or the business context of multi-tenancy; risk owners should adjust their internal scoring based on whether team isolation is a contractual or regulatory requirement.

Frequently asked questions