CVE-2026-22247: GLPI Webhook SSRF Vulnerability

CVE-2026-22247 Overview

CVE-2026-22247 is a Server-Side Request Forgery (SSRF) vulnerability affecting GLPI, a widely-used free asset and IT management software package. The vulnerability exists in the Webhook feature and allows GLPI administrators to perform unauthorized SSRF requests, potentially enabling access to internal network resources that should not be accessible from the application.

Critical Impact

An authenticated GLPI administrator can exploit the Webhook feature to send arbitrary HTTP requests to internal network resources, potentially exposing sensitive internal services, metadata endpoints, or enabling further attacks against internal infrastructure.

Affected Products

• GLPI versions 11.0.0 through 11.0.4
• GLPI installations with the Webhook feature enabled
• Organizations using GLPI for IT asset management with administrative users

Discovery Timeline

• 2026-02-04 - CVE-2026-22247 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2026-22247

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery). The flaw resides in the Webhook functionality within GLPI, where administrative users can configure webhook endpoints. The application fails to properly validate and restrict the destination URLs that webhooks can target, allowing administrators to craft requests that reach internal network resources.

SSRF vulnerabilities of this nature can be leveraged to probe internal network infrastructure, access cloud metadata services (such as AWS EC2 metadata at 169.254.169.254), interact with internal APIs, or pivot to other services within the network perimeter. While the vulnerability requires administrator-level privileges to exploit, it represents a significant risk in environments where administrative accounts may be compromised or where the principle of least privilege is not strictly enforced.

Root Cause

The root cause of this vulnerability is insufficient input validation and URL filtering in the Webhook configuration functionality. The application does not adequately restrict the destination of outbound HTTP requests initiated through webhooks, allowing requests to be directed to internal IP addresses, localhost, or cloud metadata endpoints that should be blocked.

Attack Vector

The attack is network-based and requires an authenticated administrator session. An attacker with administrative access to GLPI can navigate to the Webhook configuration interface and specify a target URL pointing to an internal resource. When the webhook is triggered, the GLPI server makes an HTTP request to the attacker-specified destination, effectively using the server as a proxy to access internal resources.

The vulnerability mechanism involves the webhook configuration accepting arbitrary URLs without proper validation. When a webhook event is triggered, the GLPI server initiates an HTTP request to the configured endpoint. By specifying internal addresses such as http://localhost/admin, http://192.168.1.1/, or cloud metadata URLs, an attacker can probe internal services and potentially extract sensitive information. For detailed technical analysis, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-22247

Indicators of Compromise

• Unusual outbound HTTP requests from the GLPI server to internal IP ranges or localhost addresses
• Webhook configurations targeting internal IP addresses (e.g., 127.0.0.1, 10.x.x.x, 192.168.x.x, 172.16.x.x-172.31.x.x)
• Access attempts to cloud metadata endpoints (e.g., 169.254.169.254) originating from the GLPI application
• Unexpected webhook configurations created by administrative accounts

Detection Strategies

• Monitor GLPI audit logs for webhook configuration changes, particularly those with internal or suspicious destination URLs
• Implement network-level monitoring to detect outbound connections from the GLPI server to internal network segments
• Review administrative account activity for unusual webhook creation or modification patterns
• Deploy Web Application Firewall (WAF) rules to detect and block SSRF patterns in application traffic

Monitoring Recommendations

• Enable comprehensive logging for all webhook-related activities within GLPI
• Configure network monitoring to alert on connections from GLPI servers to RFC 1918 private address ranges
• Implement egress filtering and log analysis for the GLPI server network segment
• Regularly audit webhook configurations for unauthorized or suspicious endpoints

How to Mitigate CVE-2026-22247

Immediate Actions Required

• Upgrade GLPI to version 11.0.5 or later immediately
• Audit all existing webhook configurations for potentially malicious endpoints
• Review administrative account access and implement multi-factor authentication
• Implement network segmentation to limit the GLPI server's access to sensitive internal resources

Patch Information

The GLPI development team has addressed this vulnerability in version 11.0.5. The patch implements proper URL validation and filtering to prevent SSRF attacks through the Webhook feature. Organizations should upgrade to the patched version as soon as possible. For detailed release information, see the GLPI 11.0.5 Release Notes.

Workarounds

• Disable the Webhook feature entirely if not required for business operations
• Implement network-level egress filtering to block the GLPI server from accessing internal IP ranges
• Deploy a web application firewall with SSRF protection rules in front of the GLPI application
• Restrict administrative access to a limited set of trusted users and implement strict access controls

# Example: Network-level egress filtering using iptables
# Block GLPI server from accessing internal networks via webhooks
# Replace eth0 with appropriate interface and adjust IPs as needed

# Block access to localhost from GLPI server outbound connections
iptables -A OUTPUT -o eth0 -d 127.0.0.0/8 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -o eth0 -d 127.0.0.0/8 -p tcp --dport 443 -j DROP

# Block access to private network ranges
iptables -A OUTPUT -o eth0 -d 10.0.0.0/8 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -o eth0 -d 172.16.0.0/12 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -o eth0 -d 192.168.0.0/16 -p tcp --dport 80 -j DROP

# Block access to cloud metadata endpoints
iptables -A OUTPUT -o eth0 -d 169.254.169.254 -j DROP