Invia #959492: https://github.com/calcom/ cal.diy commit 4026669 broken access control

PBAC permission engine shipped as allow-all stubs in the public tree (broken access control)

I am reporting a systemic authorization issue, confirmed against the verbatim BookingAccessService, with a caveat below.

In the public main tree (commit 4026669, stub from PR #28903), the PBAC layer is inlined no-op stubs: `PermissionCheckService.checkPermission/hasPermission` return `true` and `getResourcePermissions` returns all-true, duplicated across 15 files. The `@calcom/features/pbac/services/permission-check.service` exists only in test mocks (zero non-test imports), and there is no alias/swap in next.config/tsconfig/package.json. These stubs back `createTeamPbacProcedure`/`createOrgPbacProcedure` (pbacProcedures.ts) and `doesUserIdHaveAccessToBooking` (BookingAccessService.ts, also the v2 booking-pbac.guard). Migration 20260129090913_enable_pbac_globally enables PBAC by default, so the stub is the live path.

What I observed: running the verbatim BookingAccessService with only external imports faked, attacker user 42 (not organizer, not host, not a member of team 999) got `doesUserIdHaveAccessToBooking => true` for a team booking.

POC:
```
attacker (member of no relevant team) calls a team-event booking action (confirm/reject/details/history)
-> doesUserIdHaveAccessToBooking(attacker) returns true -> action allowed
```

Validated by copying `BookingAccessService.ts`, replacing only its 4 external import lines with type-compatible fakes (`MembershipRole`, `UserRepository`, a `BookingRepository` returning a fixture, type-only `PrismaClient`) and leaving the class body byte-for-byte verbatim (the `checkPermission(..._args) { return true; }` and Case-3 block unchanged), transpiled with esbuild on Node 18:

```
attackerUserId = 42 | booking.teamId = 999 | organizer = 1
doesUserIdHaveAccessToBooking(attacker) => true
>>> VULNERABLE: unrelated user granted access to a TEAM booking (PBAC stub returned true)
```

Attacker user 42 is not the organizer (id 1), not a host, and not a member of team 999, yet access returns `true`; secure behavior is `false`.

Impact: on public-source self-hosted instances with PBAC enabled (default), any authenticated user gets cross-tenant booking/team access. CWE-862/863, ~8.5.

Suggested fix: ship/import the permission-check service; make the stub default deny (fail closed); add a CI guard against `checkPermission(){return true}`.

• Fonte: ⚠️ https://github.com/calcom/cal.diy/issues/29802
• Utente: geochen (UID 78995)
• Sottomissione: 04/09/2026 08:51 (28 giorni fa)
• Moderazione: 01/10/2026 19:57 (27 days later)
• Stato: Accettato
• Voce VulDB: 412762 [calcom cal.diy fino a 6.2.0 PBAC Permission Engine BookingAccessService.ts doesUserIdHaveAccessToBooking escalationi di privilegi]
• Punti: 20