GLPI shipped two security releases on the same day, 28 October 2026 — 12.0.1 and 11.0.12. Both fix the same set of eight flaws, and one of them is rated Critical: an external authentication bypass.
For GLPI 12 this is the first patch of any kind. Stable 12.0.0 landed on 7 October 2026, so anyone who migrated immediately has three weeks of production behind them and another maintenance window ahead — a much shorter one, since a patch inside the same branch is not a migration.
What is fixed
The list is identical in both releases:
- Critical — external authentication bypass.
- High — reflected XSS in the ticket category, in the users authorization list, and in the form header.
- High — stored XSS on VLAN and in dashboards.
- High — privilege escalation by an entity administrator.
- Medium — administrator account deactivation by an unauthorized user.
External authentication in GLPI means login delegated outside the internal user database: LDAP and Active Directory, mail servers, CAS, x509 certificates, and handing authentication over to the web server. Any installation tied to a domain uses that layer, which is what makes the critical item the one that decides your maintenance window.
Privilege escalation by an entity administrator is the second item worth a look. It applies to multi-entity installations, a common shape in public administration and larger groups: an administrator of one organizational unit is deliberately boxed in, and the fix exists so that boundary holds.
Technical detail is not public yet
The project publishes advisories on a delay measured from the fix release: one month for Critical and High, one week for everything else. For the 28 October batch that puts the write-up of the critical flaw and the six high ones around late November 2026. As of 2 November 2026 neither an advisory nor a CVE identifier has been published for this batch.
There is a practical conclusion in that. You cannot build an interim mitigation — without the vector you do not know which authentication source is affected or what to filter at the reverse proxy. The delay is designed to let you deploy before the description is public: a head start, not a reason to wait.
The 10.0 branch did not get the fix
Version 10.0.28, released 30 September 2026, was the last one on the 10.0 branch; no 10.0.29 followed. The project's security policy lists only 12.0.x and 11.0.x as supported. An installation on GLPI 10 does not have these eight fixes and will not get them.
The same policy says only the latest patch release of each supported branch is in scope. Sitting on 11.0.8 or on 12.0.0 is therefore not "an older but supported version" — it is a version nobody will assess a report against.
How to handle it
- Move 12.0.0 to 12.0.1, and any 11.0.x to 11.0.12. No migration, no change in platform requirements.
- Back up the database and attachment directories first, with a rollback path you have actually tested.
- After the upgrade, test login through the external source directly — with a domain account, not a local administrator.
- Review plugins. A patch inside a branch rarely breaks them, but custom code touching authentication is worth checking.
- Record the change: for a critical fix, the deployment date and the reason both matter later in an audit.
Anyone who postponed GLPI 12 and stayed on 11 has the easier job: 11.0.12 covers the same ground, so the delay costs nothing extra. Anyone still on GLPI 10 has one more reason to move the upgrade out of the backlog and into the plan.