GLPI 11.0.9 and 10.0.27 were released on 16 September 2026. The announcement carries one sentence that matters more operationally than the fix list: release frequency is going up over the coming months, and teams should expect security releases roughly every two weeks, driven by an influx of security reports that the project attributes to the rise of LLMs and agent-driven pentesting, which it says have sharply increased report volume — as they have for other popular open source projects.
What this batch fixes
The blog announcement highlights six issues; the GitHub release notes are more detailed — twelve security entries for 11.0.9, seven for 10.0.27. Five High-severity fixes are shared by both branches:
- unauthenticated SQL injection in the planning feature
- X509 authentication succeeding with unverified certificates
- a race condition in the marketplace allowing installation of a malicious plugin
- upload of a malicious page onto the web server
- arbitrary file deletion during document creation
The first is why this update is a poor candidate for the next convenient window: unauthenticated means no login required. Anyone running GLPI reachable from the internet — usually for the self-service portal — is exposed regardless of how profiles and permissions are set. The X509 issue is equally awkward: certificate authentication is deployed precisely because it should be stricter than a password, and here it accepted unverified certificates.
Two medium-severity items also hit both branches: access to followups, tasks and solutions generated from templates, and an unauthorized visibility expansion of knowledge base items, reminders and RSS feeds. The 11.0 branch adds XSS via form illustration import, stored XSS in ticket actors, asset names and network equipment models, plus an MFA bypass by another logged-in user. Staying on 10.0.x is no way out — the list is just shorter.
CVE numbers arrive too late to wait for
The release notes carry no CVE identifiers. With the previous batch, 11.0.8 and 10.0.26 shipped on 24 June and the matching GitHub advisories with CVE numbers arrived in two waves — five on 21 July, the remaining eleven on 27 July — between 27 and 33 days after the fix. A vulnerability management process that waits for a scanner to flag a CVE runs roughly a month behind a fix that is already public — and in an open source project, a public fix also maps where the bug was. For GLPI, the release tag is the source of truth, not the vulnerability database.
A two-week cycle is a different operating mode
A quarterly update can be run as a small project: agree a date, get people together, test. On a fourteen-day cycle it has to become a routine instead, with an owner, a fixed window and a rehearsed procedure:
- a standing maintenance window users and operations both know about
- a written procedure: database and file backup, maintenance mode, file replacement,
php bin/console db:update - a test instance that can be restored from a production backup in an hour, not a day
- a plugin inventory with the author's contact and the date of the last compatible release
- a rollback path tested in advance, not improvised at midnight
Plugins are the main brake here, and the marketplace race condition is a reminder that installing one is a controlled operation. For organizations in NIS2 scope this is more than operational hygiene — Decree 227/2025 requires vulnerability management as a documented process, and on a two-week release cycle “we were waiting for the next scheduled window” is hard to defend.
And GLPI 12
Version 12.0.0-rc2 landed the same day — still a release candidate, still labelled as not for production, with stable GLPI 12 expected in October. Waiting for it is no reason to postpone 11.0.9: moving to GLPI 12 is a separate project with its own plugin and infrastructure testing, while 11.0.9 is a file swap and one command.