Coolify EUVD-2026-87817

Exploitation requires reaching the resource-update routes guarded by the CanUpdateResource route-level middleware in Coolify <= 4.1.2, whose authorization body (Gate::allows('update', $resource)) was fully commented out. Realistically it requires a valid authenticated Coolify account (any team role), since these routes sit behind login - despite the vendor's PR:N rating. No user interaction or non-default configuration is needed; any multi-user/multi-team instance is exposed. The limiting factors are the need for authentication and that single-user/single-team deployments have less to abuse. Fixed by upgrading to 4.2.0.

This is a genuine broken-access-control flaw with strong corroborating evidence, not just a paper vulnerability. The GitHub PR diff (#10829) is decisive: the entire body of the CanUpdateResource route middleware was commented out, meaning the Gate::allows('update', $resource) authorization check never executed for resource-update routes (applications, standalone databases, stack services, services, servers, environments, projects). CWE-862 (missing authorization) is accurate. The vendor/VulDB CVSS 4.0 base is 6.9 with E:P (proof-of-concept) and a published exploit archive on GitHub, so 'publicly available exploit code exists.' No CISA KEV listing and no EPSS score were provided, so there is no evidence of active mass exploitation - the E:P/POC signal indicates exploitability is demonstrated but not yet observed in the wild. The most important conflict to flag: the vendor vector states PR:N (unauthenticated), yet CanUpdateResource is an authorization layer that sits behind Coolify's login/authentication; the realistic prerequisite is a valid but low-privileged authenticated account (PR:L), and the missing check lets that account modify resources belonging to other teams/users. I also disagree with the uniformly Low impact (VC:L/VI:L/VA:L): the affected routes govern updates to servers and databases in a self-hosted PaaS, so integrity impact is realistically higher. Net: a real, moderate-to-high priority issue for anyone running multi-user/multi-team Coolify instances, tempered by the fact that some form of authenticated access is needed and real-world deployment is developer/self-hoster oriented.

A low-privileged authenticated Coolify user (e.g., a member of one team) sends a normal resource-update request whose route parameter references an application, database, or server UUID belonging to a different team. Because the CanUpdateResource middleware body was commented out, no ownership/permission gate runs and the update is accepted, letting the attacker reconfigure or redeploy resources they do not own. A proof-of-concept exploit archive has been published on GitHub.