Server-Side Template Injection Enables RCE in glpi-project GLPI

GLPI is a free asset and IT management software package. From 11.0.0 to before 11.0.6, template injection by an administrator lead to RCE. This vulnerability is fixed in 11.0.6.

• glpi-project GLPI: the structured CNA record identifies versions >= 11.0.0, < 11.0.6 as affected.
• The CNA description states that the vulnerability is fixed in 11.0.6, and the GLPI 11.0.6 release lists this issue among the security problems fixed in that release.
• The advisory displays affected versions as >= 11.0.0 without an upper bound; this entry retains the < 11.0.6 upper bound from the supplied structured affected data. Do not infer the status of parallel or other release branches without separate confirmation.

The flaw is server-side template injection in GLPI's template-processing functionality. Template data controlled by an administrator is not sufficiently neutralized before it is processed by the template engine, allowing template directives or content to be interpreted as code. The documented precondition is an administrator account; the supplied attack characteristics indicate network reachability and no user interaction. The advisory states that this can lead to RCE. The available evidence does not identify the template field, endpoint, request format, or execution context. The supplied attack model marks scope as changed, so execution could affect resources outside the vulnerable component, but the exact boundary is not disclosed.

• The vulnerability is network-reachable, has low attack complexity, requires high privileges, and needs no user interaction.
• The supplied evidence does not establish an unauthenticated exploitation path.
• The record marks public_exploit as false and known_exploited as null. These fields do not prove that exploitation has never occurred.
• No exploit code, payload, IOC, campaign, or specific victim is identified in the reviewed sources.

The confirmed technical outcome is template injection that can lead to remote code execution when performed through an administrator account. The record characterizes confidentiality, integrity, and availability impact as high and marks scope as changed.

In practice, code execution may allow an attacker to read or modify GLPI data, disrupt the service, or affect other resources accessible to the application process. The post-exploitation boundary depends on process permissions, deployment configuration, and server connectivity, none of which is specified in the available evidence. The administrator privilege requirement is an important limitation, but it does not remove the risk if an administrative account is compromised.

Successful exploitation may allow code execution in the context of the GLPI application or server. Depending on the process permissions and the server's connected resources, possible consequences include reading asset and IT management data, modifying records, disrupting service, or affecting related resources.

Exploitation requires administrator privileges, so not every GLPI user has the same exposure. If an administrator account is compromised or misused, however, the flaw can turn application-level administrative access into code execution. The available evidence does not identify a breach, victim, or campaign, so these are possible technical consequences rather than confirmed events.

1. Upgrade affected GLPI deployments to 11.0.6, the fixed release confirmed by the advisory and the vendor release notes.
2. After updating, verify the actual deployed version and confirm that the instance is no longer within >= 11.0.0, < 11.0.6.
3. If an upgrade cannot be completed, the available evidence provides no documented vendor workaround or other official mitigation. Restricting administrator access or reducing network reachability should not be treated as a replacement fix.
4. Because the flaw can lead to RCE, review instances that were in the affected range for unauthorized changes and anomalous server activity after remediation.

1. Inventory all GLPI deployments and record the exact running version. Compare each instance with the affected range in this entry.
2. Identify GLPI instances reachable from relevant networks and the accounts with administrator privileges, because administrator access is the documented exploitation precondition.
3. Review application and web server logs around administrator template activity for unexpected changes or suspicious requests. Treat this as precautionary because the advisory provides no specific log signature or IOC.
4. For instances in the affected range, review for unauthorized changes and anomalous server activity. Lack of suspicious log evidence does not prove that the instance is safe.
5. After updating, verify that the deployed instance reports the vendor's fixed release.