GLPI EUVD-2026-87273

Requires a valid but low-privileged authenticated GLPI account (PR:L) and use of the new REST API v2 (the 'HL' API) rather than the web UI - the flaw exists only in the API update flow, which failed to re-apply the per-item and right-based authorization checks the UI enforces. Concretely, the abusable operations are ITIL ticket team-member add/remove/list (endpoints like /Assistance/Ticket/{id}/TeamMember, needing the object's READ and canAssign rights) and entity Transfer (needing the Transfer READ right), plus the statusByService call. Limiting factors: the target must be running GLPI 11.0.0-11.0.7 (the v2 API is 11.x-only), the attacker must already have a functioning account, and AT:P indicates not all objects/actions are uniformly reachable; there is no unauthenticated or UI-interaction path.

This is a genuine but moderate-priority authorization flaw (CWE-862, broken access control), not a high-CVSS-but-empty finding. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L, base 6.0) is credible and integrity-focused: a network attacker who already holds a low-privileged authenticated account can perform update operations (e.g., assigning/removing ITIL ticket team members, triggering entity Transfer) that GLPI's UI would deny for that user. The commit diff corroborates the mechanism - the API v2 (HL API) controllers lacked $item->can(READ)/canAssign() and Transfer READ checks that the UI enforces. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is 'no public exploit identified at time of analysis' - the AT:P (attack requirements present) also signals that not every object/endpoint is trivially reachable. The main tempering factors are PR:L (a valid account is required) and the API-v2-specific nature of the flaw. Note one conflict to verify: the vendor's 4.0 vector sets VC:N (no confidentiality impact), yet the patch also added READ guards to GET team-member endpoints, implying a minor information-disclosure element the official score omits.

An attacker holding a low-privileged authenticated GLPI account (e.g., a basic technician or self-service user) calls the v2 API directly rather than using the web UI - for example POSTing to /Assistance/Ticket/{id}/TeamMember to add or reassign a ticket's assignee/observer, or POSTing to /Transfer - an action the UI would forbid for that profile. Because the API update flow skipped the per-item authorization checks, the operation succeeds, letting the attacker tamper with ticket assignments or entity data. No public exploit code was identified, but the fixing commit and its tests document the exact vulnerable endpoints.