CubePilot, Check Point e Gitea espongono tre snodi critici

🛡️ Executive Summary

• Un hijacking DNS ha permesso agli aggressori di intercettare il traffico diretto ai servizi CubePilot usando certificati TLS validi.
• Il PoC di CVE-2026-16232 consente di ottenere una sessione SmartConsole con privilegi amministrativi sui server Check Point vulnerabili.
• Gitea 1.27.1 corregge una RCE che permette agli utenti con accesso in scrittura di trasformare una patch in un Git hook eseguibile.

CubePilot, Check Point e Gitea affrontano tre problemi distinti che colpiscono altrettanti snodi di fiducia delle infrastrutture digitali. CubePilot ha perso temporaneamente il controllo delle configurazioni DNS del proprio dominio, permettendo agli aggressori di intercettare traffico e credenziali attraverso certificati HTTPS validi. Rapid7 ha pubblicato un proof of concept per il bypass di autenticazione CVE-2026-16232, vulnerabilità già sfruttata contro i server di gestione Check Point. Gitea ha infine corretto CVE-2026-60004, una RCE che consente agli utenti autorizzati a scrivere in un repository di eseguire comandi con i privilegi del servizio.

Il DNS di CubePilot viene dirottato il 24 luglio

Il 24 luglio 2026 un aggressore ha ottenuto il controllo delle impostazioni DNS del dominio cubepilot.org, reindirizzando verso infrastrutture esterne il traffico destinato ai servizi dell’azienda australiana. CubePilot sviluppa controller di volo, sistemi di navigazione e componenti autopilota per droni impiegati in agricoltura, ispezioni, ricerca e soccorso, attività governative e difesa. Il controllo del DNS ha permesso all’operatore di modificare la destinazione associata ai sottodomini senza dover compromettere direttamente ciascun server applicativo. Il browser dell’utente continuava a richiedere un indirizzo appartenente a CubePilot, ma la risoluzione indirizzava la connessione verso sistemi gestiti dall’aggressore. L’incidente ha coinvolto servizi interni, portale, forum, documentazione e piattaforme destinate ai partner OEM, costringendo l’azienda a disattivare precauzionalmente diversi ambienti mentre proseguivano le verifiche. CubePilot ha dichiarato di avere ripreso il controllo del dominio nella stessa giornata, preservato le evidenze e segnalato l’accaduto all’Australian Cyber Security Centre e alle forze dell’ordine.

I certificati validi rendevano credibili i servizi falsi

L’aggressore non si è limitato a cambiare i record DNS, ma ha ottenuto certificati TLS validi per tutti i sottodomini di cubepilot.org. Gli utenti potevano quindi visualizzare una connessione HTTPS apparentemente regolare, senza gli avvisi normalmente associati a certificati scaduti, autofirmati o appartenenti a un dominio differente. CubePilot ritiene che le credenziali inserite nei propri servizi durante il 24 luglio possano essere state intercettate, comprese quelle utilizzate per il portale e il forum, e ha invitato gli utenti a modificare immediatamente le password riutilizzate su altri siti. L’incidente dimostra che il lucchetto del browser garantisce soltanto la cifratura della connessione verso il server indicato dal DNS, ma non prova che quell’infrastruttura sia ancora controllata dal titolare legittimo del dominio. Quando l’aggressore governa contemporaneamente risoluzione DNS e certificati, il traffico può essere terminato, letto e inoltrato senza generare un errore visibile. L’attacco colpisce quindi il livello di fiducia sul quale poggiano autenticazione, documentazione tecnica, distribuzione degli aggiornamenti e rapporti con i fornitori.

CubePilot verifica anche l’integrità dei firmware

L’azienda ha avvertito gli utenti di non installare immagini firmware scaricate il 24 e il 25 luglio finché non sarà completata la verifica della loro integrità. I firmware ottenuti prima del 24 luglio sono stati invece considerati sicuri sulla base delle informazioni disponibili. Non esiste al momento una conferma pubblica che gli aggressori abbiano effettivamente sostituito o modificato i file distribuiti, ma il controllo del dominio impone di considerare l’intera catena potenzialmente esposta: download, documentazione, collegamenti, richieste di assistenza e comunicazioni commerciali. CubePilot ha inoltre invitato i clienti a non eseguire pagamenti richiesti attraverso messaggi apparentemente provenienti dall’azienda senza una conferma telefonica con il contatto abituale. Il rischio non riguarda quindi soltanto le password, ma comprende la possibile distribuzione di file alterati e le frodi finanziarie basate sulla compromissione dell’identità aziendale. La comunicazione ufficiale di sicurezza di CubePilot resta il riferimento per gli aggiornamenti dell’indagine e per l’eventuale identificazione dei soggetti direttamente coinvolti.

