CVE-2022-39181 - Reflected Cross-Site Scripting (RXSS) in GLPI Reports Plugin — Simple Guide, Analysis, and Exploit Example

In 2022, a security vulnerability was discovered in the popular open-source IT asset management tool, GLPI, specifically in its Reports plugin. Labeled CVE-2022-39181, this flaw put many organizations at risk of Reflected Cross-Site Scripting (Reflected XSS or RXSS) attacks.

In this post, we’ll break down what Reflected XSS is, how the vulnerability in the GLPI Reports plugin happens, and show you with simple examples how attackers exploit this kind of issue.

What is a Reflected XSS (Type 1) Attack?

Reflected XSS occurs when user input sent by an HTTP request is immediately included in the server’s output webpage without first being sanitized or encoded. Attackers send a crafted URL containing malicious JavaScript. If the target visits the URL, their browser executes the attacker’s code—often stealing sensitive information or hijacking the session.

Details: CVE-2022-39181 and GLPI Reports Plugin

GLPI is widely used for IT and asset management. The Reports plugin adds reporting features. Researchers found that this Reports plugin failed to properly sanitize parameters passed by users, resulting in a Reflected XSS vulnerability.

References

- NVD Entry for CVE-2022-39181
- GLPI Reports Plugin on GitHub
- Original Exploit-DB Report

How The Vulnerability Works (Simplified)

Suppose the Reports plugin has a page that accepts a reports parameter and includes it directly in the HTML response, for example:

http://example.com/plugins/reports/front/showreport.php?reports=monthly

Let’s say the vulnerable PHP code looks like this

<?php
// simplified vulnerable code
$reports = $_GET['reports'];
echo "<h1>Report: $reports</h1>";
?>

No sanitization or encoding is done, so whatever is passed in the reports parameter is rendered on the page. This is a classic reflected XSS risk if the input contains HTML or JavaScript.

The attacker can create a payload like this

http://example.com/plugins/reports/front/showreport.php?reports=<script>alert('GLPI XSS')</script>

If the victim clicks the link, the browser receives a page containing this

<h1>Report: <script>alert('GLPI XSS')</script></h1>

The <script> tag runs as soon as the page loads, so alert('GLPI XSS') pops up on the victim's screen. This simple test could easily become a more dangerous payload in a real attack.

`

http://[target-glpi-domain]/plugins/reports/front/showreport.php?reports=alert('XSSed!')

Send to Victim

- Email, chat, or a malicious website/iframe can be used.

Proof-of-concept: JavaScript alert appears.

- Real-world: Steal cookies/session, redirect victim, log keystrokes, etc.

Sanitize all inputs: Use PHP functions like htmlspecialchars() to escape output.

- Validate input: Ensure only expected values are accepted (e.g., allow only alphanumerics in reports).

Use a framework: Most modern frameworks provide built-in XSS protection.

- Keep plugins and GLPI up to date: Patch the Reports plugin to the latest version that fixes CVE-2022-39181.

Patched code example

<?php
$reports = htmlspecialchars($_GET['reports'], ENT_QUOTES, 'UTF-8');
echo "<h1>Report: $reports</h1>";
?>

Final Thoughts

Reflected XSS in plugins like GLPI Reports can seem simple, but the impact can be severe—especially in trusted IT environments. Understanding how these attacks work is the first step to preventing them.

Always sanitize user input, trust *nothing* from external sources, keep your plugins up to date, and review your application code for echoed variables that don’t use encoding.

Timeline

Published on: 11/17/2022 23:15:00 UTC
Last modified on: 11/23/2022 16:12:00 UTC