TeamCity, WordPress, GitLab ed Elsevier: quattro attacchi colpiscono la fiducia digitale

🛡️ Executive Summary

• CVE-2026-63077 in TeamCity passa dallo sfruttamento attivo alle campagne ransomware, mettendo direttamente a rischio credenziali, build e pipeline CI/CD.
• WordPress CVE-2026-87902 viene sfruttata poche ore dopo la disclosure, mentre GitLab mostra come un indirizzo email segreto possa funzionare da credenziale.
• Elsevier conferma un redirect temporaneo verso una pagina associata a LAPSUS$, senza evidenze di compromissione dei dati o dei sistemi core.

Quattro incidenti differenti mostrano la stessa debolezza strutturale: gli attaccanti non devono necessariamente violare il perimetro più protetto quando possono sfruttare componenti già considerati affidabili. TeamCity controlla build e pipeline, WordPress esegue PHP sul server, GitLab permette di trasformare email in azioni sui repository ed Elsevier distribuisce contenuti attraverso piattaforme utilizzate da studenti e ricercatori. Nelle ultime ore questi quattro livelli sono finiti sotto pressione: una falla TeamCity viene associata al ransomware, WordPress subisce exploitation quasi immediata, un token GitLab può trasformarsi in capacità di commit e CI/CD, mentre Elsevier conferma un redirect malevolo rivendicato con il nome LAPSUS$.

TeamCity passa dallo sfruttamento attivo al ransomware

CVE-2026-63077 era già una vulnerabilità critica per definizione operativa. JetBrains aveva spiegato nel proprio advisory su TeamCity che un attaccante non autenticato con accesso HTTP(S) può abusare del protocollo di polling degli agenti, superare i controlli di autenticazione ed eseguire comandi arbitrari con i privilegi del processo TeamCity. Sono vulnerabili le installazioni On-Premises precedenti alle versioni 2025.11.7 e 2026.1.3, mentre per i rami più vecchi è disponibile un security patch plugin. Il salto di rischio è arrivato dopo. JetBrains ha successivamente confermato exploitation e tentativi di exploitation contro server rimasti senza patch, indicando nei log ConversionException, agenti non autorizzati con nomi che iniziano per scan e altre tracce utili all’indagine. Ora BleepingComputer segnala che CISA ha aggiornato il catalogo KEV indicando l’impiego della vulnerabilità anche in campagne ransomware. Non è un’evoluzione marginale. Un server TeamCity può custodire credenziali, configurazioni, segreti e accesso ai processi di build, quindi la compromissione può superare il singolo host e contaminare artefatti e pipeline downstream. Il rischio era già diventato concreto con la compromissione del servizio Cadence di JetBrains attraverso un TeamCity rimasto vulnerabile, dopo che CVE-2026-63077 era entrata nel KEV.

Leggi anche: JetBrains Cadence violato via TeamCity, credenziali AWS e codice sorgente a rischio

WordPress CVE-2026-87902 viene sfruttata poche ore dopo la patch

La finestra di esposizione è stata ancora più compressa per CVE-2026-87902. WordPress ha pubblicato il security release 7.1.2 il 22 settembre, spiegando che un attaccante non autenticato può, in determinate condizioni, manipolare la risoluzione dei page template e includere un file PHP locale leggibile fuori dalle directory del tema. Se coincidono specifici prerequisiti del tema e del server, la Local File Inclusion può arrivare alla remote code execution. A distanza di poche ore dalla disclosure sono comparsi tentativi di exploitation reali. Previdian avrebbe registrato richieste dirette verso /usr/local/lib/php/pearcmd.php, seguite dalla scrittura di file PHP sotto /tmp e /var/tmp; Patchstack avrebbe osservato la stessa evoluzione dalla semplice ricognizione alla scrittura effettiva di payload. Il punto importante è che non tutte le installazioni vulnerabili sono automaticamente compromettibili: servono un tema con una directory top-level il cui nome inizi con page- e un file PHP locale utilizzabile dall’attaccante. La presenza di queste precondizioni riduce la platea effettivamente esposta alla RCE, ma non giustifica il rinvio della patch. Matrice Digitale aveva già analizzato CVE-2026-87902 al momento della disclosure; l’elemento nuovo è che la fase teorica è durata sostanzialmente poche ore.

