Salattu prompt-injektio voi muuttaa Grokin keskustelutietojen vuototyökaluksi

Adversa AI:n tutkija Rony Utevsky raportoi xAI:n Grok-verkkotoimintoon kohdistuvasta niin sanotusta nollaklikkausta vaativasta epäsuorasta prompt-injektiosta. Hyökkäyksen perusidea on yksinkertainen: käyttäjä pyytää Grokia tiivistämään tai analysoimaan hyökkääjän hallinnoimaa verkkosivua. Sivu piilottaa varsinaiset ohjeet salattuun dataan, minkä jälkeen Grok saadaan purkamaan ja käsittelemään ne omassa suoritusympäristössään.

Raportoitu vaikutus on vakava. Purettu sisältö voi ohjata agentin hakemaan yksityisiä istunto- ja keskustelutietoja sekä liittämään ne ulkopuoliselle palvelimelle tehtävään pyyntöön. Näyttö perustuu tällä hetkellä pääasiassa Adversa AI:n ilmoitukseen ja sitä käsitteleviin uutisraportteihin. Siksi kyseessä on raportoiduksi hyökkäyksen toimivuuden osoitukseksi tarkoitettu proof of concept, ei itsenäisesti vahvistettu xAI:n havainto.

Mitä Cryptographic Context Injection tarkoittaa?

Perinteiset prompt-injektioiden torjuntakeinot etsivät tekstistä epäilyttäviä käskyjä. Adversan kuvaama tekniikka pyrkii kiertämään tällaisen tarkistuksen siirtämällä haitalliset ohjeet verkkosivulle salakirjoitettuna tekstinä. Raportin mukaan sivu sisältää AES-256-GCM-salatun JSON-paketin, avainmateriaalin ja ohjeita, joiden avulla Grok voidaan saada suorittamaan purkukoodi Python- tai hiekkalaatikkoympäristössään.

Kyse ei siis ole hyökkäyksestä AES-salausalgoritmia vastaan. Salausta käytetään väistökeinona: sisältösuodatin näkee vaikeaselkoista salakirjoitustekstiä, mutta agentilla on myöhemmin työkalut sen muuttamiseen takaisin toimintaohjeiksi.

Tämä ero on tietoturvan kannalta ratkaiseva. Näkyvän tekstin suodattaminen ei vielä kerro, mitä agentti saa tehdä sen jälkeen, kun se on jäsentänyt, purkanut tai suorittanut epäluotettavasta lähteestä peräisin olevan sisällön.

Näin raportoitu hyökkäysketju etenee

Hyökkäys voidaan kuvata neljänä vaiheena:

1. Haitallinen sivu näyttää tavalliselta. Käyttäjä pyytää Grokia tiivistämään tai analysoimaan sivulla olevaa sisältöä.
2. Sivu toimittaa salatun paketin ja purkuohjeet. Adversan mukaan hyötykuorma käyttää AES-256-GCM:ää ja PBKDF2-menetelmällä johdettua avainta. Näin varsinaiset ohjeet pysyvät aluksi piilossa tekstin tarkistukselta.
3. Grok suorittaa purkulogiikan. Selväkieliset ohjeet ilmestyvät raportin mukaan mallin koodi- tai työkalusuorituspolussa, eivät alkuperäisellä verkkosivulla helposti havaittavana tekstinä. Adversa kertoo Grokin käsitelleen tulosta tämän jälkeen luotettuna kontekstina.
4. Hyötykuorma ohjaa seuraavaa toimintoa. Ohjeiden kerrotaan käskevän Grokia selvittämään yksityisiä istuntotietoja, sijoittamaan ne URL-osoitteeseen ja avaamaan osoitteen. Tällä tavoin tiedot voidaan välittää hyökkääjän hallinnoimalle palvelimelle.

Adversan esittelemässä proof of concept -tapauksessa mukana olivat käyttäjän nimi, likimääräinen sijainti, tilauksen taso, kehotteet ja keskusteluhistoria. Yhtiön mukaan tiedonsiirto onnistui esittelyssä ilman näkyvää varoitusta tai vahvistuspyyntöä.

