What is the CVSS score of CVE-2026-34592?

CVE-2026-34592 has a CVSS 3.1 base score of 7.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. EPSS exploitation probability: 0.2%.

Which versions of Coolify are affected by CVE-2026-34592?

Coolify, a self-hostable PaaS platform, contains a vulnerability (CVE-2026-34592) that allows authenticated users to access data from other teams, undermining the multi-tenant data isolation model…. A patch is available.

How to fix or mitigate CVE-2026-34592?

Within 24 hours: Identify all Coolify instances in use and document current versions. Within 7 days: Upgrade all instances to 4.0.0-beta.471 or later after testing in non-production environments. Within 30 days: Conduct access logs audit to identify any unauthorized cross-team data access and complete a post-incident review.

Coolify CVE-2026-34592

EUVD-2026-40236 HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-06-29 GitHub_M

Authentication Bypass Coolify Coollabsio

7.7

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

7.7 HIGH

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

vuln.today AI

7.7 HIGH

Authenticated low-priv user (PR:L) exploits a trivial network request (AV:N/AC:L); cross-team boundary breach justifies S:C; described impact is read access only, so C:H and I:N/A:N.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jun 29, 2026 - 23:01 EUVD

Analysis Generated

Jun 29, 2026 - 22:32 vuln.today

DescriptionCVE.org

Coolify is an open-source and self-hostable tool for managing servers, applications, and databases. Prior to 4.0.0-beta.471, Coolify server and project lookups are not scoped to the current team, allowing any authenticated user to access servers and projects belonging to other teams by specifying their IDs directly. This vulnerability is fixed in 4.0.0-beta.471.

AnalysisAI

Cross-team data exposure in Coolify (self-hostable PaaS) before 4.0.0-beta.471 allows any authenticated user to read servers and projects owned by other teams by supplying their object IDs directly. The flaw is a broken object-level authorization (IDOR) where lookups are never scoped to the requester's team, breaching the multi-tenant boundary. No public exploit identified at time of analysis, and the issue is resolved in 4.0.0-beta.471.

Technical ContextAI

Coolify is an open-source, self-hostable platform-as-a-service used to deploy and manage servers, applications, and databases - positioned as a self-hosted alternative to Heroku/Netlify/Vercel. Its multi-tenancy model isolates resources by 'team'. The root cause maps to CWE-639 (Authorization Bypass Through User-Controlled Key): server and project lookups accept a user-controlled identifier and resolve the record without re-checking that the record belongs to the caller's team. Because the application trusts the supplied ID rather than enforcing a team-scoped query (e.g. WHERE team_id = current_team), the access-control check that should gate every tenant resource is effectively absent. The affected package is identified by CPE cpe:2.3:a:coollabsio:coolify (all versions prior to the fix).

RemediationAI

Vendor-released patch: upgrade to Coolify 4.0.0-beta.471 or later, which scopes server and project lookups to the requesting user's team. Follow the upstream fix and details in the GitHub advisory (https://github.com/coollabsio/coolify/security/advisories/GHSA-qfcc-2fm3-9q42). If immediate upgrade is not possible, reduce exposure by restricting account provisioning so that only trusted operators hold authenticated accounts (collapsing the multi-tenant attack surface), and place the Coolify dashboard behind network controls such as a VPN, IP allowlist, or reverse-proxy authentication so unauthenticated/untrusted parties cannot reach the API - the trade-off is reduced convenience for legitimate remote and multi-team users. Avoid running mixed-trust teams on a single shared instance until patched; the side effect is needing separate instances per tenant. There is no fully effective application-level workaround because the missing check is in core lookup logic, so upgrading is strongly preferred.