CVE-2026-59979 in Yosemite-Crew
Summary
by MITRE • 10/28/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in YosemiteCrew represents a critical failure in access control logic within its backend application architecture, specifically affecting service management and project management system (PMS) task library endpoints. The core technical flaw stems from an incomplete implementation of authorization middleware that fails to enforce organization-scoped permissions on several key routes. While the authentication mechanism via `authorizeCognito` successfully validates user identity by setting the authenticated user ID, it does not invoke the necessary permission checks such as `withOrgPermissions()` or `requirePermission()`. This omission means that while the system knows who is making a request, it fails to verify whether that user has the appropriate role-based access rights relative to the specific organization associated with the requested resource.
In the service management module located in `apps/backend/src/routers/service.router.ts`, this deficiency manifests across multiple HTTP methods for the `/fhir/v1/service/:id` endpoint. The PATCH and DELETE operations are protected only by authentication, allowing any logged-in user to modify or remove services belonging to other organizations. More severely, the GET operation lacks even basic authentication middleware, enabling unauthenticated actors to read sensitive service catalog data without providing credentials. This lack of both confidentiality controls for reading and integrity/availability controls for writing creates a severe risk profile where external attackers can exfiltrate organizational data or disrupt operations by altering critical records.
Similarly, the task library and template management routes in `apps/backend/src/routers/task.router.ts` exhibit identical authorization gaps. Endpoints such as PUT `/v1/task/pms/library/:libraryId`, POST `/v1/task/pms/templates`, PATCH `/v1/task/pms/templates/:templateId`, and DELETE `/v1/task/pms/templates/:templateId` do not enforce organization or role-based restrictions. The underlying controller logic in `apps/backend/src/controllers/web/service.controller.ts` passes a global record identifier directly to the database query via `ServiceModel.findById(oid)` without filtering by an associated `organisationId`. This architectural oversight allows any registered platform user, including those with limited privileges such as patients using companion applications, to access and manipulate data belonging to other organizations.
The operational impact of these vulnerabilities is substantial, affecting both data integrity and business continuity. Unauthorized modification or deletion of service catalogues can disrupt booking systems and billing processes that rely on accurate service definitions. Furthermore, the ability for any user to alter task libraries and templates used by project management teams undermines collaborative workflows and potentially introduces malicious logic into operational procedures. The fact that an earlier security patch protected creation routes but left these sibling read and update operations exposed indicates a fragmented approach to securing API endpoints, leaving significant attack surfaces open despite partial remediation efforts.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the application fails to enforce proper access controls on sensitive resources. In terms of adversary tactics, these flaws facilitate ATT&CK techniques such as T1078 Valid Accounts for initial access exploitation by leveraging legitimate credentials, and T1485 Data Destruction or T1098 Unauthorized Account Modification if attackers use the write capabilities to alter configurations. The exposure of data via unauthenticated GET requests also relates to CWE-200 Information Exposure through improper handling of sensitive information in API responses.
Mitigation requires a comprehensive review of all middleware chains and database query constructions across the backend application. Developers must ensure that every route handler, particularly those involving CRUD operations on organization-scoped resources, explicitly validates both user authentication and organizational ownership before executing logic. This involves integrating `withOrgPermissions()` checks into the service router handlers and ensuring that database queries always include filters for the authenticated user's associated organization ID to prevent cross-tenant data leakage or manipulation. Additionally, all endpoints must be audited to confirm they enforce appropriate HTTP method restrictions based on role-based access control policies defined in the system architecture.