TL;DR: se una dipendenza AI ha eseguito codice malevolo nella tua pipeline, aggiornare il pacchetto non chiude l’incidente. Devi identificare l’ambiente esposto, revocare i secret accessibili e generarne di nuovi solo dopo la bonifica.

Il problema: il pacchetto passa, i secret restano validi

Il 24 marzo 2026 due versioni di LiteLLM pubblicate su PyPI, la 1.82.7 e la 1.82.8, contenevano codice non autorizzato capace di cercare credenziali SSH, cloud e configurazioni Kubernetes. Il progetto ha rimosso le release compromesse. Una nuova analisi di CloudSEK, ripresa il 12 agosto da Ars Technica, sostiene che l’esposizione abbia coinvolto migliaia di organizzazioni e centinaia di migliaia di pipeline CI/CD.

Il punto utile per una PMI non è il nome del pacchetto. È il modello dell’incidente: un tool apparentemente legittimo gira nello stesso ambiente in cui hai messo password WordPress, chiavi API, accessi SFTP e token di deploy. Quando quel tool viene compromesso, tutti i secret leggibili vanno considerati esposti.

La soluzione: revoca prima, sostituisci dopo

Parti dall’inventario dell’ambiente, non dalla dashboard del singolo servizio. La versione installata oggi non basta: dopo un upgrade può essere pulita mentre una build precedente ha già eseguito il pacchetto compromesso. Controlla quindi anche la cronologia dei lockfile, la SBOM, i log CI e gli artifact delle build del 24 marzo:

python -m pip show litellm
python -m pip freeze | grep '^litellm=='
git log -S 'litellm==1.82.' -- requirements.txt uv.lock poetry.lock

Se trovi una versione coinvolta, sospendi i deploy da quel runner e procedi in questo ordine:

  1. elenca i secret che il processo poteva leggere: file .env, variabili CI, chiavi SSH, token GitHub, credenziali hosting, Application Password di WordPress e chiavi dei provider AI;
  2. revoca le credenziali esistenti dal servizio che le ha emesse. Cancellarle dal server o riscrivere il file .env non le invalida;
  3. bonifica o ricrea il runner, aggiorna le dipendenze e solo dopo genera credenziali nuove con permessi minimi;
  4. controlla i log di accesso, le modifiche ai repository e i deploy avvenuti dalla prima possibile esposizione.

Per le automazioni WordPress vale la stessa regola: usa una Application Password dedicata per ogni integrazione, non la password principale dell’utente. Se devi revocarla, interrompi un solo flusso e sai subito quale componente va aggiornato. E se stai costruendo workflow agentici, applica gli stessi confini di sicurezza tra agente e infrastruttura.

L’errore da evitare

L’errore classico è fare upgrade, vedere la versione corretta e dichiarare chiuso l’incidente. Un token copiato fuori dal sistema continua a funzionare finché non viene revocato o scade. La pulizia del codice e la rotazione delle credenziali sono due lavori distinti.

La take finale

Un secret senza proprietario, scadenza, ambito e procedura di revoca è debito operativo. Non aspettare il prossimo attacco alla supply chain: assegna questi quattro dati alle credenziali che tengono online sito, deploy e automazioni. Quando serve reagire, la differenza tra un’ora e due giorni sta tutta nell’inventario.

Fonti