Zammad’s webhook mechanism did not adequately validate URLs that could point back to the same server or to link‑local ranges, allowing attackers to trigger outbound HTTP/S requests from the helpdesk application. Through such requests, an attacker could cause the application to contact internal or cloud service endpoints and retrieve sensitive metadata, such as cloud instance identifiers or internal network information. The weakness is a classic SSRF vulnerability (CWE‑918) that can lead to information disclosure and potentially further compromise the host if internal services are exposed.

The issue affects Zammad installations running any version before 7.0.1 or 6.5.4. The web‑hooks feature in these releases lacks proper validation of loop‑back and link‑local addresses. Users of the affected Zammad versions are vulnerable until they upgrade to the patched releases.

The CVSS score of 8.3 classifies the vulnerability as High severity. Although EPSS data is not available, the lack of protection against SSRF and the potential to reach internal resources make exploitation likely for an attacker with access to configure webhooks. The vulnerability is not listed in CISA’s KEV catalog, but the impact and availability of public advisories indicate that exploitation could occur in the wild. The attack vector is inferred to be via crafted webhook URLs that an attacker can supply through the Zammad UI or API, resulting in an outbound request from the application to an attacker‑controlled or internal endpoint.