GLPI Security Updates Every Two Weeks: Is Your Patching Ready?

What happened

French IT publication IT-Connect covered the release under the headline twelve flaws patched and an update rhythm that is accelerating. Their analysis is well worth reading in full. In summary:

• GLPI 11.0.9 fixed 12 vulnerabilities, ten rated important and two moderate. Seven of them also affected GLPI 10 and were fixed in 10.0.27.
• The most urgent was an unauthenticated SQL injection in the planning feature, which IT-Connect advises prioritising for any instance reachable from outside.
• Others included a race condition in the marketplace that could allow a malicious plugin to be installed, upload of a malicious page to the web server, arbitrary file deletion, and, in GLPI 11 only, an MFA bypass and four cross-site scripting flaws.

The full list is in Teclib's release announcement.

Why the pace has changed

Teclib was candid about the reason. Like other popular open-source projects, and with the rise of LLMs and agent-driven penetration testing, GLPI has seen a significant surge in security reports. The project is increasing its release frequency to keep up, and asks administrators to expect security releases roughly every two weeks.

The cadence has held. GLPI 11.0.10 and 10.0.28 followed on 30 September with further security fixes, and GLPI-Agent 1.20 also shipped security fixes in September. This is a sign of a project that fixes what it finds, quickly. It does mean the people running GLPI need to keep up too.

Fast does not mean careless

There is a second lesson in the release history. GLPI 11.0.10 contained a regression that crashed some instances when loading certain plugins, and 11.0.11 was released on 1 October to fix it. Anyone who patched production directly, without a test, found out the hard way.

The answer is not to patch slowly. It is to make patching routine, so that a fortnightly release is a planned half-hour job rather than an emergency.

A patching routine that keeps up

1. Watch the right channels. Follow the GLPI releases page and Teclib's announcements, and read the severity of each fix rather than just the version number.
2. Keep a staging copy. A recent copy of production with the same plugins lets you test every release against your own configuration.
3. Test what matters. Log in, raise and update a ticket, run an inventory, load every plugin. Twenty minutes catches most regressions.
4. Patch the agents too. GLPI Agent releases carry their own security fixes and are easy to forget.
5. Agree a window. A standing fortnightly maintenance slot, with a backup and rollback step, removes the need for change approval debates every time.
6. Reduce exposure. If GLPI does not need to be on the public internet, take it off. If it does, put it behind a reverse proxy or VPN and restrict the administrative interface.

How Echo-9 helps

Echo-9 already handles GLPI patching and updates for managed customers. Each security release is reviewed, tested on a staging copy with the customer's own plugins, and deployed in an agreed window with a rollback ready. For organisations running GLPI themselves, we can set up the staging environment, the test checklist and the maintenance routine, and step in when a release needs urgent attention.

Pairing GLPI with Wazuh adds vulnerability detection across the wider estate, so the service desk platform is not the only system you are keeping current.

Your service desk holds the keys to your estate. Patch it like it does.