2.9 milioni di download, 8 sviluppatori, 22 CVE: la ZimaOS vulnerabilità che nessuno vuole guardare in faccia
Un NAS OS con un auth bypass da CVSS 9.8 non è un prodotto: è un invito a cena per chiunque abbia uno scanner di rete e cinque minuti liberi.
ZimaOS, il sistema operativo di IceWhaleTech che promette self-hosting facile su hardware proprietario — ZimaBoard, ZimaBlade, ZimaCube — ha accumulato 22 vulnerabilità registrate in poco più di due anni. Tre delle più recenti sono devastanti. E la cosa che dovrebbe toglierti il sonno non è la gravità tecnica: è che tutte e 10 le advisory su GitHub sono ancora marchiate Unpatched. Nel frattempo, se ti interessa capire perché il self-hosting sicuro 2026 è un obiettivo e non un default, il contesto è esattamente questo.
L'interfaccia ZimaOS: bella, pulita, e con l'autenticazione opzionale. Credit: IceWhaleTech
CVE-2026-21891: entra con qualsiasi password
Partiamo dal capolavoro. CVE-2026-21891, pubblicata l’8 gennaio 2026: CVSS 9.8 secondo NIST, 9.4 secondo GitHub CNA. CWE-287, Improper Authentication. L’applicazione salta la validazione della password quando lo username corrisponde a un account di servizio di sistema. Tradotto: se conosci il nome di un utente di sistema — e su Linux non serve essere hacker per trovarli — entri. Con qualsiasi password. Con nessuna password. Con "pippo123".
Non è una race condition esotica. Non è un timing attack. È un if che manca.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Cybersecurity
CVE-2026-7482, Bleeding Llama fa sanguinare 300mila server Ollama
CVE-2026-7482: con tre chiamate API la vulnerabilita Ollama 2026 Bleeding Llama leakka memoria e token da 300k server esposti. Patch e mitigazioni.
IceWhaleTech dichiara di aver fixato nella v1.5.4 (3 febbraio 2026), ma l’advisory GitHub resta "Unpatched".
La versione 1.5.4 menziona "fixed auth bypass via system-level username handling". Ma se l’advisory ufficiale su GitHub dice ancora Unpatched, quale informazione prevale? Questa ambiguità è già di per sé un problema di sicurezza — CasaOS sicurezza e comunicazione trasparente non vanno esattamente a braccetto in casa IceWhaleTech.
Altre ZimaOS vulnerabilità: path traversal in /etc via API
Come se l’auth bypass non bastasse, a marzo 2026 arrivano le gemelle: CVE-2026-28286 e CVE-2026-28442. Entrambe CVSS 8.5/8.6, entrambe su ZimaOS 1.5.2-beta3. La prima permette di creare file e cartelle in directory di sistema — /etc, /usr — chiamando direttamente l’API. La seconda fa lo stesso, ma in cancellazione.
Riesci a immaginare cosa succede se qualcuno scrive un crontab in /etc o cancella /etc/shadow?
Il pattern è identico a quello che si ripete dal 2023: l’interfaccia web impedisce azioni pericolose, ma il backend API è completamente aperto. È come mettere un lucchetto sulla porta e lasciare il garage spalancato. Non una volta. Non due. Ogni volta.
Il DNA è CasaOS: stessi geni, stesse ZimaOS vulnerabilità
Per capire come siamo arrivati qui serve tornare indietro. ZimaOS è un fork di CasaOS, e CasaOS ha lo stesso identico vizio congenito. Nell’ottobre 2023, Thomas Chauchefoin di Sonar ha scoperto due CVE critiche da 9.8: CVE-2023-37265 — auth bypass via spoofing dell’header X-Forwarded-For — e CVE-2023-37266, dove il segreto HMAC-SHA256 per i JWT era una stringa vuota. Vuota. Letteralmente zero byte di entropia.
IceWhaleTech ha patchato in 14 giorni con la v0.4.4. Ma come ha sottolineato Chauchefoin, entro 10 giorni dalla release di sicurezza erano già comparsi exploit pubblici. Tutte le istanze non aggiornate erano già compromettibili.
"Ho scoperto le vulnerabilità per caso, mentre cercavo di accedere al setup del mio ZimaCube perché la tastiera non aveva i tasti F." — himazawa, ricercatore sicurezza, 2024
Nel 2024, himazawa ha dimostrato una catena RCE completa: lettura file arbitraria, directory traversal, upload path traversal, esecuzione come root al boot. Il fix parziale è arrivato dopo circa 40 giorni. Un ricercatore che non stava nemmeno cercando bug li ha trovati per sbaglio. Se questo non è un red flag architetturale, non so cosa lo sia.
La timeline che racconta tutto
Ottobre 2023 — Sonar scopre 2 CVE critiche 9.8 in CasaOS. Patchate in 14 giorni.
Giugno 2024 — himazawa dimostra RCE completa su ZimaOS. Fix parziale in ~40 giorni.
Ottobre 2024 — 5 CVE per ZimaOS ≤1.2.4.
Settembre 2025 — altre 2 CVE, questa volta per la ≤1.4.1. Il pattern è chiaro.
Gennaio 2026 — CVE-2026-21891, auth bypass CVSS 9.8.
Marzo 2026 — CVE-2026-28286 e CVE-2026-28442, path traversal su directory di sistema.
22 CVE in circa due anni. Stesso pattern. Stesso errore. Validazione solo lato UI, API backend nudo.
8 contributor per 2.9 milioni di installazioni
Ecco il numero che mi tiene sveglio la notte: ZimaOS ha 8 contributor su GitHub. Otto persone per un software installato su 2.9 milioni di dispositivi, con una community Discord da 30.000 utenti. CasaOS, il progetto padre, ha 33.500 stelle su GitHub ma non riceve aggiornamenti dal dicembre 2024. L’ultimo release è la v0.4.15. Sviluppo migrato su ZimaOS, ma con lo stesso organico.
Il ZimaCube: hardware curato, software con 22 CVE. Credit: IceWhaleTech
IceWhaleTech, fondata da Lauren Pan nel 2021 con un team di 4 persone, ha un business model chiaro: vendere hardware con ZimaOS come piattaforma. Il software è il veicolo, non il prodotto. E si vede. I contributor su GitHub riportano ticket aperti che non vengono smistati dai maintainer, PR bloccate in review, discussioni fantasma e silenzio nel canale Discord #casaos-dev.
Nessun security audit di terze parti è mai stato pubblicato.
La policy di disclosure dice: email a [email protected], 10 giorni per acknowledgment, 90 per disclosure. Sulla carta, ragionevole. Nella pratica, le advisory restano Unpatched e la comunicazione è opaca. Chi gestisce un homelab con servizi esposti sa che 90 giorni con un auth bypass 9.8 aperto sono un’eternità.
"Ma io lo uso solo in LAN"
Lo so cosa stai pensando. Lo pensano anche gli utenti su LowEndSpirit: ZimaOS è pensato per reti locali, non per internet. Dietro firewall e NAT il rischio è ridotto. La comodità supera il rischio residuo.
Ed è vero. In parte.
Ma "solo in LAN" presuppone che nessun dispositivo nella tua rete venga mai compromesso. Nessun telefono con un’app malevola, nessun IoT con firmware obsoleto, nessun guest sul Wi-Fi. Un singolo dispositivo compromesso sulla stessa rete trasforma un auth bypass "locale" in accesso completo al tuo NAS. E con le CVE path traversal, da lì si arriva a scrivere in /etc — il che significa persistenza, escalation, e potenzialmente una backdoor permanente.
Come ha scritto Zapier nella sua analisi sul self-hosting 2026: chi fa self-hosting si prende in carico ogni decisione di sicurezza. A differenza di un fornitore SaaS, un team IT interno — o nel nostro caso, un homelabber singolo — deve dividere l’attenzione, portando a risposte ritardate alle minacce. Le piattaforme one-click come ZimaOS promettono di eliminare questa complessità. Invece la mascherano.
Cosa fare adesso: hardening e ZimaOS vulnerabilità mitigation
Se stai usando ZimaOS, non ti sto dicendo di buttare tutto. Ti sto dicendo di non fidarti.
Se vuoi restare su ZimaOS
Aggiorna immediatamente alla v1.5.4 o successiva.
MAI esporre l’interfaccia web a internet. Mai. Nemmeno con password forte.
Accesso esclusivamente via VPN — WireGuard è lo standard.
VLAN dedicata per il NAS, isolata dal resto della rete.
Firewall deny-by-default: solo le porte necessarie, solo dai dispositivi autorizzati.
Monitora le advisory GitHub di IceWhaleTech. Non aspettare l’OTA.
Se vuoi alternative serie
Chi ha già fatto il salto verso il self-hosting consapevole sa che la scelta della piattaforma è una decisione di sicurezza, non di comodità. Alcune CasaOS alternative con un approccio diverso alla sicurezza:
Cosmos Server — sicurezza built-in con SmartShield e SSO integrato, 5.800 stelle su GitHub, sviluppo attivo.
YunoHost fa il contrario di ZimaOS: niente container, permessi UNIX tradizionali, meno trendy ma più solido.
Runtipi — 200+ app, TypeScript, approccio moderno ma con più attenzione alla separazione dei privilegi.
Il convitato di pietra: NIS2 e il principio ignorato
Un dettaglio che in Italia nessuno ha ancora collegato. La direttiva NIS2, in vigore da ottobre 2024, impone il principio "security by design" a tutta la filiera digitale europea. ZimaOS — con la sua architettura che valida in UI e lascia il backend aperto, con advisory marcate Unpatched, senza audit di terze parti — viola questo principio alla radice.
Certo, un homelab domestico non rientra direttamente nel perimetro NIS2. Ma se usi ZimaOS in un contesto aziendale — piccola impresa, studio professionale, laboratorio — stai mettendo dati regolamentati su una piattaforma che non supererebbe nessuna due diligence seria. I thread su Tom’s Hardware Forum Italia parlano di ZimaOS in termini di funzionalità e facilità d’uso. Di sicurezza, zero menzioni. Come se la sicurezza di un sistema che custodisce i tuoi dati fosse un dettaglio trascurabile.
La provocazione
Le piattaforme "one-click" per il self-hosting sono una contraddizione in termini. Ogni livello di astrazione che nascondi è un livello di sicurezza che perdi. ZimaOS ha 2.9 milioni di download e 8 contributor. Lo stesso errore architetturale — validazione solo UI, backend completamente esposto — si ripete identico dal 2023. Non è un bug ricorrente: è una scelta progettuale.
Se il tuo NAS "facile" ha un auth bypass da CVSS 9.8 e le advisory restano Unpatched per mesi, non stai facendo self-hosting. Stai facendo hosting per chiunque passi. E nel 2026, con le ZimaOS vulnerabilità documentate e ignorate, continuare a usarlo senza hardening non è ottimismo — è negligenza.
