- Cosa può fare
- Un attaccante invia una configurazione CI/CD con un'espressione regolare costruita ad arte e può eseguire codice sul server GitLab. GitLab parla di utente non autenticato; nell'attacco documentato è stato usato un account appena registrato.
- Cosa mette in pericolo
- Codice sorgente, segreti e credenziali delle pipeline (chiavi, token, accessi ai server di produzione) e l'intera catena di rilascio del software. Un server GitLab compromesso può diventare un punto di ingresso verso la rete aziendale.
- Chi è colpito
- GitLab Community Edition ed Enterprise Edition self-managed: versioni 19.2 precedenti alla 19.2.8, 19.3 precedenti alla 19.3.4 (una fonte indica 19.3.5) e 19.4 precedenti alla 19.4.2. GitLab.com è già aggiornato; GitLab Dedicated non richiede azioni. Se GitLab usa un Ruby proprio (installazione da sorgente, immagine personalizzata), serve anche Ruby corretto.
Cosa fare
- Aggiornare GitLab self-managed alla release corretta (19.2.8, 19.3.4/19.3.5 o 19.4.2): le fonti divergono sulla 19.3, verificare nell'avviso ufficiale GitLab.
- Se si usa un Ruby proprio, aggiornare anche Ruby (secondo SecurityWeek: 3.3.13, 3.4.12, 4.0.9 o successive): aggiornare solo GitLab può non bastare.
- Se l'istanza è raggiungibile da internet, limitarne l'accesso (VPN o elenco IP) e disattivare le registrazioni libere finché non è aggiornata.
- Controllare i log per crash anomali dei worker e pipeline sospette dal 12 ottobre 2026; in caso di dubbio ruotare token, chiavi e password salvati in GitLab.
- Chiedere al fornitore IT conferma scritta della versione di GitLab e di Ruby in uso.
Sfruttamento osservato dal 20-21 ottobre 2026 contro l'istanza GitLab di Alpine Linux (tentativo fallito, server ricostruito per prudenza).