Vad hände
Cloud Security Alliance publicerade en forskningsanteckning den 6 augusti 2026 som beskrev CoreBreak, en uppsättning av fyra CVE:er över AWS, Google och Vercel-agentramverk där verktygsutskickningsskiktet exekverade ett verktygsanrop utan att verifiera att en språkmodell faktiskt hade producerat det. Alla fyra har leverantörsfixar.
Cloud Security Alliances AI Safety Initiative publicerade en forskningsanteckning den 6 augusti 2026 som beskriver ett plattformsoberoende sårbarhetsmönster som forskarna kallade CoreBreak. Enligt anteckningen presenterade säkerhetsforskarna Hedi Ingber och Aviyam Ivgi, medgrundare av säkerhetsföretaget Stealth, rön på Black Hat USA 2026 som visar att verktygsexekveringsskikten för Amazon Bedrock AgentCore, Googles Agent Development Kit (ADK) för Python, och harnessAI-paketen kunde distribueras med SDK-paketen till vart och ett av Vercel-paketen. ett verktyg utan att en legitim modellvändning någonsin inträffat. Eftersom språkmodellen aldrig åberopades, hävdar anteckningen, hade skyddsräcken byggda runt modellen inget beslut att ingripa i.
Agentramar av detta slag delar en gemensam struktur. Ett orkestreringslager samlar användarförfrågan, systemuppmaning, konversationshistorik och en katalog över tillgängliga verktyg, skickar den till en språkmodell och väntar på att modellen ska returnera en strukturerad instruktion som namnger ett verktyg och dess argument. SDK:n skickar sedan motsvarande funktion, skript eller API-anrop och matar tillbaka resultatet till konversationen. CoreBreak riktar in sig på det sista steget: enligt anteckningen behandlade sändningslogiken i var och en av de tre produkterna data som bara liknade ett modellgenererat verktygsanrop som auktoritativt, utan att kontrollera var det kom ifrån.
Anteckningen listar fyra CVE-identifierare med distinkta exploateringsvägar, med hänvisning till leverantörsbulletiner och National Vulnerability Database-poster. AWS tilldelade CVE-2026-18830 (CVSS v4.0 8.6, hög) till Bedrock AgentCore-ledningsfelet, där en autentiserad fjärranropare kunde placera ett innehållsblock för verktygsanvändning direkt i det slutliga meddelandet av en InvokeHarness API-förfrågan. Google tilldelade CVE-2026-18236 (9.3, Kritisk) till ett ADK-fel där en angripare som kunde injicera händelser i sessionshistoriken kunde förfalska en bekräftelse på mänskligt godkännande, eftersom bekräftelseprocessorn inte kontrollerade att målverktyget tillhörde den verkställande agenten, att det faktiskt stämde överens med det ursprungliga namnet och anropet. Vercels @ai-sdk/harness-codex och @ai-sdk/harness-opencode fick CVE-2026-64650 och CVE-2026-64651 (6.3, Medium vardera), där skadlig kod som redan kördes inuti en Linux-sandlåda kunde uppfylla en process-sökvägskontroll som litade på alla processer vars sökväg till en godkänd kommandorad innehöll kommandoraden.
Det finns korrigeringar, men belastningen varierar beroende på implementeringsmodell. Anteckningen säger att AWS fixar till det fullt hanterade Bedrock AgentCore InvokeHarness API:et som distribuerades automatiskt före 31 juli 2026 och inte krävde någon kundåtgärd, även om det fortfarande råder att bekräfta täckning för en given region och konfiguration. Googles korrigering skickades i ADK för Python version 2.5.0 den 16 juli 2026, och Vercels korrigeringar skickade i harness-codex 1.0.29 och harness-opencode 1.0.28 den 10 juli 2026 – värdpaketoperatörer måste tillämpa själva paketuppdateringar. Anteckningen ramar in CoreBreak till skillnad från prompt injektion: prompt injektion försöker manipulera modellens omdöme, medan CoreBreak går förbi frågan om modellen utövade omdöme överhuvudtaget.
Källinformation: labs.cloudsecurityalliance.org ↗
Varför det spelar roll
Innehållsfilter, systemuppmaningar, vägransutbildning och mänskliga godkännandeportar förutsätter att modellen är den part som bestämmer om ett verktyg körs. Om leveranslagret accepterar något som formats som en modells verktygsanrop, förbigås dessa kontroller snarare än besegras - och loggar som övervakningsteam normalt inspekterar skapas aldrig.
De flesta företagskontroller för agent AI sitter på eller runt modellen. Systemuppmaningar begränsar känsliga åtgärder, innehållsfiltrerar poäng för ingångar och utdata, vägransutbildning är inbakad i modellvikter, och mänskliga bekräftelsesteg ger högriskverktyg. Var och en av dessa kontroller förutsätter att modellen är den part som bestämmer om ett verktyg körs. Om ett sändningslager kommer att utföra någon nyttolast som är korrekt formad, ger dessa investeringar lite förebyggande skydd - inte för att de var dåligt utformade, utan för att attackerna går runt platsen där de verkar. Det är en annan klass av problem än ett skyddsräcke som kan argumenteras förbi.
De specifika egenskaperna bakom dessa leveranslager är det som ger fyndet vikt. Noteringen säger att Vercel-bristerna kan nå värdexponerade verktyg inklusive hemliga uppslagningar, driftsättningsoperationer och moln-API-anrop. Felet Google är ännu mer påpekat: det tillät förfalskade bekräftelser att nå verktyg som medvetet placerats bakom mänskligt godkännande, vilket är kontrollorganisationens reserv för åtgärder som anses vara alltför följdriktiga för att automatiseras. En bypass som specifikt neutraliserar steget människa-i-slingan undergräver den begränsning som många team citerar när de motiverar bredare agentautonomi.
Patchberättelsen illustrerar också en asymmetri som kommer att återkomma när agentverktygen sprider sig. Kunder av den fullt hanterade AWS-tjänsten åtgärdades utan att göra något. Team som kör Googles ADK eller Vercels selepaket i sina egna miljöer måste lägga märke till rådgivningen, uppdatera beroendet och omdistribuera - och beroendeuppdateringar i produktionsstackar släpar rutinmässigt med veckor eller månader. Samma underliggande designgap har därför ett mycket olika praktiskt exponeringsfönster beroende på om en organisation använder agentinfrastruktur som en tjänst eller säljer den till sin egen kodbas.
Det finns också ett detektionsgap. Anteckningen noterar att säkerhetsövervakning för agentsystem generellt har fokuserat på modellingångar och -utgångar – loggningsuppmaningar, flaggning av misstänkta slutföranden, granska vilka verktyg modellen valde. När ett verktyg körs utan att modellen körs, finns inga av dessa artefakter för att loggas. Flera viktiga saker är fortfarande okända: anteckningen rapporterar inga bevis för exploatering i det vilda, ger ingen uppskattning av hur många utplaceringar som påverkades och beskriver inte proof-of-concept-kod. CSA är uppriktigt om att två avslöjanden från fyra leverantörer inte bevisar ett branschomfattande mönster och att den observerade svårighetsgradienten är en datapunkt snarare än en poängregel.
Interaktiv mekanism: hur det faktiskt fungerar
Utforska den underliggande tekniken bakom denna utveckling interaktivt.
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
Vad du ska titta på härnäst
Huruvida egenvärdiga operatörer faktiskt tillämpar paketuppdateringarna Google och Vercel, om liknande härkomstluckor dyker upp i andra agentramverk, om någon in-the-wild exploatering rapporteras och om leverantörer går över till signerade, sessionsbundna auktoriseringstokens för verktygsexekvering.
Den mest konkreta frågan på kort sikt är patchuptake. AWS:s hanterade korrigering beskrivs som redan utplacerad, men ADK 2.5.0 och de två Vercel seleutgåvorna hjälper bara operatörer som installerar dem. Håll utkik efter nedströmssignaler – paketregistrets adoptionshastigheter, leverantörsgafflar som aldrig drar uppdateringen och interna plattformsbilder som fäster äldre versioner. Noteringen rekommenderar också en retrospektiv kontroll: granska loggar för verktygsanrop som inte kan kopplas till en motsvarande, välformad modellkomplettering i sessionsposten. Huruvida organisationer har telemetri på avsändningsskiktet för att köra den kontrollen är i sig självt olöst.
Den andra frågan är omfattning. CoreBreak täcker tre produkter, men det beskrivna mönstret – att lita på en nyttolasts form eller en process kommandorad som bevis på modellbehörighet – är inte specifikt för dem. Alla ramverk med samma SDK-till-modell-till-verktyg-struktur kan ha en jämförbar lucka. Håll utkik efter ytterligare råd från andra agenter som underhåller ramverket och om forskarna publicerar fullständigare tekniska detaljer efter Black Hat-presentationen. Ytterligare bekräftade fall skulle stärka CSA:s argument att detta är ett strukturellt mönster snarare än tre tillfälliga fel.
För det tredje, titta på det arkitektoniska svaret. CSA:s rekommendation är att kräva kryptografiskt bevis på att ett verktygsanrop härstammar från en verklig modellkomplettering – en signerad, sessionsbunden, engångstoken – snarare än att härleda auktorisering från meddelandestruktur eller processidentitet. Huruvida större leverantörer antar den modellen, och om det blir något köpare kan begära och verifiera under upphandlingen, kommer att avgöra om detta avslöjande ändrar design eller bara producerar patchar. Bekräftelsebearbetningslogik som validerar verktygsägande, bekräftelsekrav och argumentintegritet mot det ursprungliga inspelade samtalet är den smalare versionen av samma fix.
Slutligen, titta på styrning och hot-intelligens spår. CSA pekar på sitt MAESTRO-ramverk för hotmodellering och AI Controls Matrix v1.1 som platser där exekveringskontroll och privilegiehanteringsbedömningar nu uttryckligen bör täcka verktygsutskick, och kopplar CoreBreak till sin tidigare GuardFall-forskning om förbikopplingar av skyddsräcke på skalnivå. Också värt att övervaka: om NVD-posterna eller CVSS-resultaten revideras, om leverantörer publicerar detaljer efter incidenten utöver de första bulletinerna och om någon bekräftad exploatering dyker upp. Ingen av de fyra CVE:erna har för närvarande en offentlig rapport om övergrepp i naturen i det material som CSA citerar, och frånvaron av sådana rapporter är inte detsamma som frånvaro av aktivitet.