GLPI 11.0.6 critical security update — what to upgrade

GLPI 11.0.6 critical security update — what to upgrade

On March 3, 2026, the GLPI project released security versions GLPI 11.0.6 and GLPI 10.0.24. Both address six vulnerabilities – one critical, three high-severity, and two moderate. If you run GLPI in production, patching should be your immediate priority.

What was fixed

The most severe vulnerability is CVE-2026-26026 – a Server-Side Template Injection (SSTI) rated critical. An attacker can execute arbitrary code on the server through the template engine. Successful exploitation leads to full system compromise.

Three additional high-severity issues were patched:

  • CVE-2026-26263 – unauthenticated SQL injection via the search engine. No credentials needed – access to the GLPI web interface is enough.
  • CVE-2026-29047 – authenticated SQL injection, exploitable after login.
  • CVE-2026-26027 – stored cross-site scripting (XSS) through inventory data.

Two moderate vulnerabilities complete the list:

  • CVE-2026-25937 – multi-factor authentication (MFA) bypass.
  • CVE-2026-25936 – another authenticated SQL injection.

Users of the older 10.0 branch should also note the fixes in GLPI 10.0.24: a stored XSS in the supplier module (CVE-2026-25932) and an authenticated SQL injection.

Why this is urgent

The combination of SSTI and unauthenticated SQL injection is particularly dangerous. The first allows code execution on the server; the second requires no credentials at all. GLPI typically holds device inventories, tickets with sensitive information, and credentials for network devices. A compromise means access to data about the entire IT infrastructure.

If your GLPI instance is not isolated behind a VPN or strict firewall rules, the risk is even higher.

Before upgrading: backup

The update is a migration that alters the database schema. Before running it, always:

# 1. Database dump
mysqldump --single-transaction --quick \
  -u glpi -p glpi_db > glpi_backup_$(date +%F).sql

# 2. Files backup
tar -czf glpi_files_$(date +%F).tar.gz /var/www/glpi

# 3. Verify the dump by restoring to a test database
mysql -u glpi -p glpi_test < glpi_backup_$(date +%F).sql

Without verifying backups you only have the illusion of a rollback. Test the restore on a throwaway database before running the production migration.

Plugin compatibility check

Plugins are the most common cause of upgrade trouble. Before upgrading:

  1. Open Setup → Plugins and list all active plugins and their versions.
  2. For each plugin, verify in the GLPI Plugins catalogue that a 11.0.6-compatible version exists.
  3. If a plugin has no compatible version, decide: wait for an update, find a replacement, or deactivate it before the upgrade.
  4. Active incompatible plugins can crash the migration script — disable them first.

Cascade compatibility: our workflow plugin Cascade has been tested with 11.0.6 and is compatible; if you're running it, the upgrade isn't blocked.

Deployment procedure

Recommended sequence for self-hosted deployments:

  1. Staging upgrade — if you have a test instance (strongly recommended), upgrade there first. Clone the production database and files to staging, run the upgrade, and verify functionality.
  2. Disable the GLPI cron — pause automatic actions during migration by commenting out the GLPI line in crontab -e.
  3. Maintenance mode — in Setup → General turn on Maintenance mode (or set an HTTP redirect to a maintenance page so users don't interfere during migration).
  4. Download the release — from the official glpi-project/glpi GitHub repository or from glpi-project.org. Verify the SHA-256 against the value in the release notes.
  5. Extract — replace files in /var/www/glpi, but keep the existing config/ and files/ directories from the previous install.
  6. Migration script — run php bin/console db:update or visit install/update.php in a browser.
  7. Reactivate — turn off Maintenance mode, re-enable cron, smoke-test the system.

Typical downtime: 5–15 minutes for smaller installs (under ~5,000 tickets), 15–30 minutes for larger databases. Heavily customised setups take longer.

Post-upgrade checklist

Before reopening for users, verify:

  • Login flows — local and via LDAP/AD
  • Email-to-ticket via mail collector
  • Search and saved searches
  • Notifications — fire a test ticket assignment and confirm the email arrives
  • Dashboards and reports
  • Plugin functionality (Cascade, Formcreator, and others)
  • Clean error log (files/_log/php-errors.log)

Rollback if something fails

If the migration fails or corrupts data:

  1. Stop the web server (systemctl stop apache2 or nginx).
  2. Restore the GLPI directory from the tar.gz backup.
  3. Restore the database from the SQL dump (mysql -u glpi -p glpi_db < glpi_backup_$(date +%F).sql).
  4. Restart the web server.

After rollback you're back on the previous version. Diagnose the failure — the most common causes are an incompatible plugin, insufficient PHP memory_limit, or a timeout for larger databases (max_execution_time).

Still on 10.0?

If you're still on GLPI 10.0.x, at minimum update to 10.0.24, which contains fixes for CVE-2026-25932 and the SQL injection. Plan the move to 11.0 within the coming months — the 10.0 branch is approaching end of life and future vulnerabilities will be patched only on 11.0. Version 11.0.6 also includes functional bug fixes: visibility of linked ITIL objects across entities, a timeline crash on NULL document dates, and several template and ticket-creation fixes.

Need help with this topic?

Get in touch