vCenter sotto attacco, LiteLLM avvelenato e SAP espone una RCE critica

🛡️ Executive Summary

• CVE-2026-59310 in VMware vCenter viene sfruttata pochi giorni dopo la disclosure per installare reverse_ssh e mantenere accesso persistente ai server.
• Le release LiteLLM 1.82.7 e 1.82.8 compromesse hanno sottratto credenziali cloud, SSH, Kubernetes e database dopo la campagna TeamPCP contro Trivy.
• SAP corregge CVE-2026-58231, falla CVSS 10.0 in Commerce Cloud capace di portare un attaccante non autenticato all’esecuzione arbitraria di codice.

Tre sviluppi contemporanei mostrano quanto rapidamente una compromissione possa attraversare infrastrutture enterprise, pipeline software e applicazioni cloud. VMware vCenter è già sotto attacco attraverso CVE-2026-59310, vulnerabilità critica corretta da Broadcom a fine luglio e ora associata a compromissioni reali con persistenza tramite reverse SSH. Parallelamente emergono nuovi dettagli sull’incidente LiteLLM, nel quale due release PyPI malevole hanno sottratto segreti da ambienti di sviluppo e cloud dopo la compromissione della supply chain Trivy attribuita a TeamPCP. SAP chiude infine CVE-2026-58231, falla con punteggio CVSS 10.0 in Commerce Cloud che può consentire a un utente non autenticato di arrivare all’esecuzione arbitraria di codice.

CVE-2026-59310 passa dalla disclosure allo sfruttamento reale

Broadcom aveva corretto CVE-2026-59310 il 29 luglio all’interno dell’advisory VMSA-2026-0006. La vulnerabilità è una directory traversal nel Syslog server di VMware vCenter, valutata Critical con punteggio CVSS 9.8, attraverso la quale un attaccante con accesso di rete al servizio può arrivare all’esecuzione arbitraria di codice. Lo stesso aggiornamento aveva chiuso anche CVE-2026-59309, authentication bypass nel VMware Directory Service anch’essa valutata 9.8. Nell’advisory ufficiale Broadcom il vendor raccomanda l’aggiornamento delle installazioni interessate e non indica workaround equivalenti alla patch. Matrice Digitale aveva già analizzato le due falle pre-auth di vCenter al momento della pubblicazione delle correzioni.

Gli attaccanti installano reverse_ssh per mantenere la persistenza

La situazione cambia ora perché CVE-2026-59310 non è più soltanto una vulnerabilità teoricamente sfruttabile. Un’indagine incident response di QUIRSO ha rilevato attività di path traversal compatibili con la falla seguite dall’installazione di un cron job malevolo che avvia reverse_ssh, progetto open source capace di creare connessioni SSH inverse verso infrastrutture controllate dall’attaccante. Le prime comunicazioni dei sistemi compromessi con i domini ostili risalgono al 3 agosto, appena cinque giorni dopo la disclosure Broadcom.

La telemetria ricostruita dai ricercatori individua fino a 361 indirizzi IP unici distribuiti in 47 Paesi, con concentrazioni in Germania, Stati Uniti, Turchia, Iran e Francia. QUIRSO considera la propria evidenza compatibile con una compromissione riuscita attraverso CVE-2026-59310, ma non attribuisce con certezza la campagna a uno specifico gruppo.

Reverse SSH aggira il problema delle connessioni in ingresso

L’impiego di reverse_ssh è particolarmente efficace su un’appliance come vCenter perché inverte il normale modello di connessione. È il server compromesso ad aprire una sessione verso l’infrastruttura dell’operatore, riducendo l’utilità delle regole che bloccano accessi amministrativi in ingresso. La semplice presenza dello strumento non costituisce però un indicatore sufficiente di compromissione, perché il progetto può avere usi legittimi; acquista valore quando compare senza autorizzazione su un vCenter vulnerabile, insieme a cron job inattesi e connessioni outbound sconosciute. Nello stesso periodo sono stati osservati anche aumenti delle scansioni verso vCenter compatibili con la ricerca di CVE-2026-59309, ma al momento non esistono elementi sufficienti per collegare quelle attività alla stessa infrastruttura che sfrutta CVE-2026-59310. La distinzione è importante: scansione, tentativo di exploit e compromissione confermata rappresentano tre livelli differenti di evidenza.

LiteLLM riporta alla supply chain compromessa di Trivy

Il secondo filone risale alla campagna TeamPCP di marzo ma assume ora una dimensione più chiara. Le versioni LiteLLM 1.82.7 e 1.82.8 pubblicate su PyPI il 24 marzo erano malevole e sono rimaste disponibili per circa 40 minuti, dalle 10:39 UTC, prima della quarantena. LiteLLM ha collegato l’incidente alla compromissione della dipendenza Trivy utilizzata nel proprio workflow di sicurezza CI/CD. L’incident report ufficiale LiteLLM identifica esplicitamente le due release compromesse e invita a considerare sospette le installazioni avvenute nella relativa finestra temporale. La campagna era già stata ricostruita da Matrice Digitale quando TeamPCP aveva avvelenato Trivy e le GitHub Actions di Checkmarx.

Il file .pth esegue il malware prima ancora dell’import di LiteLLM

La caratteristica più pericolosa della release 1.82.8 era la presenza di litellm_init.pth. I file .pth possono essere elaborati automaticamente dall’interprete Python durante l’avvio dell’ambiente, per cui il codice malevolo poteva eseguirsi senza che un’applicazione importasse esplicitamente LiteLLM. Il payload cercava variabili d’ambiente, chiavi SSH, credenziali dei provider cloud, token Kubernetes, password dei database e chiavi API dei servizi AI, comprese quelle associate a OpenAI e Anthropic. I dati venivano quindi esfiltrati verso un dominio controllato dagli attaccanti che imitava il nome del progetto. Questa modalità amplia il perimetro di indagine: non basta stabilire se un’applicazione usasse LiteLLM direttamente, perché una dipendenza transitiva non bloccata su una versione precisa poteva introdurre il pacchetto nell’ambiente.

