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.