CVE-2026-34719: Zammad Information Disclosure Vulnerability

CVE-2026-34719 Overview

CVE-2026-34719 is a Server-Side Request Forgery (SSRF) vulnerability affecting Zammad, a web-based open source helpdesk and customer support system. The vulnerability exists in the webhook model which lacks proper validation for loopback addresses and link-local addresses. While the application validates the URL scheme (HTTP/HTTPS) and hostname, it fails to prevent requests to internal network addresses. This security gap could allow an attacker with administrative privileges to retrieve confidential metadata from cloud or hosting providers, potentially exposing sensitive infrastructure information.

Critical Impact

Authenticated attackers can exploit inadequate webhook URL validation to access internal cloud provider metadata endpoints, potentially exposing sensitive infrastructure credentials and configuration data.

Affected Products

• Zammad versions prior to 7.0.1
• Zammad versions prior to 6.5.4

Discovery Timeline

• April 8, 2026 - CVE-2026-34719 published to NVD
• April 8, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34719

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery), a weakness category that occurs when a web application fetches remote resources without properly validating user-supplied URLs. In this case, the Zammad webhook functionality allows authenticated administrators to configure webhook endpoints that trigger HTTP requests when certain events occur within the helpdesk system.

The core issue lies in the incomplete validation logic within the webhook model. While the application correctly validates that webhook URLs use HTTP or HTTPS schemes and performs basic hostname checks, it fails to block requests to loopback addresses (such as 127.0.0.1 or localhost) and link-local addresses (such as 169.254.x.x). This oversight enables attackers to craft malicious webhook configurations that target internal network resources.

Cloud environments are particularly at risk because providers like AWS, Azure, and GCP expose instance metadata through well-known internal endpoints (e.g., http://169.254.169.254/). An attacker exploiting this vulnerability could retrieve temporary IAM credentials, instance configuration data, or other sensitive metadata that could facilitate further attacks on the infrastructure.

Root Cause

The root cause of this vulnerability is insufficient input validation in the webhook URL processing logic. The validation routine checks the URL scheme and performs hostname validation but does not adequately filter IP addresses that resolve to internal network ranges. Specifically, the application fails to:

1. Block loopback addresses (127.0.0.0/8)
2. Block link-local addresses (169.254.0.0/16)
3. Prevent DNS rebinding attacks where a hostname initially resolves to an external IP but later resolves to an internal address

The fix implemented in versions 7.0.1 and 6.5.4 extends the existing validation checks and applies them both during webhook configuration and when triggering webhook jobs.

Attack Vector

The attack vector requires network access and authenticated administrative privileges within the Zammad application. An attacker with these privileges can configure a webhook with a malicious URL pointing to internal resources. When the webhook is triggered by system events, Zammad's server makes an HTTP request to the specified URL, effectively acting as a proxy for the attacker.

A typical attack scenario involves:

1. Attacker gains administrative access to the Zammad instance
2. Attacker configures a webhook targeting a cloud metadata endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/)
3. Attacker triggers the webhook through a helpdesk event
4. The server retrieves the metadata and potentially exposes it through response handling or logging
5. Attacker extracts sensitive credentials or infrastructure information

The vulnerability can also be used to scan internal network services, identify open ports, and potentially interact with internal APIs that lack authentication when accessed from trusted internal addresses.

Detection Methods for CVE-2026-34719

Indicators of Compromise

• Webhook configurations containing loopback addresses (127.0.0.1, localhost, ::1)
• Webhook URLs targeting link-local addresses (169.254.x.x)
• Webhook configurations pointing to cloud metadata endpoints
• Unusual outbound HTTP requests from the Zammad server to internal IP ranges
• Access logs showing requests to metadata service endpoints from application servers

Detection Strategies

• Audit existing webhook configurations for URLs containing internal IP addresses or suspicious hostnames
• Monitor network traffic from Zammad application servers for connections to RFC 1918 private address ranges
• Implement DNS logging to detect resolution of hostnames to internal addresses
• Review application logs for webhook execution errors that may indicate SSRF attempts

Monitoring Recommendations

• Configure network monitoring to alert on outbound connections from application servers to cloud metadata endpoints
• Implement web application firewall rules to detect SSRF patterns in webhook configuration requests
• Enable detailed audit logging for webhook configuration changes in Zammad
• Deploy egress filtering on application servers to restrict outbound connections to approved destinations

How to Mitigate CVE-2026-34719

Immediate Actions Required

• Upgrade Zammad to version 7.0.1 or 6.5.4 immediately
• Audit all existing webhook configurations for suspicious URLs targeting internal resources
• Review access logs for evidence of exploitation attempts
• Restrict administrative access to trusted users pending upgrade

Patch Information

Zammad has released security patches in versions 7.0.1 and 6.5.4 that address this vulnerability. The patches extend the existing URL validation to properly block loopback and link-local addresses during both webhook configuration and webhook job execution. Organizations should upgrade to these versions as soon as possible.

For additional details and upgrade instructions, refer to the GitHub Security Advisory.

Workarounds

• Implement network-level egress filtering to block connections from application servers to metadata endpoints and internal ranges
• Use a web application firewall to inspect and block webhook configuration requests containing internal IP addresses
• Restrict webhook configuration privileges to a minimal set of trusted administrators
• Consider disabling webhook functionality entirely until patches can be applied in high-risk environments

# Example: iptables rule to block access to cloud metadata endpoint from application server
# Add this rule on the Zammad application server to prevent SSRF to metadata services
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Block entire link-local range
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# Block loopback (if external processes shouldn't access localhost services)
# Use with caution as this may affect legitimate local services
# iptables -A OUTPUT -d 127.0.0.0/8 -j DROP