Check Point espone una sessione amministrativa pre-auth

CVE-2026-16232, valutata 9,3 su 10, interessa il processo di autenticazione SmartConsole dei Check Point Security Management Server e dei Multi-Domain Security Management Server. Un attaccante non autenticato che riesca a raggiungere il server di gestione può ottenere un application login token, convertirlo in un ticket single sign-on e aprire una sessione SmartConsole dotata di privilegi amministrativi completi. Lo sfruttamento richiede che la configurazione Trusted Clients non limiti i client grafici autorizzati, condizione che Rapid7 ha riscontrato nelle impostazioni predefinite dei sistemi testati.

Check Point ha dichiarato di avere osservato la vulnerabilità in attacchi zero-day contro un numero limitato di clienti e ha distribuito i Jumbo Hotfix il 22 luglio 2026. La gravità non deriva dall’esecuzione diretta di una shell sul sistema operativo, ma dal controllo dell’ambiente utilizzato per amministrare policy, configurazioni e oggetti di sicurezza. Un accesso SmartConsole completo permette di modificare regole, creare amministratori, alterare impostazioni e potenzialmente indebolire l’intero perimetro governato dal Management Server.

Il server accetta l’identità dichiarata dall’attaccante

La causa tecnica consiste in un confine di fiducia errato nel percorso di autenticazione delle applicazioni remote. Il servizio vulnerabile riceve dall’esterno un Secure Internal Communication distinguished name, o SIC DN, e lo utilizza come identità effettiva invece di associarlo al distinguished name contenuto nel certificato realmente presentato dal client. Durante la fase iniziale non autenticata, l’attaccante può leggere il SIC DN del Management Server, reinviarlo come semplice stringa e presentarsi come un’applicazione remota legittima senza possedere un certificato corrispondente. Il server genera quindi un application token che viene utilizzato per richiedere un ticket SmartConsole intestato a system_admin e dotato di tutti i bit di autorizzazione.

Il ticket viene infine riscattato attraverso il servizio SOAP, restituendo gli identificativi di una sessione amministrativa valida. La correzione impone ai client remoti di utilizzare l’identità del certificato autenticato e rifiuta sia le difformità rispetto al DN dichiarato sia le connessioni prive di un’identità SIC verificata. La pubblicazione del PoC aumenta la pressione sui sistemi non aggiornati, già richiamati nell’articolo su Check Point inserita da CISA tra le vulnerabilità sfruttate.

Il PoC permette di verificare sistemi vulnerabili e corretti

Rapid7 ha riprodotto la vulnerabilità su R81.20 e R82.10 e ha pubblicato uno script Python capace di eseguire l’intera sequenza necessaria per ottenere il token applicativo e la sessione SmartConsole. Il proof of concept può essere utilizzato anche per controllare se un sistema sia stato corretto, perché sui target aggiornati il tentativo di bind con il SIC DN contraffatto viene rifiutato prima della generazione del token. Gli amministratori devono installare i Jumbo Hotfix indicati da Check Point, restringere l’accesso di rete al Management Server e configurare Trusted Clients in modo da autorizzare esclusivamente le postazioni realmente utilizzate per l’amministrazione. Nei registri di audit va cercata la stringa “Authentication method: application token”, soprattutto quando associata a sessioni, indirizzi IP o orari non riconducibili agli operatori legittimi. La patch deve essere accompagnata dalla revisione delle policy, degli account amministrativi e delle modifiche applicate durante il periodo di esposizione, perché un aggressore già entrato potrebbe aver creato nuovi percorsi di accesso. Il precedente articolo su Check Point sotto attacco e sullo zero-day SmartConsole fornisce il contesto operativo precedente alla divulgazione tecnica di Rapid7.

Gitea trasforma una patch in un Git hook eseguibile

