V AgentCore CLI šlo podstrčit kód do generovaného agenta. Oprava ho neodstraní

Nástroj @aws/agentcore je příkazová řádka, kterou se v Amazon Bedrock AgentCore zakládají, ladí a nasazují agenti. Umí mimo jiné převzít agenta hotového v Bedrock Agents a přeložit ho do místního projektu v Pythonu. Právě v tomhle překladu byla chyba, kterou AWS 8. června vydal jako bulletin 2026-040 a jako CVE-2026-11393.

Známku 9,0 z deseti podle metodiky CVSS 3.1 si přidělil sám AWS, který si čísla CVE pro svoje produkty vydává. Americká národní databáze NVD měla záznam 1. srpna pořád ve stavu čekání na vlastní rozbor, takže druhé hodnocení k dispozici není.

Popis, ze kterého se stal program

Když se importuje řídicí agent, který má pod sebou další, stáhne si nástroj z rozhraní Bedrocku i údaje o nich. Mezi nimi je pole collaborationInstruction – volný text popisující, k čemu je ten který pomocník dobrý. Ten popis se pak vypíše do dokumentačního řetězce ve vygenerovaném souboru main.py, tedy do řetězce ohraničeného třemi uvozovkami.

Takový řetězec v Pythonu končí přesně tam, kde se ty tři uvozovky objeví podruhé. Cizí text v něm proto musí projít ošetřením: každá trojice se zneškodní zpětnými lomítky. Nástroj ošetření dělal, jen nesprávnou funkcí.

V souboru base-translator.ts stojí vedle sebe dvě pomocné funkce. Jedna připravuje text pro řetězec v jednoduchých uvozovkách a hlídá zpětné lomítko, apostrof a konec řádku. Druhá připravuje text pro řetězec trojitý a hlídá zpětné lomítko a trojici uvozovek. Na popis spolupracujícího agenta se pouštěla ta první, která uvozovku nehledá vůbec. Co v popisu následovalo za trojicí uvozovek, tedy vygenerovaný soubor nečetl jako text, ale jako program.

Kdo to mohl použít

Předpoklad je úzký a bulletin ho popisuje přesně. Útočník musí být přihlášený uživatel ve stejném účtu AWS a mít oprávnění bedrock:AssociateAgentCollaborator. Tím připojí k řídicímu agentovi pomocníka s připraveným popisem – a pak čeká, až si toho řídicího agenta někdo jiný naimportuje.

Vložený kód se pak spustí na dvou různých místech. Na počítači vývojáře, když spustí agentcore dev: tam běží pod jeho vlastními přístupovými údaji k AWS. A v běhovém prostředí AgentCore Runtime poté, co vývojář agenta nasadí a zavolá: tam běží pod rolí, kterou má agent přidělenou. Díra otevřená do internetu to tedy není. Je to cesta, jak se uvnitř jednoho účtu dostat z práva spravovat agenty k oprávněním někoho jiného.

Podstrčený text se u agentů obvykle řeší za běhu – ať už jde o skrytý pokyn, nebo o podvržený údaj, který agent bere jako danost. Tady jde o něco jiného: text se do agenta zapíše natrvalo ještě dřív, než poprvé nastartuje.

Oprava je jeden řádek

Návrh změny číslo 1329 se otevřel a začlenil za hodinu a půl večer 20. května světového času. Sáhl na tři soubory, přidal 126 řádků a jeden ubral; v samotném překladači je z toho jediný změněný řádek a zbytek jsou testy. Změna spočívá v tom, že se místo funkce pro jednoduché uvozovky zavolá ta pro trojité.

Ta funkce přitom nebyla nová. Ve verzi 0.14.1, tedy poslední zranitelné, je v témž souboru a volá se na třech dalších místech – u převzatých systémových zadání i u popisů funkcí z akčních skupin. Cizí text se tedy do trojitě uvozeného řetězce lepil na čtyřech místech a špatnou funkci dostalo jediné z nich.

Povýšení nástroje samo nestačí

Tohle je na celé věci nejméně obvyklé a AWS to píše natvrdo: aktualizace nástroje sama neopraví kód, který se už vygeneroval nebo nasadil. Chyba je v generátoru, ale škoda je v jeho výstupu – v souboru main.py, který leží ve vývojářově projektu a jehož kopie běží v AWS.

Bulletin proto vypisuje kroky čtyři, ne jeden: povýšit nástroj na 0.14.2 (u předběžné řady na 1.0.0-preview.9), odebrat dotčeného agenta z projektu, spustit import znovu opraveným nástrojem a nasadit ho, aby se v AWS přepsal starší otisk. Kdo to neudělá, má podle hlášení vložený kód v chodu při každém zavolání agenta. Náhradní řešení pro toho, kdo povýšit nemůže, je ruční: projít vygenerovaný main.py, najít v popisech spolupracovníků trojice uvozovek a přepsat je na ošetřený tvar.

Časová osa jde poskládat z veřejných zdrojů

Verze 0.14.1 vyšla na npm 19. května, oprava se začlenila 20. května a verze 0.14.2 byla venku 21. května. Bulletin i hlášení v repozitáři vyšly 8. června, tedy o osmnáct dní později, a týž týden chybu vypsala i týdenní zpráva CISA.

Jeden údaj se rozchází. Hlášení v repozitáři projektu nese 8. červen, ale záznam v globální databázi bezpečnostních hlášení GitHubu je datovaný 29. červencem a týmž dnem je označené i jeho ověření ze strany GitHubu. Proč mezi tím leží sedm týdnů, ani jedna z těch stránek neuvádí.

Do katalogu zneužívaných zranitelností CISA se CVE-2026-11393 nedostalo. Ten katalog měl 29. července 1 656 položek a z nástrojů pro agenty je v něm Langflow. Model EPSS, který odhaduje pravděpodobnost pokusu o zneužití v následujících třiceti dnech, u něj podle údaje připojeného k hlášení na GitHubu vychází na 0,3 %.

Co si z toho odnést

Přesah za jeden nástroj jedné firmy je v tom, jak vzniká kód agenta. Generátory berou texty z cizích rozhraní a vypisují je do zdrojových souborů; jakmile to jednou udělají špatně, nese chybu výstup, ne generátor. Aktualizace pak spraví budoucnost a minulost nechá být. U agentů to bolí o to víc, že se ten výstup obvykle rovnou nasazuje – vygenerovaný soubor je meziprodukt, do kterého se po vydání nikdo nedívá.

Podle nás je nejcennější částí bulletinu ta nudná: seznam čtyř kroků. Hlášení, které by skončilo u pokynu povýšit na 0.14.2, by tady čtenáře nechalo v přesvědčení, že má hotovo.

Zdroje: bulletin AWS 2026-040 z 8. června 2026, hlášení GHSA-m4x6-gwgp-4pm7, záznam CVE-2026-11393 v NVD, týdenní přehled CISA za týden od 8. června 2026, repozitář aws/agentcore-cli a balíček @aws/agentcore na npm, odkud pocházejí data vydání jednotlivých verzí.