Sådan kan et krypteret webangreb omgå Groks sikkerhedsfiltre

Adversa oplyste, at teknikken blev testet mod Grok 4.5 Fast på grok.com. En separat beskrivelse af testene angiver, at angrebet lykkedes i 40 procent af 20 forsøg mellem juni og august 2026. Det resultat gælder forskernes testmiljø og er ikke en garanti for, at alle forsøg eller alle Grok-sessioner ville blive kompromitteret.

Sådan fungerer angrebet på websiden

Den beskrevne angrebskæde består af flere trin:

1. Websiden skjuler nyttelasten. Angriberen placerer krypterede data, instruktioner til dekryptering og nøglemateriale på en webside, der ellers kan ligne almindeligt indhold. Den rapporterede konstruktion bruger PBKDF2-baseret nøgleafledning og AES-256-GCM-kryptering.

2. Den første scanning overser kommandoen. Groks filtre kan undersøge det synlige indhold på siden, men den farlige instruktion er skjult i krypterede data. Stærk kryptering forhindrer modellen i direkte at fortolke kommandoens klartekst i første gennemgang.

3. Agenten dekrypterer indholdet. Når brugeren beder Grok om at opsummere eller analysere siden, følger agenten sidens instruktioner og kører dekrypteringen i sit kodekørselsmiljø.

4. Kommandoen kommer tilbage i konteksten. Den dekrypterede tekst præsenteres som resultatet af en værktøjshandling. Dermed opstår et såkaldt provenance-problem: Angriberstyret indhold fra en upålidelig webside kan nu fremstå som et resultat fra et værktøj, som agenten har større tillid til.

5. Grok finder data i den private session. I proof of concept-testen bad den dekrypterede instruktion Grok om at hente værdier som brugerens navn, omtrentlige placering, abonnementstype og prompts fra den tilgængelige samtalekontekst.

6. En browserforespørgsel sender dataene ud. Grok åbnede derefter en angriberstyret URL og placerede de indsamlede oplysninger i URL’ens forespørgselsparametre. Den rapporterede demonstration blev gennemført uden en ekstra bekræftelse eller synlig advarsel.

Der er dog en vigtig begrænsning. Den tilgængelige dokumentation understøtter adgang til prompts og kontekst, som agenten fik stillet til rådighed i den aktive session. Formuleringer om en »fuld chathistorik« bør derfor ikke automatisk forstås som adgang til enhver samtale, der er gemt på brugerens konto.

Hvornår blev fejlen rapporteret til xAI?

Adversa oplyste, at problemet blev rapporteret til xAI via HackerOne den 3. juni 2026. Forskerne sendte efterfølgende opfølgende henvendelser om koordinering den 4. og 10. august.

Den 19. august 2026 sagde Adversa, at virksomheden ikke havde modtaget et substantielt svar, og at angrebet fortsat kunne reproduceres mod Grok. Den rapportering, der var tilgængelig på det tidspunkt, beskrev problemet som uden offentlig rettelse, CVE-nummer eller brugervendt workaround.

Statussen skal læses som en forsker- og mediebeskrivelse af offentliggørelsesforløbet – ikke som en officiel sikkerhedsmeddelelse fra xAI. Den tilgængelige dokumentation fastslår heller ikke, at angribere har brugt teknikken mod virkelige brugere uden for forskernes demonstrationer.

Hvorfor kan kryptering skabe en blind vinkel?

Traditionelle forsvar mod prompt-injektion forsøger ofte at genkende mistænkeligt sprog i det indhold, et AI-system henter. Cryptographic Context Injection flytter den farlige instruktion til et senere trin i behandlingen.

Modellen behøver ikke at forstå den skadelige kommando, da den første gang scanner siden. Den skal blot følge en tilsyneladende nyttig instruktion – for eksempel at køre en dekrypteringsrutine – i et runtime-miljø, som systemet selv har tillid til. Kommandoen bliver først læsbar efter dette trin, når agenten muligvis allerede har adgang til privat kontekst og tilladelse til at browse eller foretage netværkskald.

Derfor bør sårbarheden først og fremmest forstås som et arkitekturproblem i AI-agenter og ikke blot som et mislykket filter mod bestemte søgeord. Når en agent kan læse eksternt indhold, køre kode, tilgå sessionsdata og bruge netværksværktøjer, kan en ondsindet instruktion omdanne disse funktioner til en kanal for dataeksfiltrering.

En del af et større sikkerhedsproblem

Grok-afsløringen føjer sig til en bredere række eksempler, hvor upålideligt indhold manipulerer assistenter med adgang til følsomme data eller kraftfulde værktøjer.

• Microsoft 365 Copilot og EchoLeak: Et studie af EchoLeak dokumenterede en zero-click-prompt-injektion i Microsoft 365 Copilot, som muliggjorde fjernbaseret og uautoriseret dataeksfiltrering via en særligt udformet e-mail. Sårbarheden er registreret som CVE-2025-32711.
• Microsoft Copilot Personal og CoSnitch: Forskere fra Varonis beskrev, hvordan gentagen manipulation af Copilots ræsonnement kunne få følsomme data sendt til en ekstern server og samtidig forgifte assistentens permanente hukommelse.
• Angreb mod AI-kodeagenter: I Adversas TrustFall-forskning blev det beskrevet, hvordan skadelig konfiguration i et kodearkiv kunne få et angriberstyret MCP-system til at køre kommandoer gennem kodeassistenter som Claude Code, Gemini CLI, Cursor CLI og GitHub Copilot CLI.

Fælles for angrebene er, at angriberen ikke nødvendigvis behøver at kompromittere selve modellen eller operativsystemet direkte. I stedet leverer angriberen indhold, som agenten er designet til at læse, og udnytter derefter agentens egne tilladelser til at hente information, kalde værktøjer, ændre tilstand eller sende en netværksforespørgsel.

Hvilke forsvar peger afsløringen på?

Angrebet viser, at sikkerheden omkring AI-agenter kræver mere end stærkere filtre mod prompt-injektion. Centrale kontrolforanstaltninger er blandt andet:

• Tydelig oprindelse: Websider og værktøjsresultater bør både teknisk og visuelt holdes adskilt fra systeminstruktioner og betroet applikationstilstand.
• Begrænset kodekørsel: Indhold, der hentes fra nettet, bør ikke kunne udløse vilkårlig dekryptering eller anden kode uden en stramt afgrænset politik og sandbox.
• Mindst mulige privilegier: Begræns, hvilke private oplysninger agenten kan tilgå, så en almindelig opsummeringsopgave ikke kan eksponere uvedkommende sessionsdata.
• Godkendelse ved følsomme handlinger: Netværksforespørgsler, der indeholder bruger- eller samtaledata, bør kræve en tydelig og meningsfuld bekræftelse.
• Kontrol af udgående trafik: Domæne-allowlister, proxy-inspektion og egress-kontroller kan forhindre agenter i at sende kontekstdata til vilkårlige URL’er.
• Overvågning af værktøjskæder: Usædvanlige sekvenser – eksempelvis websidehentning efterfulgt af kodekørsel, udtræk af kontekst og ekstern navigation – bør logges og udløse alarmer.

Den centrale pointe er enkel: Et AI-system må ikke automatisk betragte indhold som troværdigt, blot fordi det er produceret af et værktøj. I Groks rapporterede tilfælde blev en webside forvandlet til et dekrypterings- og eksekveringsforløb, hvorefter agentens egne privilegier blev brugt til at føre private kontekstdata ud af sessionen.