cal.diy EUVD-2026-91160

Requires a valid authenticated low-privilege session on the cal.diy instance (CVSS PR:L); it is NOT unauthenticated. Given that, no further special configuration is needed because the PBAC PermissionCheckService stub unconditionally returns true for checkPermission/hasPermission in default builds up to 6.2.0, so doesUserIdHaveAccessToBooking in BookingAccessService.ts grants access to bookings the user does not own. Exploitation is remote (AV:N), low-complexity (AC:L), and needs no user interaction (UI:N). Limiting factors: the attacker must hold an account on the target instance; impact per request is low (VC:L/VI:L/VA:L); affected versions are ≤6.2.0; and no merged patch yet exists, so defenders cannot remediate by upgrade until PR #30253 is accepted.

The vuldb CNA assigns a CVSS 4.0 base score of 2.1 (Low) with vector AV:N/AC:L/AT:N/PR:L/UI:N and uniformly low impacts (VC:L/VI:L/VA:L), plus E:P (Proof-of-Concept exploit maturity), which is consistent with the description's claim that exploit code has been released publicly. No EPSS probability and no CISA KEV status were provided in the input, so there is no signal of widespread or confirmed active exploitation - exploitation status here is 'publicly available exploit code exists', which is distinct from active in-the-wild use. On raw CVSS this looks like a low-priority, authenticated-only issue. However, the GitHub source-code evidence materially sharpens the picture: the PBAC Permission Engine's PermissionCheckService was a placeholder stub whose checkPermission()/hasPermission() methods unconditionally 'return true' and getTeamIdsWithPermission() returns [], and this stub was duplicated across several components (BookingAccessService.ts, getEventTypesByViewer.ts, getPublicEvent.ts, and the watchlist container). This is a genuine broken-access-control defect, not a theoretical one - authorization was effectively a no-op for any authenticated caller. The low vendor-assigned C/I/A impacts (VC:L/VI:L/VA:L) may UNDERSTATE the real breadth, since a permission engine that always returns true could expose or allow modification of bookings/event-types beyond a single resource - verify actual data exposure against the affected components. Net: a credible, easily-exploitable authorization bypass for authenticated users, but mitigated by the authentication requirement (PR:L), low per-request impact, and the absence of KEV/EPSS evidence of mass exploitation. Note also that no fix is merged yet (the PR awaits acceptance), so there is currently no confirmed patched version.

A low-privilege authenticated user of a cal.diy instance (≤6.2.0) sends a normal API request for a booking belonging to another user or team. Because the PBAC PermissionCheckService is a stub that always returns true, the doesUserIdHaveAccessToBooking check in BookingAccessService.ts passes regardless of actual entitlement, letting the attacker read or manipulate bookings they should not access. Public exploit code is reported to exist, and the network/low-complexity vector means the request requires only a valid logged-in session and no user interaction.