Lo stato salvato di un agente fa parte del suo confine di sicurezza. L'11 giugno, Check Point Research ha mostrato una catena in cui un filtro di cronologia esposto poteva alterare una query, aggiungere un falso risultato di checkpoint e innescare l'esecuzione di codice durante il caricamento. È una dimostrazione dei ricercatori, non la notizia di una violazione di tutte le installazioni LangGraph.
Un checkpointer salva lo stato di esecuzione dell'agente per riprendere un flusso di lavoro o esaminare i passaggi precedenti. Nell'implementazione SQLite interessata, una chiave del filtro sui metadati poteva essere inserita in una query senza una validazione adeguata. Una seconda vulnerabilità permetteva a dati di checkpoint appositamente costruiti di ricreare oggetti Python non sicuri durante il caricamento. Check Point ha concatenato i due percorsi nella propria dimostrazione, ottenendo l'esecuzione di codice nel processo dell'applicazione.
Chi doveva preoccuparsi?
La condizione decisiva è l'esposizione. La catena dimostrata riguardava applicazioni personalizzate e self-hosted che usavano il checkpointer interessato e passavano a una ricerca nella cronologia un filtro non attendibile, per esempio tramite `get_state_history()`. L'avviso del manutentore di LangGraph dice che i clienti di LangSmith Deployment non erano colpiti dalla vulnerabilità del filtro SQLite, perché quel percorso non era disponibile. L'avviso separato sulla deserializzazione descrive un rischio successivo a una compromissione quando un aggressore può controllare i byte dei checkpoint.
Le correzioni erano disponibili prima dell'analisi di giugno: `langgraph-checkpoint-sqlite` 3.0.1 risolve l'iniezione nel filtro e `langgraph` 1.0.10 corregge il caricamento non sicuro dei checkpoint msgpack. Verificate pacchetti e versioni di ogni installazione. La sola versione non dice se la vostra applicazione esponeva il percorso vulnerabile; la ricerca pubblica non documenta uno sfruttamento diffuso.
Che cosa dovrebbe coprire la revisione?
- Step 01Individuate dove ogni agente salva i checkpoint e quali servizi o utenti possono leggerli, scriverli o consultarli.
- Step 02Cercate endpoint di cronologia che accettano chiavi di filtro da utenti o altre fonti non attendibili. Validate l'input e applicate le versioni corrette dal manutentore.
- Step 03Verificate se l'accesso all'archivio dei checkpoint può raggiungere lo stato di un altro utente o il processo dell'agente. Limitate permessi del database e privilegi del runtime; conservate registri utili alle indagini.
HikmaAI può aiutare a valutare le interazioni supportate degli agenti, applicare controlli sui percorsi protetti e conservare evidenza delle decisioni. Una lettura interna dei checkpoint da parte del framework potrebbe non attraversare quel percorso. Occorre verificarne direttamente la versione, la validazione degli input e i permessi di archiviazione.
La lezione per chi acquista è concreta: esaminate l'archivio dello stato con la stessa attenzione dedicata agli strumenti dell'agente. Memoria e cronologia sono utili, ma creano anche input e permessi che un aggressore può tentare di raggiungere.
