Zammads AI-agent-RCE: en nästlad malltagg, en fix på en bokstav

Zammad, helpdesken med öppen källkod, släppte version 7.1.2 den 4 augusti 2026 med arton säkerhetskorrigeringar; den första i listan stänger en fjärrkodkörningssårbarhet i konfigurationsfälten för funktionen AI Agent. Sårbarheten är CVE-2026-84462, som offentliggjordes i GitHub-rådgivningen GHSA-gp3x-9xm8-rcj6 samma dag, och dess påverkade intervall omfattar samtliga självhostade installationer på versioner upp till och med 7.1.1. En administratör som kan skapa eller redigera en AI Agent kunde ange specialutformad text i ett av agentens fält, kringgå filtret som var tänkt att neutralisera den och köra godtyckliga kommandon på servern som hostar Zammad – med potentialen, enligt rådgivningens formulering, att "läsa, ändra eller förstöra all data som lagras på den servern." Ingen annan användare behöver göra något: rådgivningen anger att "den skadliga koden körs automatiskt nästa gång den drabbade AI Agenten bearbetar ett ärende." GitHub klassar den som High med 8,6 på CVSS 4.0. Posten, dess allvarlighetsgrad och skadetaggar samt posterna som registrerats kring den finns i Orca AI Incident Archive, som listar denna händelse tillsammans med resten av serien.

Vad rådgivningen fastställer

GitHub-rådgivningen, som publicerades den 4 augusti 2026, är kort och ovanligt specifik om mekanismen och förutsättningarna. Den beskriver ett "säkerhetsfilter som skyddar Zammads AI Agent-konfiguration" vilket "kan kringgås genom att ange särskilt utformad text i ett av AI Agentens fält", och den namnger aktören exakt: "En administratör med behörighet att skapa eller redigera AI Agenter kunde utnyttja detta för att köra godtyckliga kommandon på servern som hostar Zammad." Det påverkade intervallet anges som upp till och med 7.1.1, den patchade versionen som 7.1.2. Reportern som krediteras är colinthebomb1; publiceringskontot är fliebe92. Rådgivningen publicerar inget proof of concept och inga exploit-detaljer.

GitHub bedömer sårbarheten som Hög, 8,6 enligt CVSS 4.0, med vektorn AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H och utan scopeändring. Läst i klartext innebär det att sårbarheten är nåbar över nätverket med låg komplexitet, utan attackkrav och utan användarinteraktion, av en angripare som redan har höga privilegier i applikationen, med hög påverkan på konfidentialitet, integritet och tillgänglighet för själva Zammad-instansen. Rådgivningen listar tre svagheter: CWE-20, otillräcklig indatavalidering; CWE-94, kodinjicering; och CWE-1336, den klass av svagheter som rör mallmotorer och som MITRE definierar som att specialsyntax inte neutraliseras "som kan tolkas som malluttryck eller andra kodirektiv när de behandlas av motorn."

Fixen ändrade en bokstav

Den offentliga rättelsen är commit e3b0c8df91ad2108c8305be23e8fe6f73fb9718d, inlämnad med meddelandet "Underhåll: Förbättra ERB-saneraren." GitHub registrerar ett författardatum den 7 juli 2026 och ett commit-datum den 3 augusti 2026, en dag före säkerhetsmeddelandet och utgåvan. Den berör två filer: en rad i lib/erb_sanitizer.rb och fjorton tillagda rader specifikation.

Den enda raden är hela rättelsen. Metoden escape_tag använde Rubys sub, som ersätter den första träffen av ett mönster i en sträng; nu använder den gsub, som ersätter alla träffar. I båda versionerna är ersättningen densamma: en öppnare skriven som <% blir <%%, den dubblerade form som ERB, Rubys mallmotor, renderar som literal text i stället för att utvärdera. Säkerhetsmeddelandet anger inte vilket AI Agent-fält som innehåller mallen; commiten identifierar filtret som var tänkt att göra mallen overksam.

Med sub avväpnades endast den första öppnaren i strängen. En payload som placerar en andra öppnare omedelbart efter den första överlever filtret: <%<%= 1 + 1 %> blir <%%<%= 1 + 1 %>, där ERB utmatar den ledande öppnaren som text och sedan evaluerar den inre taggen. Regressionsspecifikationen som lades till i samma commit beskriver tricket rakt ut – "med en nästlad öppnare insmugglad i en enda tagg (escape-all-openers-bypass)" – och slår fast att både <%<%= 1 + 1 %> och en dubbelt nästlad <%<%<%= 1 + 1 %> måste renderas som literal text. Den specen är den tydligaste offentliga redogörelsen för hur filtret kringgicks, eftersom säkerhetsmeddelandet självt inte ger någon.

Buggens form är generisk snarare än en Zammad-kuriositet: en escaper som stoppar efter första träffen kan överlistas av vilken indata som helst som bär en andra, nästlad kopia av sekvensen den rensar bort. Commit-meddelandet kallar ändringen underhåll, vilket är så en hårdningspatch på ett enda tecken vanligtvis sprids – och det är därför rådgivningen, inte diffen, måste bära varningen.

Sju veckor från säkerhetsmeddelande till NVD

