YosemiteCrew provides organization-based service and task management. In the source-reported affected main and dev snapshots, YosemiteCrew's service and PMS task-library/template routes omit organization and permission checks. `authorizeCognito` in `apps/backend/src/middlewares/auth.ts` sets the authenticated user's ID but does not provide the `withOrgPermissions()` and `requirePermission(...)` checks used by protected siblings. In `apps/backend/src/routers/service.router.ts`, `PATCH /fhir/v1/service/:id` and `DELETE /fhir/v1/service/:id` are authentication-only, while `GET /fhir/v1/service/:id` has no authentication middleware. The trace through `apps/backend/src/controllers/web/service.controller.ts` to `apps/backend/src/services/service.service.ts` passes a global record ID into `ServiceModel.findById(oid)` without an `organisationId` filter. In `apps/backend/src/routers/task.router.ts`, `PUT /v1/task/pms/library/:libraryId`, `POST /v1/task/pms/templates`, `PATCH /v1/task/pms/templates/:templateId` and `DELETE /v1/task/pms/templates/:templateId` likewise lack organization/role enforcement. Any registered platform user, including a patient/companion-app account, can modify or delete another organization's service catalogue and PMS task-library/template data, affecting bookings and billing; service records can additionally be read without authentication. An earlier security change protected create routes but left these sibling operations exposed. A fixed release cannot be established from the available evidence.