Zammad EUVD-2026-87220

No special conditions - remote unauthenticated exploitation against default configurations of a fully set-up production Zammad instance prior to 7.0.2. The vulnerable actions import_check and import_status lack the setup_done_response guard that other actions in the same controller carry, so they execute even after setup is complete; no account, valid OTRS import configuration, or target knowledge beyond the hostname is required, and the CSRF token is trivially obtained from any prior GET response. The only limiting factors are that the instance must be network-reachable and running a version below 7.0.2; effective denial requires sustaining a modest request rate (a few per second) for as long as the outage is desired.

This is a genuine, easily-triggered availability risk despite being 'only' a DoS. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) and the description agree fully: an unauthenticated remote attacker can trigger it against default production configurations with no special access. Impact is confined to availability (VC:N/VI:N/VA:H) - there is no confidentiality or integrity exposure. The asymmetry is the notable signal: each cheap request forces ~115 seconds of server-side blocking, so a few requests per second exhaust the Puma worker pool and keep the instance down for as long as traffic continues. No EPSS score, CISA KEV listing, or public PoC is provided in the input, so exploitation is 'no public exploit identified at time of analysis'; however, the vulnerability is so trivial (a single documented POST, CSRF token freely obtainable from any GET) that low exploitation friction offsets the absence of an EPSS/PoC signal. Net: a real patching priority for exposed Zammad instances, but tempered by the DoS-only impact and the product's niche footprint - not a critical data-breach event.

An attacker who only knows a Zammad instance's hostname sends repeated unauthenticated POST requests to /api/v1/import/otrs/import_check (grabbing a CSRF token from any prior GET). Each request enters a retry loop against a blank OTRS endpoint, sleeping 30s+45s and tying up a Puma worker for ~115 seconds; a few requests per second saturate the whole worker pool and deny service for the duration of the traffic. No public exploit code is identified, but the attack requires no account, no valid import configuration, and no tooling beyond an HTTP client.