CVE-2024-50339 - How Attackers Can Hijack Any Session in GLPI Before Version 10..17

GLPI is an open-source IT asset management software popular among many organizations for tracking hardware, software, tickets, and much more. However, between versions 9.5. and before 10..17, a serious flaw was found—CVE-2024-50339—allowing an attacker to steal valid sessions without any login credentials.

In this detailed breakdown, I’ll show how this vulnerability works, what the core flaw is, examples of the exploit, and most importantly, what to do if you’re running a vulnerable version.

What is CVE-2024-50339?

CVE-2024-50339 is a vulnerability in GLPI that allows an attacker—without any authentication—to retrieve all active session IDs. If an attacker gets these IDs, they can impersonate any active user, including administrators, and do almost anything on the target GLPI system.

References

- CVE-2024-50339 details on NVD
- GLPI release notes
- GLPI GitHub advisory

How Does the Exploit Work?

The vulnerability is in how GLPI stores and exposes session IDs. Sessions are meant to be secret – only the person who logs in should ever know their session ID, and it’s passed as a cookie.

But in affected versions, an attacker can directly query the path where GLPI stores session information. Since no authentication is required, this opens a door for anyone on the network (or internet, if exposed) to list all sessions, grab the session ID, and use it against the system.

Once the attacker has a session ID for a logged-in user (say, an admin), they can impersonate that user instantly by setting the session ID cookie in their browser.

Proof-of-Concept Exploit

Here’s a basic, real-world example of how someone could exploit CVE-2024-50339.

1. Find The Sessions Directory

GLPI stores session files in the /files/_sessions folder within your GLPI installation directory. For example:

/var/www/html/glpi/files/_sessions/

2. List Session Files

If session files are accessible over the web (because of misconfigurations or the nature of this bug), you can list all files. Each session file corresponds to a user’s session.

Example (using curl)

curl http://target-glpi.example.com/files/_sessions/

If directory listing is enabled, you’ll see a list of files like

sess_j13ufsnpb3be2d7a76e9c51c48123467
sess_g7hh5abf1a41d5c786dd940f231ae238
...

Pick a session ID from the list (e.g., sess_j13ufsnpb3be2d7a76e9c51c48123467). Strip the sess_ part and set it as your session cookie in your browser.

Example using browser DevTools

document.cookie = "glpi=session_id_here; path=/";

Replace session_id_here with the value after sess_ (e.g., j13ufsnpb3be2d7a76e9c51c48123467).

4. Access GLPI as the Victim

Now, when you go to the GLPI web page, you’re authenticated as the user associated with that session—without knowing their password!

1. Update Immediately

Upgrade to at least GLPI 10..17. This release blocks unauthenticated access and tightens session security.

- Download GLPI 10..17 (official)

2. Check File Permissions

The /files/_sessions directory should only be accessible by the web application, not directly over HTTP. Make sure it’s not web-accessible:

- On Apache, use .htaccess

  Deny from all

Conclusion

CVE-2024-50339 is a critical flaw that allows session stealing and full system compromise on affected GLPI installs. If you run GLPI, upgrade to 10..17 or newer today. Check your server configuration so session files are never accessible online. Even after upgrading, always apply the principle of least privilege for all directories and services.

For even more details

- GLPI Security Advisory
- NVD’s CVE-2024-50339 page

Timeline

Published on: 12/12/2024 02:06:19 UTC
Last modified on: 01/10/2025 18:48:11 UTC