RCE im KI-Agenten von Zammad: ein verschachteltes Template-Tag, eine Korrektur mit einem Buchstaben

Zammad, der Open-Source-Helpdesk, veröffentlichte am 4. August 2026 Version 7.1.2 mit achtzehn Sicherheitskorrekturen; die erste aufgeführte schließt eine Schwachstelle für Remotecodeausführung in den Konfigurationsfeldern seiner KI-Agenten-Funktion. Die Schwachstelle ist CVE-2026-84462, offengelegt in der GitHub-Sicherheitsempfehlung GHSA-gp3x-9xm8-rcj6 am selben Tag, und ihr betroffener Bereich umfasst alle selbst gehosteten Installationen mit einer Version bis einschließlich 7.1.1. Ein Administrator, der einen KI-Agenten erstellen oder bearbeiten kann, könnte speziell präparierten Text in eines der Felder des Agenten eingeben, den Filter umgehen, der ihn neutralisieren soll, und beliebige Befehle auf dem Server ausführen, auf dem Zammad gehostet wird – mit dem Potenzial, laut Formulierung der Empfehlung, „alle auf diesem Server gespeicherten Daten zu lesen, zu verändern oder zu zerstören“. Kein anderer Benutzer muss handeln: In der Empfehlung heißt es, dass „der bösartige Code automatisch ausgeführt wird, wenn der betroffene KI-Agent das nächste Mal ein Ticket verarbeitet“. GitHub stuft sie als High mit 8,6 nach CVSS 4.0 ein. Der Datensatz, seine Schweregrad- und Schadens-Tags sowie die Einträge, die rund um ihn erfasst wurden, sind im Orca AI Incident Archive aufbewahrt, das diesen Vorfall zusammen mit dem Rest der Serie aufführt.

Was der Hinweis feststellt

Der am 4. August 2026 veröffentlichte GitHub-Sicherheitshinweis ist kurz und ungewöhnlich konkret hinsichtlich des Mechanismus und der Voraussetzungen. Er beschreibt einen „Sicherheitsfilter, der die Konfiguration des AI Agent von Zammad schützt“, der „umgangen werden kann, indem man in eines der Felder eines AI Agent speziell gestalteten Text eingibt“, und er benennt den Akteur genau: „Ein Administrator mit der Berechtigung, AI Agents zu erstellen oder zu bearbeiten, könnte dies ausnutzen, um beliebige Befehle auf dem Server auszuführen, auf dem Zammad gehostet wird.“ Der betroffene Bereich wird als bis einschließlich 7.1.1 angegeben, die gepatchte Version als 7.1.2. Als Melder wird colinthebomb1 genannt; das veröffentlichende Konto ist fliebe92. Der Hinweis enthält weder einen Proof of Concept noch Einzelheiten zur Ausnutzung.

GitHub bewertet die Schwachstelle als High, 8,6 auf CVSS 4.0, mit dem Vektor AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H und ohne Änderung des Scope. Ausgeschrieben bedeutet das: Die Schwachstelle ist über das Netzwerk bei geringer Komplexität erreichbar, ohne Angriffsvoraussetzungen und ohne Benutzerinteraktion, durch einen Angreifer, der bereits hohe Berechtigungen innerhalb der Anwendung besitzt, mit hoher Auswirkung auf die Vertraulichkeit, Integrität und Verfügbarkeit der Zammad-Instanz selbst. Die Sicherheitsmeldung führt drei Schwachstellen auf: CWE-20, unzureichende Eingabevalidierung; CWE-94, Codeinjektion; und CWE-1336, die Klasse der Template-Engine-Schwachstellen, die MITRE dahingehend definiert, dass spezielle Syntax nicht neutralisiert wird, „die bei Verarbeitung durch die Engine als Template-Ausdrücke oder andere Code-Direktiven interpretiert werden kann“.

Die Korrektur änderte einen Buchstaben.

Der öffentliche Fix ist Commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, eingereicht mit der Nachricht „Maintenance: Improve ERB sanitizer.“ GitHub verzeichnet ein Autorendatum vom 7. Juli 2026 und ein Commit-Datum vom 3. August 2026, einen Tag vor dem Sicherheitshinweis und der Veröffentlichung. Er ändert zwei Dateien: eine Zeile in lib/erb_sanitizer.rb und vierzehn hinzugefügte Zeilen in der Spezifikation.

