Sicurezza di Odoo: i tentativi di accesso sono quotidiani, l'AI li moltiplicherà

Qualcuno sta già bussando

Chi gestisce istanze Odoo raggiungibili da internet lo vede nei log, se li guarda: richieste che non vengono da nessun utente, a qualunque ora, tutti i giorni.

Anche sui sistemi che seguiamo noi arrivano tentativi continui. Sono tutti uguali: qualcuno prova a entrare con nomi utente generici come admin, odoo, demo o root, e qualcuno prova a usare la pagina con cui Odoo crea, copia e salva i database. Finora sono stati tutti respinti.

Non c'è niente di personale. Nessuno ha scelto proprio quell'azienda: sono programmi che passano in rassegna internet alla ricerca di qualunque Odoo risponda, e provano le stesse cose su tutti. Probabilmente non è nemmeno una novità, e succede a chiunque abbia un Odoo online. Proprio per questo il punto non è se qualcuno ci proverà, ma cosa troverà quando lo farà.

E Odoo è un bersaglio ovvio. Dentro c'è tutto quello che serve a un'azienda per lavorare: clienti, fornitori, ordini, fatture, listini, contratti, spesso anche i dati del personale. Un solo sistema, un solo database, e con una configurazione sbagliata una sola porta da aprire.

La porta più grande: il gestore database

Ogni Odoo installato in proprio ha una pagina, all'indirizzo /web/database/manager, da cui si creano, copiano, cancellano, scaricano e ripristinano i database. Durante l'installazione è comoda. In produzione è la porta più grande che si possa lasciare aperta: un backup scaricato da lì contiene tutta l'azienda in un solo file, e un clic su "Delete" la cancella.

Lo dice la stessa Odoo nella documentazione ufficiale: è "fortemente raccomandato" disattivare il gestore su qualunque sistema esposto a internet, perché è uno strumento pensato per sviluppo e dimostrazioni, che "non è progettato per l'uso in produzione e può persino esporre funzioni pericolose agli attaccanti" (documentazione Odoo 18, Database Manager Security).

Quando resta acceso, a proteggerlo c'è una cosa sola: la password master. E c'è un dettaglio che pochi conoscono. Finché la password master è quella predefinita, chi usa per primo il gestore la sceglie lui, e con quella crea, copia, scarica o cancella i database. Lo abbiamo verificato nel codice di Odoo, dalla versione 16 alla 20, e la documentazione lo dice a modo suo: finché la password non è impostata, l'installazione "è accessibile a chiunque su internet" (Reset the master password). Un Odoo appena installato e messo online con le impostazioni di partenza è di chi arriva prima.

Non è un problema teorico, e non è nuovo:

• Nel 2017 Odoo pubblicò un avviso su una campagna di scansione che cercava server Odoo su internet, ne elencava i database e provava l'accesso con admin/admin. Dove entrava, installava un modulo malevolo per eseguire comandi sul server (ODOO-SA-2017-01-27-1).
• Gli scanner di vulnerabilità lo cercano apposta. Tenable, per esempio, classifica come critico un gestore senza password master, perché permette a chiunque di scaricare i database, impostare la password master o ripristinare un database compromesso (plugin 114372).
• A febbraio 2026 è stata pubblicata la CVE-2026-25137, con un punteggio di gravità di 9.1 su 10: nelle installazioni Odoo su NixOS la password master non restava salvata e il gestore era aperto a chiunque, con la possibilità di scaricare o cancellare l'intero database (NVD). Un errore di confezione del pacchetto, non di Odoo, ma il bersaglio è sempre lo stesso.

E anche con una password master robusta, lasciare il gestore raggiungibile significa offrire a chiunque un posto dove provarla, senza limiti di tentativi. Una porta blindata resta pur sempre una porta: meglio non averla sulla strada.

Perché andrà peggio: l'attacco diventa industriale

I tentativi che vediamo oggi sono rozzi: script che ripetono sempre le stesse mosse, con nomi utente scontati e password di default. Funzionano solo contro chi ha lasciato la porta aperta. Il punto è che stanno cambiando gli strumenti con cui vengono costruiti.

