WebSocket Session Disclosure and Remote Code Execution in Zammad

The repository contains six files: one README, three Ruby programs, and two POSIX shell scripts. It is a standalone laboratory reproduction, not a framework module or a working exploit against live Zammad. minibox_server.rb replaces WebSocket framing with newline-delimited JSON over TCP, keeps every connected client's handshake headers in a shared registry, deliberately invokes the nonexistent registry method foo, logs e.inspect, and returns e.message to the requesting client. On a Ruby runtime that includes the hash receiver in the exception text, this exposes other clients' cookies. minibox_attack.rb creates both the synthetic victim and unauthenticated attacker, sends the trigger event, extracts the hardcoded victim cookie's token, and submits a login event with that token. The server's fake session store then associates the attacker connection with admin@example.com. The actual production event needed to trigger the exception is explicitly undisclosed, and no RCE or post-exploitation payload is supplied. ruby_behavior_probe.rb isolates the exception-rendering dependency and exits with status 1 when cookie material appears. ioc_check.sh searches ordinary and compressed logs for ERROR lines containing a Cookie hash entry or @clients registry, reports matching lines, and prints distinct exposed cookies. It returns status 0 whether indicators are present or absent, so automation must inspect its output. ioc_check_test.sh feeds it a synthetic matching log line and conditionally downloads the scanner if missing; it does not assert the result. Its rm -rf operation is scoped to a generated temporary directory and is ordinary cleanup, not evidence of a fake exploit. Important limitations include a possible timing race between registration of the victim connection and the attacker's trigger, hardcoded token extraction, and loopback-only server binding, which also means the README's published-port Docker example does not by itself make the service reachable through the container interface. The README attributes CVE-2026-102489 to Zammad 6.3.x–6.5.x and claims a subsequent RCE chain, real-world exploitation, and KEV inclusion; these external claims are not verified by the supplied files. Repository URL, revision, and archive size were not supplied; the listed file sizes total 19,462 bytes, which is not an archive-size measurement.

The supplied repository contains two files: a standalone Python exploit (7,574 bytes) and a README (2,706 bytes). The Python script embeds a Ruby ERB command-execution payload; no exploit framework, dependency manifest, or tests are present. It sends an unauthenticated WebSocket event named base, expecting a Ruby NoMethodError to disclose the shared @clients map and connected users' session cookies. It validates those cookies through the users/me API, preferentially selects a session containing role ID 1, obtains a CSRF token, and uploads the ZammadRceAddon package containing a malicious password-reset mailer template. A password-reset request then attempts to execute the operator's command, defaulting to id, as the Zammad service user. Cleanup attempts package removal but suppresses exceptions and does not explicitly remove the output file. The script reports execution after a fixed delay without verifying output, so its success messages are not proof of compromise. HTTP requests disable TLS certificate verification. No reverse shell, external exfiltration destination, or direct command-output retrieval is implemented. The repository claims CVE-2026-102489 affects Zammad <= 6.5.4 and is fixed in 7.2.0; these claims and runtime exploitability cannot be independently verified from the supplied files. The Git reference and archive size were not supplied: ref is empty and size_bytes is 0 to represent unavailable metadata; the listed file sizes total 10,280 bytes.