Die eine Zeile ist die gesamte Korrektur. Die Methode escape_tag verwendete Rubys sub, das das erste Vorkommen eines Musters in einer Zeichenkette ersetzt; jetzt verwendet sie gsub, das jedes Vorkommen ersetzt. In beiden Versionen ist die Ersetzung dieselbe: Ein als <% geschriebener Opener wird zu <%%, die verdoppelte Form, die ERB, Rubys Template-Engine, als Literaltext rendert, anstatt sie auszuwerten. Der Sicherheitshinweis nennt nicht, welches AI Agent-Feld das Template enthält; der Commit identifiziert den Filter, der dieses Template inert machen sollte.

Mit sub wurde nur der erste Opener in der Zeichenkette entschärft. Ein Payload, der unmittelbar nach dem ersten einen zweiten Opener setzt, überlebt den Filter: <%<%= 1 + 1 %> wird zu <%%<%= 1 + 1 %>, wobei ERB den führenden Opener als Text ausgibt und dann das innere Tag auswertet. Die im selben Commit hinzugefügte Regressionsspezifikation benennt den Trick unverblümt – „mit einem verschachtelten Opener, der in ein einzelnes Tag eingeschmuggelt wurde (Escape-all-openers-Bypass)“ – und fordert, dass sowohl <%<%= 1 + 1 %> als auch ein doppelt verschachteltes <%<%<%= 1 + 1 %> als wörtlicher Text gerendert werden müssen. Diese Spezifikation ist die klarste öffentliche Darstellung davon, wie der Filter umgangen wurde, denn das Advisory selbst liefert keine.

Die Form des Bugs ist generisch und nicht etwa eine Zammad-Kuriosität: Ein Escaper, der nach dem ersten Treffer aufhört, wird durch jede Eingabe ausgehebelt, die eine zweite, verschachtelte Kopie der Sequenz enthält, die er entfernt. Die Commit-Nachricht bezeichnet die Änderung als Wartung – so wird ein Härtungspatch für ein einzelnes Zeichen üblicherweise weitergegeben – und deshalb musste der Advisory und nicht der Diff die Warnung enthalten.

Sieben Wochen vom Advisory bis zum NVD

NVD veröffentlichte seinen Datensatz für CVE-2026-84462 am 25. September 2026, sieben Wochen nach der Advisory, und änderte ihn zuletzt am 28. September. Der Datensatz ist als „Deferred“ gekennzeichnet, was bedeutet, dass die Behörde keine eigene Analyse veröffentlicht hat, und sein Metrikblock schreibt die Bewertung 8.6 security-advisories@github.com als sekundäre Metrik zu – GitHubs Bewertung als CVE Numbering Authority, nicht eine unabhängige NVD-Einschätzung. Derselbe Datensatz enthält überhaupt keine CPE-Konfiguration, sodass er die Schwachstelle keinem versionierten Produktidentifikator zuordnet.

Beide Details sind für alle wichtig, die selbst gehostete Software über Feeds statt über Release Notes verfolgen. Der Fix war am 4. August öffentlich und umsetzbar; der maschinenlesbare Eintrag kam am 25. September; und selbst dann kam er ohne die Produktkennung, auf die CPE-basierte Scanner abgleichen. Sieben Wochen lang waren die Sicherheitsmeldung des Herstellers und seine Release Note die maßgebliche Darstellung der Schwachstelle.

Was gilt als gesichert und was nicht

Gesichert ist: Der Sicherheitshinweis, die gepatchte Version, der CVSS-Wert und die Codeänderung stammen alle von Zammad und aus GitHubs Advisory-Datenbank und stimmen miteinander überein. Der NVD-Eintrag gibt die Beschreibung der Nummerierungsstelle wieder, ohne eigene Analyse hinzuzufügen. Das Archiv bewertet den Eintrag auf dieser Grundlage mit der Konfidenzstufe A, wobei der Vorfall unbestritten ist.

Nicht belegt oder nicht dokumentiert: Im Advisory gibt es keinen Proof of Concept und keine Berichte über eine Ausnutzung in freier Wildbahn. Das EPSS von FIRST gibt CVE-2026-84462 in dem am 29. Oktober 2026 veröffentlichten Score eine Wahrscheinlichkeit von 0,28 Prozent für eine Ausnutzung in den nächsten dreißig Tagen an – das 20. Perzentil. Das Archiv verzeichnet keinen realen Schaden und stuft den Eintrag als mittleren Schweregrad ein – unterhalb des eigenen High-Bereichs des Advisorys. Dabei handelt es sich um getrennte Instrumente, die unterschiedliche Fragen beantworten: was die Schwachstelle ermöglichen würde, gegenüber dem, was nachweislich geschehen ist; und dieser Beitrag berichtet über beides, statt sie miteinander in Einklang zu bringen.