TeamPCP trasforma gli strumenti di sicurezza in punti di raccolta dei segreti

Unit 42 colloca LiteLLM dentro una campagna più ampia nella quale TeamPCP ha compromesso deliberatamente strumenti di sicurezza e sviluppo che operano in ambienti ad alto privilegio. Trivy, KICS, LiteLLM e altri componenti vengono eseguiti frequentemente nelle pipeline CI/CD e possono quindi vedere token GitHub, credenziali cloud, chiavi SSH e segreti Kubernetes che non sarebbero disponibili a un normale pacchetto applicativo. L’analisi di Unit 42 sulla campagna TeamPCP descrive la strategia come una sequenza di compromissioni capace di utilizzare le credenziali sottratte a una vittima per raggiungere il progetto successivo. Matrice Digitale aveva successivamente ricostruito anche la compromissione del pacchetto PyPI Telnyx da parte dello stesso ecosistema.

Le credenziali rubate restano pericolose mesi dopo la rimozione del pacchetto

La rimozione delle versioni LiteLLM malevole da PyPI ha chiuso il vettore di distribuzione, ma non revoca automaticamente i segreti copiati durante la finestra di compromissione. Una chiave AWS statica, un token GitHub, una chiave SSH o una password database possono continuare a funzionare mesi dopo se l’organizzazione si limita ad aggiornare il pacchetto. Proprio per questo il remediation path deve includere la ricerca delle versioni 1.82.7 e 1.82.8, l’identificazione dei sistemi sui quali sono state eseguite e la rotazione di tutte le credenziali accessibili da quegli ambienti. Unit 42 raccomanda inoltre di fissare dipendenze e GitHub Actions a versioni precise e conosciute, riducendo la possibilità che un tag o una release appena pubblicata venga assorbita automaticamente nelle pipeline.

I nuovi numeri sull’impatto non equivalgono a vittime confermate

Le analisi più recenti basate su materiale sottratto durante la campagna parlano di centinaia di migliaia di file catturati e di migliaia di organizzazioni potenzialmente riconducibili agli ambienti dai quali provenivano i segreti. Questi valori non devono però essere trasformati automaticamente in un conteggio di breach confermati. L’associazione si basa su indicatori come hostname, domini dei committer e namespace dei repository e può indicare che dati appartenenti a un determinato ambiente sono stati raccolti, ma non dimostra da sola che le credenziali rubate siano state successivamente utilizzate per compromettere l’organizzazione. La portata reale della campagna resta comunque significativa: l’ecosistema TeamPCP è stato collegato da Unit 42 a compromissioni successive e Matrice Digitale ha documentato come la sua attività sia evoluta ben oltre le prime intrusioni cloud.

SAP Commerce Cloud corregge una RCE con punteggio massimo

Il terzo sviluppo riguarda CVE-2026-58231, vulnerabilità in SAP Commerce Cloud Data Hub Adapter valutata CVSS 10.0. La falla deriva da controlli insufficienti sull’autorizzazione e sulla validazione degli input. Un attaccante non autenticato può abusare di un client di autenticazione predefinito e inviare input costruiti appositamente a determinate funzioni, arrivando potenzialmente all’esecuzione arbitraria di codice e alla compromissione dei componenti interni dell’applicazione. SAP ha distribuito la correzione all’interno del proprio Security Patch Day di agosto 2026, che comprende numerose altre vulnerabilità High e Critical nell’ecosistema enterprise.

L’assenza di autenticazione rende urgente il redeploy

L’elemento più critico di CVE-2026-58231 è l’assenza del requisito di autenticazione. Un endpoint Commerce Cloud raggiungibile dall’attaccante può quindi essere preso di mira senza che siano prima necessarie credenziali rubate o un account con privilegi elevati. La remediation richiede l’aggiornamento a una versione corretta e il redeploy dell’istanza SAP Commerce Cloud. Fino alla possibilità di applicare la patch, l’esposizione può essere ridotta restringendo tramite IP Filter Set l’accesso all’endpoint vulnerabile, ma la misura temporanea non sostituisce l’aggiornamento. Il Patch Day di agosto comprende anche CVE-2026-44772 in SAP Manufacturing Integration and Intelligence, valutata 9.9, e CVE-2026-34265 in NetWeaver e ABAP Platform, valutata 9.8, mostrando una superficie enterprise che richiede un ciclo di remediation più ampio della sola Commerce Cloud.

Tre incidenti mostrano perché il perimetro enterprise non coincide più con Internet

VMware, LiteLLM e SAP rappresentano superfici differenti ma espongono lo stesso problema operativo. vCenter dimostra che pochi giorni tra disclosure e patch possono essere sufficienti per trasformare un management server in un punto di persistenza; LiteLLM mostra che il codice malevolo può raggiungere un ambiente senza attaccarne direttamente il perimetro, entrando attraverso uno strumento considerato affidabile; SAP Commerce Cloud ricorda infine che una singola falla pre-authentication in un’applicazione enterprise può offrire un percorso diretto alla code execution.

La risposta deve quindi combinare aggiornamento rapido dei sistemi esposti, controllo delle dipendenze e soprattutto rotazione dei segreti quando una supply chain viene compromessa. Aggiornare il software chiude il vettore originario; non elimina automaticamente reverse shell, cron job, token cloud o credenziali che l’attaccante può aver già trasformato in nuovi punti d’accesso.