A novembre 2025 Anthropic, l'azienda che sviluppa i modelli Claude, ha pubblicato il resoconto di una campagna di spionaggio che aveva individuato e bloccato a metà settembre, attribuita con alta confidenza a un gruppo sostenuto da uno Stato. L'attacco aveva preso di mira una trentina di organizzazioni, tra grandi aziende tecnologiche ed enti governativi, ed era riuscito in alcuni casi. La novità era il modo: gli attaccanti avevano fatto svolgere a un agente AI l'80-90% delle operazioni in modo autonomo, dalla ricognizione alla ricerca delle vulnerabilità fino all'estrazione dei dati, con l'intervento umano limitato a poche decisioni chiave e un ritmo di richieste che il rapporto definisce "fisicamente impossibile" per un essere umano (rapporto Anthropic, novembre 2025).

La conclusione del rapporto è quella che riguarda tutti: le barriere per condurre attacchi sofisticati "si sono abbassate in modo sostanziale" e continueranno a farlo, e gruppi con meno esperienza e meno risorse possono ora tentare attacchi su larga scala. Lo stesso rapporto riconosce un limite: l'AI esagerava i risultati e a volte se li inventava, il che oggi frena gli attacchi completamente autonomi. Oggi.

Chi si occupa di sicurezza per mestiere va nella stessa direzione. Nelle sue previsioni per il 2026 Trend Micro parla della "vera industrializzazione del cybercrime", con agenti AI che "scopriranno, sfrutteranno e monetizzeranno le debolezze senza intervento umano" (comunicato Trend Micro, 25 novembre 2025). È una previsione, non una misura, e viene da chi vende sicurezza; ma è coerente con quello che i casi documentati mostrano già.

Per chi ha un Odoo online la conseguenza è semplice. Quando provare costa quasi zero, nessuno sceglie più il bersaglio: si prova tutto, su tutti, di continuo, e sempre meglio. Un errore di configurazione che ieri poteva restare inosservato per mesi, con ogni probabilità, verrà trovato prima, e lo stesso vale per una vulnerabilità appena pubblicata. La sicurezza "abbastanza buona" smette di esserlo, perché il numero di chi bussa cresce e chi bussa diventa più bravo.

Cosa fare: la checklist

La documentazione ufficiale di Odoo dedica un capitolo alla sicurezza e apre con una frase da tenere a mente: proteggere un sistema "è un processo continuo, non un'operazione una tantum", e si è sicuri quanto l'anello più debole (Security). Quella che segue è la lista che applichiamo, divisa in due: quello che va fatto subito e quello che separa un'installazione funzionante da un'installazione solida.

Vale per Odoo installato in proprio, su un server vostro o in cloud. Su Odoo Online e Odoo.sh buona parte di questi aspetti è gestita da Odoo, mentre utenti, accessi e moduli restano vostri.

Da fare oggi

1. Spegnere il gestore database. Nel file di configurazione list_db = False blocca la selezione e la gestione dei database, e dbfilter (con db_name) dice a Odoo quale database servire. In più, il proxy deve rifiutare tutto ciò che inizia con /web/database. Sono le indicazioni della documentazione ufficiale. Creare, copiare e salvare database diventa un'operazione da sistemista, fatta dal server, non da una pagina web.

2. Una password master vera. Anche con il gestore spento, la password master va cambiata dal valore predefinito: casuale, lunga, diversa per ogni installazione e custodita in un gestore di password. Nel file di configurazione conviene scriverne l'hash e non il testo in chiaro: Odoo lo accetta, e chi legge il file non scopre la password.

3. Odoo non deve rispondere direttamente da internet. Davanti a Odoo va un proxy (per esempio nginx) che gestisce HTTPS con un certificato valido, e Odoo deve ascoltare solo sull'interfaccia locale, con le sue porte (di solito 8069 e 8072) chiuse dall'esterno. Un firewall sul server lascia aperto solo ciò che serve: in genere SSH, HTTP e HTTPS. È inutile proteggere la porta principale se resta aperta quella di servizio.

4. Niente admin, niente password di default. La documentazione è esplicita: login unici e password robuste per tutti gli amministratori, "mai" admin/admin, neanche sugli ambienti di prova, e niente dati dimostrativi sui server esposti, perché contengono utenti e password noti (Security).

5. Autenticazione a due fattori per tutti gli utenti interni. È già in Odoo, anche nella versione Community: il modulo Two-Factor Authentication (TOTP) aggiunge il codice da app, e il modulo 2FA by mail permette di renderla obbligatoria per tutti, con un codice via email per chi non ha ancora configurato l'app. Una password rubata, da sola, non basta più.

