Zammad CVE-2026-56732

Requires an affected Zammad instance prior to 7.0.2 whose HTML sanitizer fails to strip image/srcset references to same-origin state-changing GET endpoints (/api/v1/signout, /api/v1/sessions/switch/N, /api/v1/sessions/switch_back, /api/v1/getting_started/auto_wizard/token). The attacker must get crafted HTML into a ticket body (achievable unauthenticated via inbound email, or authenticated via ticket creation), AND a second user must subsequently VIEW that ticket in a browser with an active session (UI:P) - this victim interaction is the primary limiting factor. Impact is bounded to terminating/altering the viewer's session; there is no data exposure or code execution, and no special non-default configuration is required beyond running a vulnerable version.

This is a genuinely low-to-moderate issue that the CVSS 4.0 score (5.3, MEDIUM) already frames accurately as an availability-only problem. The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L confirms no confidentiality (VC:N) or integrity (VI:N) impact - the only consequence is VA:L, terminating the viewing user's session. Exploitation is network-borne and low-complexity, but requires victim interaction (UI:P): an agent must actually open the malicious ticket. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so no signals point to active or imminent exploitation; the fix commit and its RSpec test cases do, however, publicly document the exact payload (<img src='/api/v1/signout'>), which lowers the bar for a would-be attacker. Note a nuance: while PR:N (unauthenticated) is defensible because Zammad ingests tickets from inbound email, the practical worst case is only a forced logout of another agent - a nuisance/denial-of-session, not data theft or takeover. The 'Code Injection' tag overstates the mechanism; this is really same-origin HTML-injection/login-CSRF against state-changing GET endpoints, not code execution.

An attacker sends an email to the Zammad helpdesk (or otherwise creates a ticket) whose body contains an image tag pointing at a same-origin state-changing GET endpoint, e.g. <img src='/api/v1/signout'>. When a support agent opens the ticket, their browser automatically issues the GET request with their session cookie, terminating their session (or, via /api/v1/sessions/switch/N, altering session state). No public exploit tooling exists, but the payload is disclosed in the fix's test suite.