Version 12.0.0-rc1 appeared on GitHub on 3 September 2026 marked "do not use in production"; the announcement on the GLPI blog followed on 7 September. The 12.0.0 milestone is due on 6 October 2026 and, at the time of writing, had six of its 339 items still open. If you run GLPI for a larger organisation, that leaves about a month to find out what the upgrade breaks — and several of these changes only show up in a real environment, not in a test install on a laptop.
Start with the PHP and database versions
GLPI 11 requires PHP 8.2 or later; GLPI 12 raises the minimum to PHP 8.3. The database change is more pointed: MySQL stays at a minimum of 8.0, but the MariaDB minimum moves from 10.6 to 10.11. If GLPI runs on a distribution-packaged database that has not been refreshed in a while, check that first rather than discovering it mid-migration.
CSRF protection without tokens
This is the biggest operational change. GLPI 12 replaces the per-form CSRF token with validation of the Sec-Fetch-Site and Origin headers the browser sends itself. Every _glpi_csrf_token hidden field and X-Glpi-Csrf-Token AJAX header has to be removed from plugins.
The practical consequence: protection now depends on headers that have to survive the whole chain in front of the application. A reverse proxy or WAF that strips or rewrites Origin will cause form submissions to be rejected. GLPI has no switch for those two headers: if the proxy strips them, the fix belongs on the proxy. Separately, GLPI 12 adds client IP detection behind a proxy — GLPI_TRUSTED_REVERSE_PROXIES for the proxy IPs and GLPI_REVERSE_PROXY_HEADERS for the header list, where the guidance is to name only the headers the proxy actually handles, since anything else can be spoofed from outside. The only useful place to test this is behind the production proxy chain.
The knowledge base has lost its categories
The KnowbaseItemCategory itemtype and the knowbasecategory right are both gone. Categories are now ordinary articles linked parent-to-child, a root article is created automatically, and the structure can be rearranged by drag and drop. For an organisation with a knowledge base split across several teams, that means reviewing permission profiles and every report or integration referencing the old itemtype. The migration script moves the data; it does not fix your dashboards.
Plugins will fail on types
The development branch added PHP typing where there was none: Session::haveRight() now returns only a boolean, CommonGLPI and CommonDBTM have native parameter types, and KnowbaseItem_Comment and KnowbaseItem_Revision are marked final. The Glpi\Toolbox\Sanitizer class is gone entirely — in GLPI 11 its methods were merely deprecated — and database master/slave support is out of the code. A plugin written against GLPI 11 will die on a type error rather than politely reporting that it is incompatible. Integrations deserve the same attention — the High-Level API is at version 3.0.0 in GLPI 12.
The functional additions worth a look: a session manager with a dedicated tab for OAuth clients, sudo mode, reworked OLA handling and accessibility improvements.
What to get done before October
- verify the PHP and MariaDB versions on the target server
- build a test instance from a copy of the production database, not an empty one
- try logging in and submitting a form behind the real reverse proxy
- walk the plugin list and confirm 12.0 support for each one
- check profiles and reports for references to knowledge base categories
A release candidate does not belong in production, as the release itself insists. There is also no need to rush: GLPI 11 went stable on 1 October 2025 and its maintenance branch still gets security fixes — 11.0.8 and 10.0.26 shipped on 24 June 2026. Anyone still on GLPI 10 has a reason to plan the upgrade so it points straight at 12.