Zammad's AI Agent RCE: a nested template tag, a one-letter fix

Zammad, the open-source helpdesk, released version 7.1.2 on 4 August 2026 with eighteen security fixes; the first one listed closes a remote code execution flaw in the configuration fields of its AI Agent feature. The vulnerability is CVE-2026-84462, disclosed in GitHub advisory GHSA-gp3x-9xm8-rcj6 on the same day, and its affected range is every self-hosted installation on a version up to and including 7.1.1. An administrator who can create or edit an AI Agent could enter specially crafted text into one of the agent's fields, defeat the filter meant to neutralise it, and run arbitrary commands on the server hosting Zammad — with the potential, in the advisory's words, of "reading, modifying, or destroying all data stored on that server." No other user has to act: the advisory states that "the malicious code runs automatically the next time the affected AI Agent processes a ticket." GitHub rates it High at 8.6 on CVSS 4.0. The record, its severity and harm tags, and the entries filed around it are kept in the Orca AI Incident Archive, which lists this incident alongside the rest of the series.

What the advisory establishes

The GitHub advisory, published 4 August 2026, is short and unusually specific about the mechanism and the preconditions. It describes a "security filter that protects Zammad's AI Agent configuration" which "can be bypassed by entering specially crafted text into one of an AI Agent's fields," and it names the actor precisely: "An administrator with permission to create or edit AI Agents could exploit this to run arbitrary commands on the server that hosts Zammad." The affected range is recorded as up to and including 7.1.1, the patched version as 7.1.2. The reporter credited is colinthebomb1; the publishing account is fliebe92. The advisory publishes no proof of concept and no exploit detail.

GitHub rates the flaw High, 8.6 on CVSS 4.0, with the vector AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H and no scope change. Read out, that means the flaw is reachable over the network at low complexity, with no attack requirements and no user interaction, by an attacker who already holds high privileges inside the application, with high impact on the confidentiality, integrity and availability of the Zammad instance itself. The advisory lists three weaknesses: CWE-20, improper input validation; CWE-94, code injection; and CWE-1336, the template-engine class that MITRE defines as failing to neutralise special syntax "that can be interpreted as template expressions or other code directives when processed by the engine."

The fix changed one letter

The public fix is commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, submitted with the message "Maintenance: Improve ERB sanitizer." GitHub records an author date of 7 July 2026 and a commit date of 3 August 2026, one day before the advisory and the release. It touches two files: one line of lib/erb_sanitizer.rb, and fourteen added lines of specification.

The one line is the entire fix. The method escape_tag used Ruby's sub, which replaces the first match of a pattern in a string; it now uses gsub, which replaces every match. In both versions the replacement is the same: an opener written as <% becomes <%%, the doubled form that ERB, Ruby's template engine, renders as literal text instead of evaluating. The advisory does not name which AI Agent field carries the template; the commit identifies the filter that was supposed to make that template inert.

With sub, only the first opener in the string was defused. A payload that puts a second opener immediately after the first survives the filter: <%<%= 1 + 1 %> becomes <%%<%= 1 + 1 %>, where ERB emits the leading opener as text and then evaluates the inner tag. The regression specification added in the same commit names the trick plainly — "with a nested opener smuggled inside a single tag (escape-all-openers bypass)" — and asserts that both <%<%= 1 + 1 %> and a doubly nested <%<%<%= 1 + 1 %> must render as literal text. That spec is the clearest public account of how the filter was got around, because the advisory itself supplies none.

The shape of the bug is generic rather than a Zammad curiosity: an escaper that stops after the first match is defeated by any input carrying a second, nested copy of the sequence it strips. The commit message calls the change maintenance, which is how a single-character hardening patch usually travels — and it is why the advisory, not the diff, had to carry the warning.

Seven weeks from advisory to NVD

NVD published its record for CVE-2026-84462 on 25 September 2026, seven weeks after the advisory, and last modified it on 28 September. The record is marked "Deferred", meaning the agency has not published its own analysis, and its metrics block attributes the 8.6 score to security-advisories@github.com as a secondary metric — GitHub's scoring as the CVE numbering authority, not an independent NVD assessment. The same record carries no CPE configuration at all, so it does not map the flaw to a versioned product identifier.

Both details matter to anyone tracking self-hosted software by feeds rather than by release notes. The fix was public and actionable on 4 August; the machine-readable record arrived on 25 September; and even then it arrived without the product identifier that CPE-based scanners match on. For seven weeks the authoritative account of the flaw was the vendor's advisory and the vendor's release note.

What is established, and what is not

Established: the advisory, the patched version, the CVSS score and the code change all come from Zammad and from GitHub's advisory database, and they agree with each other. NVD's record reproduces the numbering authority's description without adding analysis of its own. The archive grades the entry confidence A on that basis, with the incident undisputed.

Not established, or not recorded: there is no proof of concept in the advisory and no report of exploitation in the wild. FIRST's EPSS gives CVE-2026-84462 a 0.28 percent probability of exploitation in the next thirty days, the 20th percentile, in the score published on 29 October 2026. The archive records no real harm, and files the entry at medium severity — below the advisory's own High band. Those are separate instruments answering different questions, what the flaw would permit against what is known to have happened, and this piece reports both rather than reconciling them.

Independent corroboration is thin. A search for coverage of this CVE returns vulnerability databases that republish the numbering authority's text, plus Zammad's own release note; no news outlet appears to have reported the flaw independently. That is a finding about the record, not a criticism of it: a helpdesk remote code execution that requires an administrator account is not the kind of event that generates press, and the absence of an independent account is itself part of what the record documents.

Who could trigger it, and what changed

Zammad's release note for 7.1.2, dated 4 August 2026, lists the eighteen vulnerabilities patched in that version and puts the AI Agent template bypass first. For hosted customers it says "No action is required. Your instances have already been patched and secured by our team." For self-hosted installations it is blunter: "We strongly advise upgrading to the latest version of Zammad immediately to ensure your system is protected." The advisory offers no workaround, and the record carries no mitigation beyond the upgrade.

The privilege requirement deserves a closer look than the vector gives it. PR:H means the attacker needs significant access before the flaw is useful, and here that access is the admin.ai_agent permission that Zammad's documentation says is required to work with AI Agents at all. In a helpdesk, that is often a service-team lead who tunes categorisers, taggers and text extractors — not necessarily the person who administers the server. The advisory's own phrasing, "an administrator with permission to create or edit AI Agents," is narrower than "anyone" and wider than "root." If an upgrade cannot happen immediately, narrowing who holds that permission reduces the pool of people who can reach the code path; that is an inference from the vector and the documentation, not a remedy the vendor published.

None of the primary documents puts a language model in the exploit path. The command runs inside Zammad's Ruby process when the agent's configuration is rendered; nothing in the advisory, the commit or the release note describes the model producing the payload. The AI Agent feature supplies the administrator-writable, template-processed field, and the AI is the surface rather than the mechanism. That is the pattern the record points at: the agent definition — its instructions, templates and filters — is executable configuration, edited by people whose job is support work, not security review.

Zammad's remedy is proportionate and dull: one method change, two regression tests, and a version bump that closes seventeen other holes alongside this one. The part worth carrying forward is the exposure model. A helpdesk that lets a support lead define an agent also lets that support lead write something the server will execute, and the only thing standing between the two is a filter that has to be right about every nested copy of the syntax it strips.