YosemiteCrew EUVD-2026-112145

For the state-changing routes (PATCH/DELETE /fhir/v1/service/:id and PUT /v1/task/pms/library/:libraryId, POST /v1/task/pms/templates, PATCH and DELETE /v1/task/pms/templates/:templateId) the only prerequisite is any registered platform account - explicitly the lowest-privilege role, including a patient/companion-app user - because these routes carry authorizeCognito (authentication only) without withOrgPermissions() or requirePermission(...), and the service methods look records up by global ID with no organisationId filter. The GET /fhir/v1/service/:id read sink has no authentication middleware at all, so any service record is readable with no account. These are default code-path routes, so no non-default configuration or feature flag is required. The limiting factors are: write/delete operations require possession of a valid account (trivial where companion-app self-registration is open) and knowledge or enumeration of a target record ID; the affected scope is the main/dev snapshots at the stated commit, and no fixed release is available to upgrade to.

The CVSS 3.1 base score of 8.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H) reflects a network-reachable, low-complexity flaw needing no user interaction and only the lowest authenticated privilege - and the source evidence confirms that 'lowest privilege' includes a self-registrable patient/companion-app account, so the PR:L barrier is close to meaningless in practice. The vuln.today decision label is 'this_week' (not act_now/emergency), and there is no CISA KEV listing and no EPSS score in the input, so there is no signal of active or probable near-term exploitation - this is a severity-driven priority, not an exploitation-driven one. No public exploit identified at time of analysis; the only reference is the GitHub Security Advisory (GHSA-256m-gg99-4274), which documents the vulnerable routes and sink trace in detail but is not exploit code. Working against treating this as urgent: the affected product appears to be a niche open-source veterinary practice-management platform with limited real-world deployment, and no fixed release exists, so the realistic exposure is small even though the technical severity is high. Working for prompt action: exploitation prerequisites are trivial, the advisory and source trace precisely locate the bug (making a PoC easy to build), the impact is cross-tenant integrity and availability on bookings/billing-critical data, and one read sink is fully unauthenticated. EPSS and SSVC exploitation/automatable/technical-impact sub-fields are not provided and cannot be cross-referenced.

An attacker registers an ordinary low-privilege account (e.g. a patient/companion-app login), authenticates, and sends a PATCH or DELETE to /fhir/v1/service/:id or a PUT/POST/PATCH/DELETE to the /v1/task/pms/library and /templates routes using another organization's record ID, which the backend resolves by global ID with no organisationId filter. Because AV:N/AC:L/PR:L/UI:N, this is a single remote authenticated request with no special tooling, letting the attacker alter or delete another tenant's service catalogue and PMS task definitions and thereby disrupt bookings and billing; the GET /fhir/v1/service/:id read sink additionally requires no authentication at all. No public exploit identified at time of analysis, but the GHSA advisory supplies the exact routes and sink trace.