Nel panorama della sicurezza informatica, quando si parla di GitHub, l’attenzione è sempre massima. Parliamo della “casa” del codice sorgente di milioni di progetti in tutto il mondo, uno strumento che non è solo un deposito di file, ma il cuore pulsante dello sviluppo software moderno. Recentemente, la piattaforma è finita sotto i riflettori per una vulnerabilità piuttosto seria, identificata con la sigla CVE-2026-3854, con gravità pari a 8.7 su 10, pertanto di gravità critica. Si tratta di un problema che tocca sia la versione pubblica di GitHub.com sia quella dedicata alle aziende, il GitHub Enterprise Server, e che ha sollevato non poche preoccupazioni tra gli esperti di sicurezza per la facilità con cui, in teoria, potrebbe essere sfruttata.
La notizia, segnalata anche dal CERT-AgID e da CSIRT, riguarda una falla di tipo Remote Code Execution (RCE), ciò questo significa che sfruttandola un malintenzionato potrebbe riuscire a eseguire comandi o programmi arbitrari direttamente sui server che ospitano il codice. La cosa curiosa, e allo stesso tempo inquietante, è il modo in cui questo può avvenire, perché il tutto parte da un semplice comando di git push. Normalmente, su GitHub, quando uno sviluppatore carica le proprie modifiche, può inviare delle piccole informazioni aggiuntive chiamate “opzioni di push”. Gli esperti hanno scoperto che queste informazioni non venivano “pulite” correttamente dal sistema. Un utente con i permessi di scrittura su un archivio potrebbe inserire dei caratteri speciali in queste opzioni per “ingannare” i protocolli interni di GitHub, riuscendo a scavalcare le barriere di sicurezza e ad arrivare alle macchine sottostanti. In pratica, un hacker che sfrutta sapientemente questa vulnerabilità usa una funzione normale e quotidiana (il caricamento delle modifiche) per “nascondere” un ordine illegittimo che il server eseguirebbe senza effettuare.
Ciò che rende questa vulnerabilità particolarmente rilevante è il fatto che sia stata definita estremamente facile da sfruttare. Non serve un attacco complesso o una catena infinita di errori, è sufficiente generare in modo “corretto” un solo comando. Se un utente ha i permessi per contribuire a un progetto, potrebbe potenzialmente colpire l’intera infrastruttura che lo ospita. Fortunatamente, GitHub si è mossa con estrema rapidità dato che coloro che utilizzano la versione web standard della piattaforma hanno già approfittato dell’applicazione automatica delle patch di protezione effettuata dai tecnici. Il discorso cambia invece per le aziende che gestiscono i propri server privati con la versione Enterprise, poiché in questo caso, è strettamente necessario che gli amministratori di sistema installino manualmente le patch di sicurezza rilasciate per chiudere definitivamente il buco, e sappiamo quanto questo talvolta incontri la “pigrizia” di determinati gestori di sistemi.
Guardando a questa vicenda, emerge una riflessione importante sulla natura della sicurezza nel software, perché a volte i pericoli più grandi non arrivano da attacchi esterni sofisticati, bensì da piccoli difetti di gestione nei gesti compiuti quotidianamente, come il caricamento di una riga di codice. Il miglior consiglio che si può dare a tutte quelle aziende che che utilizzano soluzioni “on-premise” è di non rimandare mai gli aggiornamenti, questo perché, come diciamo sempre su questo blog, la velocità di reazione è una delle poche difese veramente efficaci. Inoltre, è sempre buona norma applicare il principio del privilegio minimo, evitando di concedere permessi di scrittura a chiunque non ne abbia strettamente bisogno, poiché ogni utente autorizzato rappresenta, anche involontariamente, una potenziale porta d’ingresso per chi sa dove guardare. Un ultimo consiglio, dato da CERT-AgID agli utenti di GitHub, è quello di analizzare il file /var/log/github-audit.log e controllare l’eventuale presenza di anomalie nelle operazioni di push.
Fonte: 1
