GLPI CVE-2025-64520

Exploitation requires the attacker to already possess working GLPI API access (a valid API token / authenticated API session) - the description explicitly states 'an unauthorized user with an API access.' The specific weakness is that knowledge base (KnowbaseItem) search/read queries via the API did not apply visibility restrictions, so the API path returns entries regardless of per-user/group/profile/entity permissions. Limiting factors: the attacker must hold valid API credentials (consistent with PR:L - this is not pre-authentication), the impact is confined to reading knowledge base content (no write/modify, no DoS), and only GLPI deployments exposing API access in the 9.1.0-10.0.20 range are affected; upgrading to 10.0.21 removes the exposure.

This is a genuine but modest-severity information-disclosure issue, not a high-priority emergency. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3 MEDIUM) is internally consistent with the description: AV:N and PR:L reflect that an attacker needs valid API access (so authenticated, per PR:L) but can then read knowledge base entries they should not see, with only low confidentiality impact (C:L) and no integrity or availability impact. The signals broadly agree that this is low real-world urgency: EPSS is 0.22% (11th percentile), indicating low predicted exploitation likelihood; there is NO CISA KEV listing and NO public exploit code identified, so there is no public exploit identified at time of analysis. No SSVC decision was provided in the input. The one notable discrepancy is the 'Authentication Bypass' tag: the description and CWE-862 (Missing Authorization) describe an authorization/access-control failure by an already-authenticated API user, NOT a bypass of authentication itself - verify tagging rather than treating this as a pre-auth bypass. Net: a real, confirmed-and-patched authorization flaw worth scheduling for remediation, but not a drop-everything priority.

A low-privileged user who holds a valid GLPI API token issues knowledge base search/read queries through the REST API and receives all knowledge base entries, including those whose visibility should be restricted to specific users, groups, profiles, or entities. No public exploit code is known, but the flaw is trivially reachable (AC:L) once API access is held, as confirmed by the patch adding visibility restrictions to KnowbaseItem searches.