NVD publicerade sin post för CVE-2026-84462 den 25 september 2026, sju veckor efter rådgivningen, och ändrade den senast den 28 september. Posten är markerad "Deferred", vilket innebär att myndigheten inte har publicerat sin egen analys, och dess mätvärdesblock tilldelar poängen 8,6 till security-advisories@github.com som ett sekundärt mätvärde – GitHubs poängsättning i egenskap av CVE-nummerutfärdare, inte en oberoende NVD-bedömning. Samma post innehåller överhuvudtaget ingen CPE-konfiguration, så den kopplar inte sårbarheten till någon versionerad produktidentifierare.

Båda detaljerna är viktiga för alla som spårar självhostad programvara via flöden i stället för via versionsinformation. Korrigeringen var offentlig och åtgärdbar den 4 augusti; den maskinläsbara posten kom den 25 september; och även då kom den utan den produktidentifierare som CPE-baserade skannrar matchar på. Under sju veckor var den auktoritativa beskrivningen av sårbarheten leverantörens säkerhetsråd och leverantörens versionsinformation.

Vad som är fastställt, och vad som inte är det

Fastställt: rådgivningen, den patchade versionen, CVSS-poängen och kodändringen kommer alla från Zammad och från GitHubs rådgivningsdatabas, och de stämmer överens med varandra. NVD:s post återger numreringsmyndighetens beskrivning utan att tillföra någon egen analys. Arkivet ger posten tillförlitlighetsbetyget A på den grunden, och incidenten är obestridd.

Inte fastställt, eller inte dokumenterat: det finns inget proof of concept i rådgivningen och ingen rapport om exploatering i det vilda. FIRST:s EPSS ger CVE-2026-84462 en sannolikhet på 0,28 procent för exploatering under de kommande trettio dagarna, den 20:e percentilen, i den poäng som publicerades den 29 oktober 2026. Arkivet registrerar ingen verklig skada och placerar posten på medelallvarlighetsgrad – under rådgivningens egen High-nivå. Det är separata instrument som besvarar olika frågor – vad sårbarheten skulle möjliggöra jämfört med vad som är känt att ha inträffat – och den här artikeln rapporterar båda i stället för att förena dem.

Oberoende bekräftelse är tunn. En sökning efter bevakning av denna CVE ger sårbarhetsdatabaser som återpublicerar numreringsmyndighetens text, plus Zammads egen releaseanteckning; ingen nyhetskanal verkar ha rapporterat om felet oberoende. Det är ett konstaterande om registret, inte en kritik av det: en fjärrkodskörning i en helpdesk som kräver ett administratörskonto är inte den sorts händelse som genererar press, och frånvaron av en oberoende redogörelse är i sig en del av det som registret dokumenterar.

Vem skulle kunna utlösa det, och vad förändrades

Zammads versionsanteckning för 7.1.2, daterad 4 augusti 2026, listar arton sårbarheter som rättats i den versionen och lyfter först kringgåendet av AI Agent-mallen. För kunder med hostad tjänst står det: "Ingen åtgärd krävs. Vårt team har redan patchat och säkrat dina instanser." För självhostade installationer är tonen rakare: "Vi rekommenderar starkt att du omedelbart uppgraderar till den senaste versionen av Zammad för att säkerställa att ditt system är skyddat." Säkerhetsmeddelandet innehåller ingen workaround, och posten anger ingen riskreducerande åtgärd utöver uppgraderingen.

Behörighetskravet förtjänar en närmare granskning än vad vektorn antyder. PR:H betyder att angriparen behöver betydande åtkomst innan sårbarheten är användbar, och här är den åtkomsten behörigheten admin.ai_agent som Zammads dokumentation säger krävs för att över huvud taget arbeta med AI Agents. På en helpdesk är det ofta en serviceteamledare som justerar kategoriserare, taggare och textextraktorer – inte nödvändigtvis personen som administrerar servern. Säkerhetsrådgivningens egen formulering, ”en administratör med behörighet att skapa eller redigera AI Agents”, är snävare än ”vem som helst” och bredare än ”root”. Om en uppgradering inte kan genomföras omedelbart minskar en begränsning av vem som har den behörigheten poolen av personer som kan nå kodvägen; det är en slutledning från vektorn och dokumentationen, inte en åtgärd som leverantören har publicerat.

Inget av primärdokumenten placerar en språkmodell i exploateringskedjan. Kommandot körs i Zammads Ruby-process när agentens konfiguration renderas; inget i säkerhetsrådgivningen, incheckningen eller versionsinformationen beskriver att modellen producerar nyttolasten. Funktionen AI Agent tillhandahåller det mallbearbetade fält som administratören kan skriva i, och AI är ytan snarare än mekanismen. Det är mönstret som materialet pekar på: agentdefinitionen – dess instruktioner, mallar och filter – är körbar konfiguration som redigeras av personer vars arbete är support, inte säkerhetsgranskning.

Zammads åtgärd är proportionerlig och tråkig: en metodändring, två regressionstester och en versionsbump som stänger sjutton andra hål vid sidan av detta. Det som är värt att ta med sig vidare är exponeringsmodellen. En helpdesk som låter en supportansvarig definiera en agent låter också den supportansvariga skriva något som servern kommer att köra, och det enda som står mellan de två är ett filter som måste ha rätt om varje nästlad kopia av syntaxen det rensar bort.