Die unabhängige Bestätigung ist dürftig. Eine Suche nach Berichterstattung über diese CVE liefert Schwachstellen-Datenbanken, die den Text der Nummerierungsstelle erneut veröffentlichen, sowie Zammads eigene Release-Anmerkung; kein Nachrichtenmedium scheint die Schwachstelle unabhängig gemeldet zu haben. Das ist eine Feststellung über den Eintrag, keine Kritik an ihm: Eine Remote-Code-Execution in einem Helpdesk, die ein Administratorkonto erfordert, ist nicht die Art von Ereignis, die Presse erzeugt, und das Fehlen einer unabhängigen Darstellung ist selbst Teil dessen, was der Eintrag dokumentiert.

Wer konnte es auslösen, und was hat sich geändert?

Zammads Versionshinweis für 7.1.2 vom 4. August 2026 listet die achtzehn in dieser Version gepatchten Schwachstellen auf und führt den Vorlagen-Bypass des AI Agent an erster Stelle. Für gehostete Kunden heißt es: „Es ist keine Aktion erforderlich. Ihre Instanzen wurden bereits von unserem Team gepatcht und abgesichert.“ Für Self-Hosted-Installationen ist der Ton unmissverständlicher: „Wir raten dringend dazu, sofort auf die neueste Version von Zammad zu aktualisieren, um den Schutz Ihres Systems zu gewährleisten.“ Der Sicherheitshinweis bietet keinen Workaround, und der Eintrag enthält keine über das Upgrade hinausgehende Gegenmaßnahme.

Die Privileg-Anforderung verdient eine genauere Betrachtung, als der Vektor ihr zukommen lässt. PR:H bedeutet, dass der Angreifer signifikanten Zugriff benötigt, bevor die Schwachstelle nutzbar ist, und hier ist dieser Zugriff die Berechtigung admin.ai_agent, die laut der Dokumentation von Zammad überhaupt für die Arbeit mit AI Agents erforderlich ist. In einem Helpdesk ist das oft ein Teamleiter im Service-Team, der Kategorisierer, Tagger und Textextraktoren abstimmt – nicht unbedingt die Person, die den Server administriert. Die Formulierung des Advisories selbst, „ein Administrator mit der Berechtigung, AI Agents zu erstellen oder zu bearbeiten“, ist enger gefasst als „jeder“ und weiter gefasst als „root“. Wenn ein Upgrade nicht sofort erfolgen kann, verringert eine Einschränkung des Kreises der Personen, die diese Berechtigung besitzen, die Anzahl der Menschen, die den Codepfad erreichen können; das ist eine Schlussfolgerung aus dem Vektor und der Dokumentation, keine vom Hersteller veröffentlichte Abhilfe.

Keines der primären Dokumente bringt ein Sprachmodell in den Exploit-Pfad. Der Befehl läuft im Ruby-Prozess von Zammad, wenn die Konfiguration des Agenten gerendert wird; nichts in dem Advisory, dem Commit oder der Release Note beschreibt, dass das Modell die Payload erzeugt. Die Funktion „AI Agent“ liefert das vom Administrator beschreibbare, template-verarbeitete Feld, und die KI ist die Oberfläche, nicht der Mechanismus. Das ist das Muster, auf das der Datensatz verweist: Die Agentendefinition – ihre Anweisungen, Templates und Filter – ist ausführbare Konfiguration, bearbeitet von Personen, deren Aufgabe Supportarbeit und nicht Sicherheitsprüfung ist.

Zammads Gegenmittel ist verhältnismäßig und unspektakulär: eine Methodenänderung, zwei Regressionstests und eine Versionsanhebung, die zusammen mit dieser Lücke siebzehn weitere schließt. Der Teil, der es wert ist, weitergetragen zu werden, ist das Expositionsmodell. Ein Helpdesk, das es einer Support-Leitung erlaubt, einen Agenten zu definieren, erlaubt dieser Support-Leitung auch, etwas zu schreiben, das der Server ausführen wird, und das Einzige, was zwischen beidem steht, ist ein Filter, der bei jeder verschachtelten Kopie der Syntax, die er entfernt, richtig liegen muss.