CVE-2026-60004, valutata 9,8, colpisce le versioni di Gitea dalla 1.17 alla 1.27.0 ed è stata corretta nella 1.27.1. La vulnerabilità richiede autenticazione e permessi di scrittura su un repository, ma le installazioni che conservano le impostazioni predefinite permettono agli utenti esterni di registrarsi, creare un repository e ottenere autonomamente i privilegi necessari. Il problema si trova nell’endpoint POST /api/v1/repos/{owner}/{repo}/diffpatch, utilizzato per applicare una patch all’interno di un clone temporaneo bare. Le versioni vulnerabili eseguono git apply con opzioni che comprendono --index e, con Git 2.32 o successivo, il fallback three-way -3. Inviando due volte la stessa patch, l’attaccante crea una collisione add/add che porta Git a materializzare un file eseguibile nella directory $GIT_DIR/hooks. Un payload collocato come hooks/post-index-change diventa quindi un hook attivo ed è eseguito durante l’aggiornamento dell’indice con i privilegi dell’account di sistema utilizzato da Gitea.

La registrazione aperta riduce la barriera all’attacco

La falla non è tecnicamente pre-auth perché l’endpoint respinge le richieste prive di una sessione valida. La configurazione predefinita di Gitea lascia però aperta la registrazione, non richiede conferma manuale o verifica dell’email, non limita automaticamente i nuovi utenti e consente loro di creare repository. Un visitatore può quindi generare le proprie credenziali, inizializzare un repository privato, inviare la patch malevola e recuperare l’output dei comandi senza possedere in precedenza un account aziendale. Il PoC non necessita nemmeno di una connessione in uscita dal server: l’hook salva il risultato nei Git object, crea un branch e permette all’aggressore di scaricarlo attraverso il normale protocollo HTTP autenticato. L’esecuzione avviene con i privilegi dell’account Gitea e può esporre segreti applicativi, repository montati, database, credenziali OAuth e servizi interni raggiungibili dall’host. La vulnerabilità assume quindi una dimensione supply chain, perché un server Git compromesso può diventare il punto dal quale alterare codice e processi di distribuzione, come già emerso nelle compromissioni di pacchetti AsyncAPI su npm.

Gitea 1.27.1 elimina il clone temporaneo bare

La correzione modifica il clone temporaneo utilizzato dall’endpoint, trasformandolo da bare a non-bare e impedendo che il percorso radice coincida con la directory interna .git contenente gli hook. Gitea ha pubblicato la versione 1.27.1 il 27 luglio, mentre l’advisory è arrivato il giorno successivo con il proof of concept già disponibile. Disabilitare la registrazione aperta riduce la possibilità che un soggetto esterno crei autonomamente l’account necessario, ma non protegge dagli utenti esistenti con accesso in scrittura e non sostituisce l’aggiornamento. Gli amministratori devono cercare file inattesi nelle directory degli hook, processi figli generati dal servizio Gitea, branch o oggetti creati in modo anomalo e accessi all’endpoint diffpatch. La ricostruzione tecnica della RCE di Gitea precisa che non risultano conferme di sfruttamento attivo al 29 luglio, ma la disponibilità pubblica della catena rende rischioso qualsiasi ritardo.

Tre attacchi colpiscono livelli diversi della fiducia

CubePilot, Check Point e Gitea mostrano tre modi differenti di compromettere infrastrutture considerate affidabili. Nel primo caso l’aggressore controlla la destinazione dei servizi e ottiene certificati capaci di rendere credibile il reindirizzamento. Nel secondo convince il server di gestione ad accettare un’identità amministrativa non legata a un certificato autenticato. Nel terzo trasforma una funzione legittima di applicazione delle patch in un percorso per installare codice nella directory degli hook Git. DNS, identità e repository svolgono tutti una funzione di mediazione: indicano dove collegarsi, chi è autorizzato e quale codice può essere considerato valido. Quando uno di questi livelli viene compromesso, la protezione del singolo endpoint non è sufficiente. CubePilot richiede rotazione delle credenziali e verifica dei firmware, Check Point impone patch e analisi delle sessioni amministrative, Gitea necessita dell’aggiornamento e del controllo retroattivo dei repository: in tutti e tre i casi la correzione tecnica deve essere accompagnata dalla ricerca delle azioni già compiute attraverso il rapporto di fiducia violato.