GLPI template-injection RCE: why admin rights should not equal root

GLPI is a widely used open-source IT asset management package. CVE-2026-26026 affects 11.0.0 through 11.0.5, is fixed in 11.0.6, scores CVSS 9.1, and is rated critical. Reported on 6 April 2026.

In one line: an authenticated administrator reaches arbitrary code execution on the server through template injection.

What the chain looks like

Per the public analysis:

1. The attacker obtains administrator access to GLPI (weak credentials, credential stuffing, or simply an insider)
2. Navigates to a section that permits template modification
3. Crafts a template containing an injection payload and saves it
4. GLPI renders the template and executes the injected code
5. That yields arbitrary command execution; a reverse shell establishes persistence
6. The attacker pivots laterally or exfiltrates data

The part actually worth discussing

The technical detail — which template engine, where the injection point sits — has no actionable value for someone running the software. The patch exists; upgrade. What deserves a pause is the assumption sitting between steps 3 and 4:

Why does “can edit a template” mean “can run commands on the server”?

A template engine exists so that non-programmers can change the interface. Its implicit promise is that what you edit here only affects how the page looks. The moment a template can call arbitrary code, that promise is void — and this bug is precisely a wire run from “edit the interface” to “execute code”.

The permission model makes it worse. A GLPI administrator manages assets, users, and tickets — all application-layer things. This chain converts application-layer privilege directly into operating-system privilege, with no step in between asking whether the person actually needs server access.

This is not a GLPI-only problem

The same assumption is everywhere:

• “Custom script” or “code snippet” boxes in admin panels
• Expression languages allowed inside report or email templates
• Plugin ecosystems where installing an extension is installing code
• Even CI configuration files — whoever can edit the pipeline can run commands on the runner

They share a shape: something treated as configuration that is in fact a Turing-complete execution entry point, with permissions designed as though it were configuration.

What defenders can do

If you run GLPI:

1. Upgrade to 11.0.6 or later. That is the only action that actually resolves it.
2. Inventory who holds administrator. The exploit needs an authenticated admin, so fewer admins and more controlled provisioning lower the risk.
3. Run GLPI in a constrained environment. A container, a read-only filesystem, an explicit egress policy. Even if a template executes, what it can reach stays bounded.

The third is the general answer to this class of bug. You cannot guarantee an application layer never has an injection; you can guarantee that being injected does not hand over the machine.

Where I land

Part of that 9.1 comes from discounting the “requires high privilege” precondition. I think the discount is wrong: administrator accounts in many organisations are shared, outsourced, or left behind by departed staff. Treating that as a strong precondition assumes an operational discipline most organisations do not have.

Whether a template engine can execute code should be an explicit, documented, switchable choice, not a side effect that is on by default. Any product where “something editable in the admin panel” ends up executing code should say so on the permissions screen — because when a user clicks “save template”, they are thinking “I changed a colour”.