Todellinen ongelma on suoritusympäristön luottamusraja

Ongelma ei ole vain siinä, että Grokille näytetään haitallinen kehote. Raportin perusteella epäluotettavalta verkkosivulta peräisin oleva data ylittää useita luottamusrajoja:

• verkkosivun sisällöstä tulee suoritettavaa tai toimintaa ohjaavaa kontekstia;
• purettua tulosta kohdellaan alkuperään nähden liian luotettavana;
• yksityinen keskustelu- tai istuntokonteksti tulee hyökkäysketjun saataville; ja
• agentti voi käyttää ulkoista pyyntöä tietojen siirtämiseen pois istunnosta.

Ohjeesta ei tule luotettavaa vain siksi, että salauksen purkurutiini tuotti sen, työkalu palautti sen tai se sijoitettiin väliaikaiseen suoritusympäristöön. Tiedon alkuperän on säilyttävä näkyvissä näiden muunnosten läpi. Muuten hyökkääjä voi käyttää jäsentämistä, koodin suorittamista, tiedonhakua tai työkalujen tuloksia epäluotettavan sisällön muuttamiseen näennäisesti auktoritatiiviseksi ohjeeksi.

Ilmoitusaikataulu ja tämänhetkinen tila

Adversan mukaan Utevsky ilmoitti ongelmasta xAI:lle ja HackerOne-palvelun kautta 3. kesäkuuta 2026. Adversan 20. elokuuta julkaisemassa ilmoituksessa sanotaan, että ongelma oli seurantayhteydenotoista huolimatta ollut korjaamatta yli kaksi kuukautta.

Saatavilla olevissa raporteissa ei ilmoituksen aikaan ollut julkista xAI:n vastausta, CVE-tunnistetta, korjausta tai aikataulua ongelman ratkaisemiseksi. Tämä perustuu tutkijan ilmoitukseen ja samanaikaiseen uutisointiin; mukana ei ole itsenäisesti julkaistua xAI:n lausuntoa, joka vahvistaisi havainnon tai sen korjaamisen.

Mitä pitäisi korjata?

Adversan suositukset kohdistuvat ennen kaikkea agentin ajonaikaiseen hallintaan, eivät uusien avainsanasuodattimien lisäämiseen. Keskeisiä toimia ovat:

• Säilytä alkuperä- ja tartuntatiedot. Verkkosivulta peräisin olevan sisällön pitäisi pysyä epäluotettavana myös jäsentämisen, salauksen purkamisen, koodin suorittamisen tai työkalukutsun jälkeen.
• Erota data ja auktoriteetti. Epäluotettava sisältö tai siitä johdetut arvot eivät saisi kutsua etuoikeutettuja työkaluja, avata yksityistä keskustelukontekstia tai määrittää arkaluonteisten työkalukutsujen parametreja.
• Rajoita ulospäin suuntautuvaa liikennettä. Agentin pitäisi käyttää sallittujen kohteiden listoja, kohderajoituksia ja tietovuotojen estomekanismeja ennen tietojen lähettämistä uudelle ulkopuoliselle palvelimelle.
• Vaadi ymmärrettävä suostumus. Yksityistä kontekstia tai ulkoista tiedonsiirtoa koskevan toiminnon pitäisi edellyttää käyttäjän selvää vahvistusta. Vahvistuksessa tulee kertoa, mitä tietoja istunnosta poistuu ja minne ne lähetetään.
• Noudata vähimmän oikeuden periaatetta. Pelkkä tiivistämistehtävä ei saisi automaattisesti antaa pääsyä koko keskusteluhistoriaan, profiilitietoihin, koodin suoritukseen tai rajoittamattomaan verkkoyhteyteen.

Nämä suojaukset puuttuvat vaaralliseksi muuttuvasta yhdistelmästä, jossa epäluotettava syöte, yksityinen konteksti, koodin suoritus ja toimintakykyiset työkalut pääsevät vaikuttamaan toisiinsa. Pelkkä mallin kieltäytymiskäyttäytyminen ei riitä tietoturvan rajaksi.

