CVE-2026-1884: ZenTao Webhook Module SSRF Vulnerability

CVE-2026-1884 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in ZenTao project management software up to version 21.7.6-85642. The vulnerability exists in the fetchHook function within the module/webhook/model.php file of the Webhook Module component. This flaw allows authenticated attackers with high privileges to manipulate server-side requests, potentially enabling access to internal resources, data exfiltration, or further network reconnaissance.

Critical Impact

Remote attackers with privileged access can exploit this SSRF vulnerability to make the ZenTao server initiate arbitrary HTTP requests to internal or external systems, potentially bypassing network security controls and accessing sensitive internal services.

Affected Products

• ZenTao versions up to and including 21.7.6-85642
• ZenTao Webhook Module component
• Systems with exposed ZenTao administrative interfaces

Discovery Timeline

• February 4, 2026 - CVE-2026-1884 published to NVD
• February 5, 2026 - Last updated in NVD database

Technical Details for CVE-2026-1884

Vulnerability Analysis

This SSRF vulnerability (CWE-918) resides in the Webhook Module of ZenTao, specifically within the fetchHook function located at module/webhook/model.php. The vulnerability allows an authenticated attacker with administrative privileges to craft malicious webhook configurations that cause the ZenTao server to make unintended HTTP requests to arbitrary destinations.

The attack requires network access to the vulnerable ZenTao instance and authenticated access with elevated privileges. Once exploited, the vulnerability can compromise the confidentiality, integrity, and availability of internal systems accessible from the ZenTao server. The exploit has been publicly disclosed on GitHub, increasing the risk of active exploitation despite the vendor not responding to initial disclosure attempts.

Root Cause

The root cause of this vulnerability lies in insufficient validation of user-supplied URLs within the fetchHook function. The Webhook Module fails to properly sanitize or restrict the target URLs that webhooks can interact with, allowing attackers to specify internal network addresses, localhost references, or cloud metadata endpoints. This lack of URL validation enables the server to be used as a proxy to access internal resources that should not be externally reachable.

Attack Vector

The attack vector is network-based, requiring the attacker to have authenticated access with high privileges to the ZenTao administrative interface. The attacker can then manipulate webhook configurations to include malicious URLs targeting internal services.

The exploitation flow typically involves:

1. Authenticating to ZenTao with administrative credentials
2. Navigating to the Webhook Module configuration
3. Creating or modifying a webhook to point to internal resources (e.g., http://localhost:6379/, http://169.254.169.254/latest/meta-data/)
4. Triggering the webhook to cause the server to fetch the malicious URL
5. Observing response data or leveraging access to internal services

Technical details and proof-of-concept information are available in the GitHub Issue Discussion and the VulDB Vulnerability Report.

Detection Methods for CVE-2026-1884

Indicators of Compromise

• Unexpected outbound HTTP/HTTPS requests from the ZenTao server to internal network ranges or cloud metadata endpoints
• Webhook configurations pointing to internal IP addresses (e.g., 127.0.0.1, 10.x.x.x, 172.16.x.x, 192.168.x.x) or metadata services (e.g., 169.254.169.254)
• Unusual administrative activity in the Webhook Module, particularly creation or modification of webhooks by unexpected users
• Network logs showing the ZenTao server initiating connections to unauthorized internal services

Detection Strategies

• Implement network monitoring to detect outbound requests from the ZenTao server to RFC 1918 private addresses or cloud metadata endpoints
• Enable detailed logging for the Webhook Module and monitor for suspicious URL patterns in webhook configurations
• Deploy Web Application Firewall (WAF) rules to detect SSRF patterns in request parameters targeting webhook functionality
• Configure SentinelOne's Singularity platform to monitor for anomalous network behavior from the ZenTao application process

Monitoring Recommendations

• Establish baseline network behavior for the ZenTao server and alert on deviations, particularly outbound connections to new internal destinations
• Monitor authentication logs for privileged access to the Webhook Module administration interface
• Implement egress filtering on the ZenTao server to restrict outbound connections to only necessary external destinations
• Review webhook configurations regularly for unauthorized or suspicious entries

How to Mitigate CVE-2026-1884

Immediate Actions Required

• Restrict access to the Webhook Module to only trusted administrators who require this functionality
• Implement network-level egress filtering to prevent the ZenTao server from connecting to internal network ranges and cloud metadata endpoints
• If webhooks are not actively used, consider disabling the Webhook Module entirely
• Audit existing webhook configurations for any suspicious or unauthorized entries and remove them immediately

Patch Information

As of the last CVE update on February 5, 2026, the vendor (ZenTao) has not responded to disclosure attempts and no official patch is available. Organizations should implement the workarounds below and monitor the VulDB entry and GitHub issue for updates on vendor response or community patches.

Workarounds

• Apply network segmentation to isolate the ZenTao server from sensitive internal systems and services
• Configure web server or reverse proxy rules to block requests to the webhook endpoints from untrusted sources
• Implement URL allowlisting at the application or network level to restrict webhook destinations to pre-approved external domains only
• Use SentinelOne's network control capabilities to enforce egress policies and monitor for SSRF exploitation attempts

# Example: iptables rules to block outbound connections to internal ranges from ZenTao server
# Adjust for your specific network configuration

# Block connections to localhost
iptables -A OUTPUT -d 127.0.0.0/8 -m owner --uid-owner www-data -j DROP

# Block connections to private network ranges
iptables -A OUTPUT -d 10.0.0.0/8 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -m owner --uid-owner www-data -j DROP

# Block connections to cloud metadata endpoints
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner www-data -j DROP