Da fare bene

6. Il database con il minimo dei privilegi. L'utente PostgreSQL con cui Odoo si collega "non deve essere un superutente", e per rendere il gestore del tutto inutilizzabile non deve nemmeno poter creare database (documentazione). Se Odoo venisse compromesso, il danno resterebbe confinato al suo database.

7. Fermare chi prova le password. Odoo registra ogni accesso, riuscito o fallito, con l'utente e l'indirizzo di provenienza, e la documentazione suggerisce di usare questi log con strumenti come fail2ban per bloccare chi sbaglia troppe volte (Blocking Brute Force Attacks). Odoo ha anche un suo rallentamento dopo una serie di tentativi falliti dallo stesso indirizzo, ma funziona bene solo se il proxy è configurato correttamente (proxy_mode): altrimenti Odoo vede tutti arrivare dallo stesso indirizzo, quello del proxy.

8. Aggiornare. Installare regolarmente gli aggiornamenti della propria versione, come raccomanda la documentazione, e non restare su versioni che non ricevono più correzioni. Se cercare e sfruttare le falle diventa un lavoro da macchina, è ragionevole aspettarsi che una falla pubblicata venga provata su larga scala sempre prima: chi aggiorna tardi resta scoperto più a lungo.

9. Backup che si possono davvero usare. Backup giornalieri del database e dei file allegati, copiati su un server di archivio che il server di Odoo "non può raggiungere" (documentazione): se qualcuno entra nel server, non deve poter cancellare anche le copie. E un backup vale solo se il ripristino è stato provato.

10. Conservare i log, e guardarli. I log di Odoo, del proxy e del database vanno conservati abbastanza a lungo da ricostruire cosa è successo, anche settimane dopo: un'intrusione silenziosa si scopre spesso tardi. E qualcuno, o qualcosa, deve leggerli: tentativi ripetuti sul gestore o sugli accessi sono un segnale da non ignorare.

11. Chiavi API e integrazioni sotto controllo. Ogni integrazione con la sua chiave API, intestata a un utente con i soli permessi che servono, e revoca delle chiavi non più usate. Una chiave dimenticata è una password che nessuno controlla.

12. Moduli di terze parti con giudizio. Un modulo installato gira con i permessi di Odoo. La campagna del 2017 entrava proprio installando un modulo malevolo (ODOO-SA-2017-01-27-1). Prima di installare un modulo: chi lo pubblica, chi lo mantiene, cosa fa.

13. Produzione separata da prove e collaudi. Gli ambienti di test e di staging su macchine diverse dalla produzione e con le stesse protezioni, come suggerisce la documentazione: spesso contengono una copia dei dati veri, ma sono custoditi peggio.

Il test di un minuto

Tre controlli che chiunque può fare sul proprio Odoo, da un browser, senza toccare niente:

1. Aprite https://il-vostro-dominio/web/database/manager. Se compare la pagina per creare, copiare o salvare i database, il gestore è raggiungibile da chiunque. Se compare ma dice che il gestore è disattivato, è spento ma la pagina è ancora esposta: manca il blocco nel proxy. La risposta giusta è una pagina di errore.
2. Aprite http://il-vostro-dominio:8069. Se risponde Odoo, il server è raggiungibile direttamente, scavalcando il proxy e il suo HTTPS. La risposta giusta è nessuna risposta.
3. Fatevi una domanda: quando è stato provato l'ultima volta il ripristino di un backup? Se la risposta è "mai", il backup è una speranza, non una protezione.

Se anche uno solo di questi controlli non torna, o se non sapete chi dovrebbe accorgersi di un tentativo di intrusione sul vostro Odoo, è il momento di guardarci.

Possiamo farlo noi: verifichiamo la sicurezza della vostra installazione Odoo, dalla configurazione agli accessi, dai backup ai log, e vi consegniamo l'elenco di cosa sistemare, in ordine di priorità. È un servizio a pagamento: il costo dipende dall'installazione e lo definiamo dopo una prima analisi. Contattateci.

La sicurezza non è una funzione che si installa una volta: è un'abitudine. Gli attacchi diventeranno più numerosi e più capaci; un Odoo ben configurato, aggiornato e sorvegliato resta comunque un bersaglio difficile, ed è quello che chi prova tutto su tutti tende a lasciar perdere.