Yhteys muihin AI-agentteihin kohdistuneisiin hyökkäyksiin

Grokia koskeva raportti liittyy laajempaan ilmiöön. Hyökkääjä muokkaa sisältöä, jota agentin pyydetään käsittelemään, ja hyödyntää sen jälkeen agentille jo myönnettyjä oikeuksia.

Microsoft 365 Copilotin EchoLeak kuvattiin nollaklikkausta vaativaksi prompt-injektiohaavoittuvuudeksi, jossa muotoiltu sähköpostiviesti saattoi mahdollistaa avustajan saatavilla olevien tietojen etävuotamisen ilman tunnistautumista. Akateemisessa tapaustutkimuksessa ongelma yhdistetään tunnisteeseen CVE-2025-32711.

Microsoft Copilot Personalista tehdyissä erillisissä raporteissa kuvattu CoSnitch-ketju puolestaan hyödynsi muotoiltua linkkiä, jonka avulla voitiin käynnistää kehotteita ja vuotaa tietoja yhdistetyistä sovelluksista. Tutkijat kertoivat Microsoftin julkaisseen korjaukset 18. elokuuta 2026.

Koodausagentteihin kohdistuvissa tapauksissa hyökkäysreitti on verkkosivun sijaan usein koodivarasto. Adversa raportoi, että haitalliset repositoriot voivat hyödyntää useiden koodausavustajien luottamus- ja asetuskäytäntöjä, mukaan lukien Claude Code, Cursor CLI, Gemini CLI ja Copilot CLI. Näin hyökkääjän hallinnoima MCP-palvelin voidaan käynnistää mahdollisesti laajoilla oikeuksilla. Toisessa Adversan raportissa kuvattiin repositoriopohjainen käytäntöjen ohitus, joka liittyi pitkiin komentoketjuihin ja mahdolliseen tunnistetietojen tai salaisuuksien varastamiseen.

Jakelutapa vaihtelee — sähköposti, URL-osoite, asiakirja, repositorio, salattu verkkosivu tai työkaluliitäntä — mutta arkkitehtuurin perusopetus on sama: agentin ei pidä muuttaa hyökkääjän hallinnoimaa sisältöä luvaksi lukea luottamuksellisia tietoja tai tehdä ulkoisia toimia.

Laajempi tietoturvavaikutus

Cryptographic Context Injection osoittaa, miksi agenttien tietoturva ei voi rajoittua konteksti-ikkunaan ensin saapuvan tekstin skannaamiseen. Ohjeita voi ilmestyä myös salauksen purkamisen, tiedonhaun, jäsentämisen, koodin suorituksen, muistin käytön tai muun työkalukutsun jälkeen. Jos jokainen muunnos hävittää tiedon alkuperän, hyökkääjä voi hyödyntää eroa sen välillä, mikä järjestelmä luokittelee epäluotettavaksi ja mitä suoritusympäristö myöhemmin kohtelee luotettavana.

Käyttäjälle käytännön neuvo on olla varovainen, kun yksityisiin keskusteluihin tai työkaluihin pääsevää agenttia pyydetään käsittelemään tuntemattomia verkkosivuja, asiakirjoja, linkkejä tai koodivarastoja. Kehittäjille viesti on vielä suorempi: suoritusympäristön luottamusrajat on pakotettava teknisesti, pääsy arkaluonteiseen kontekstiin on rajattava, työkalujen parametreja on valvottava, verkkoliikenteen ulospääsyä on kontrolloitava ja vaikutuksiltaan merkittävistä toimista on tehtävä näkyviä ja vahvistettavia.

Raportoitu Grok-tekniikka ei näin ollen ole ensisijaisesti tapa ”murtaa AES:ää”. Se on varoitus auktoriteetin väärentämisestä: salattu sisältö voi piilottaa ohjeen suodattimelta, mutta vasta salliva agentin suoritusympäristö voi muuttaa piilotetun ohjeen tietovarkaudeksi.