Un indirizzo GitLab segreto può diventare una credenziale CI/CD

Nel caso GitLab non c’è invece una CVE classica. Il problema nasce da una funzionalità legittima: ogni utente dispone di un incoming email token incorporato negli indirizzi personali utilizzati per creare issue e merge request via email. La documentazione ufficiale GitLab è esplicita: il token non scade e chiunque lo possieda può creare issue e merge request impersonando il proprietario. La ricerca riportata da The Hacker News e attribuita ad Aikido Security mostra però un impatto più ampio. Lo stesso token sarebbe condiviso tra gli indirizzi generati per progetti diversi e, modificando l’indirizzo da -issue a -merge-request, chi ne entra in possesso può inviare una patch, farla applicare a una branch sulla quale l’utente dispone dei permessi e, in determinate condizioni, modificare .gitlab-ci.yml fino a eseguire job CI/CD con l’identità e i privilegi della vittima. Il token non supera i privilegi dell’account compromesso: quello di un Guest ha capacità molto diverse da quello appartenente a un Maintainer. Il problema è però concettuale. Un indirizzo apparentemente destinato a ricevere segnalazioni deve essere trattato come un segreto perché incorpora una capacità di autenticazione. GitLab permette di rigenerarlo, ma non scade automaticamente. In un ecosistema nel quale GitLab è già stato recentemente coinvolto in vulnerabilità critiche e inserimenti nel KEV, la protezione dei token associati alla supply chain diventa importante quanto quella delle password.

Elsevier conferma il redirect ma non un data breach

Il quarto episodio richiede maggiore cautela perché un redirect verso un sito criminale non equivale automaticamente alla compromissione dei database. Elsevier ha confermato a The Register che il 21 settembre alcuni visitatori di piattaforme selezionate sono stati temporaneamente reindirizzati verso una pagina di terze parti associata a LAPSUS$. La società sostiene di avere ripristinato rapidamente il servizio e afferma che l’indagine non indica compromissioni di core platform, dati dei clienti, contenuti scientifici o sistemi operativi. Mancano invece dettagli pubblici sul meccanismo utilizzato per alterare il traffico e sulla precisa superficie compromessa. Questa distinzione è essenziale. Mostrare la pagina di un gruppo criminale dimostra almeno una capacità di alterare il percorso seguito dagli utenti, ma non prova da sola l’accesso ai repository di ScienceDirect, ai dati di ClinicalKey o alle infrastrutture centrali di Elsevier. È la stessa cautela applicata alle rivendicazioni underground: un leak site o un defacement non costituiscono automaticamente prova di un data breach.

Continua con:

• GitLab CVSS 10, attacchi su Artifactory, PaperCut e Cisco FMC
• Acronis sotto exploit e WordPress backdoor: plugin fidati diventano il punto d’ingresso

Il bersaglio comune è la capacità concessa ai sistemi fidati

TeamCity, WordPress, GitLab ed Elsevier non condividono una tecnologia, ma condividono un elemento molto più interessante: l’attaccante cerca di appropriarsi di una capacità che il sistema considera legittima. TeamCity può impartire comandi e costruire software; WordPress può includere ed eseguire PHP; GitLab può trasformare un messaggio in una modifica al repository; una piattaforma editoriale può indirizzare migliaia di utenti verso contenuti fidati. È qui che la superficie di attacco si sposta dalla semplice vulnerabilità al trust boundary. Nel caso TeamCity il risultato può raggiungere build e supply chain; con WordPress una primitiva di inclusione locale può diventare RCE; su GitLab un token nascosto dentro un indirizzo email può acquisire il peso operativo di una credenziale; nel caso Elsevier basta il controllo del redirect per colpire direttamente la fiducia dell’utente, anche senza dimostrare accesso ai dati. Il denominatore comune non è quindi il CVSS. È il privilegio implicito nei sistemi intermedi. Più una piattaforma è autorizzata a distribuire codice, eseguire workflow, pubblicare contenuti o instradare utenti, maggiore diventa il valore di qualsiasi debolezza capace di trasformare quella fiducia in esecuzione, persistenza o impersonificazione.