Zammad CVE-2026-63207

Requires an authenticated Zammad administrator account (PR:H) and that the LDAP and/or Exchange integration be configured with stored credentials (bind password, EWS password, or OAuth access token). The attacker queries the integration administration API - specifically the import job_try responses - where sensitive fields are inconsistently masked and raw request params leak into the returned ImportJob payload. Limiting factors: exploitation is confined to users already holding full administrative privileges, affects only instances that actually use the LDAP or Exchange integrations, and yields disclosure only (no code execution or data modification). Fixed in 7.1.2; affected in 7.0.3 and 7.1.1.

This is a genuine but low-priority confidentiality flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N) is internally consistent with the description: network-reachable admin API, but PR:H means the attacker must already hold Zammad administrator rights. That single gate dramatically narrows real-world risk - the only new capability gained is reading stored LDAP bind and Exchange EWS secrets in cleartext instead of the masked placeholder, i.e. a privilege that a full admin can largely already reach by other means. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or likely exploitation. The commit and regression tests confirm the mechanism (unmasked sensitive fields plus raw request params leaking into the ImportJob payload response), so the vulnerability itself is confirmed, but exploitation status is 'no public exploit identified at time of analysis.' Net: a real hardening fix worth applying, not an urgent emergency - the value lies in credential exposure enabling lateral movement into the connected LDAP/Exchange directory, not in initial compromise.

A malicious or compromised Zammad administrator queries the LDAP or Exchange integration administration API (e.g. the job_try GET endpoint) and receives the configured bind password, EWS password, or OAuth access token in cleartext rather than the expected masked value. The recovered directory/mailbox credentials can then be reused to authenticate directly against the organization's Active Directory/LDAP or Microsoft Exchange environment. No public exploit code is identified; exploitation requires existing administrator access.