Una falla di sicurezza classificata al punteggio massimo possibile, CVSS 10.0, sta mettendo a rischio migliaia di installazioni della piattaforma di business intelligence Metabase in tutto il mondo, Italia compresa. La vulnerabilità, identificata come CVE-2026-72898, permette a un attaccante non autenticato di iniettare comandi SQL arbitrari attraverso l’endpoint di reset della password e ottenere il pieno controllo amministrativo dell’istanza, comprese le credenziali dei database collegati. La Cybersecurity and Infrastructure Security Agency (CISA) statunitense l’ha inserita nel catalogo Known Exploited Vulnerabilities (KEV) l’11 agosto 2026, confermando che lo sfruttamento attivo era già in corso prima della pubblicazione della patch.
Per le aziende europee che usano Metabase come strumento gratuito e open source per dashboard e analisi dati, la notizia arriva in un momento delicato: agosto 2026 si sta rivelando un mese denso di vulnerabilità critiche aggiunte al catalogo CISA e di attacchi ransomware contro le piccole e medie imprese italiane. Vediamo cosa è successo, chi rischia di più e cosa fare subito.
Cos’è successo: la falla in Metabase spiegata
Metabase è una delle piattaforme di business intelligence open source più diffuse al mondo, usata da startup, PMI e reparti dati di aziende più grandi per costruire dashboard senza scrivere query complesse. Proprio questa diffusione rende la vulnerabilità appena scoperta particolarmente pericolosa. Secondo l’advisory ufficiale pubblicata da Metabase (identificata come GHSA-vwf4-m7j8-wcjf), il problema risiede nell’endpoint POST /api/session/reset_password, pensato per gestire il recupero della password degli utenti.
Il difetto nasce da una convalida insufficiente dei campi inviati nel corpo della richiesta JSON. Campi non dichiarati vengono passati a un query builder che li interpreta come istruzioni SQL invece che come semplice testo. Un attaccante remoto, senza bisogno di credenziali né di alcuna interazione dell’utente, può costruire una richiesta HTTP appositamente formata e ottenere l’accesso come amministratore all’istanza Metabase.
Le conseguenze non si fermano al pannello di controllo. Chi ottiene i privilegi di amministratore può leggere le credenziali dei database esterni collegati a Metabase, esportare i dati aziendali visibili nelle dashboard e, potenzialmente, muoversi lateralmente verso i sistemi a cui quelle credenziali danno accesso. Bishop Fox, la società di sicurezza che ha analizzato in dettaglio il bug, ha confermato che lo sfruttamento nel mondo reale era già attivo al momento della divulgazione pubblica.
Il punteggio CVSS 10.0: cosa significa in pratica
Un punteggio CVSS di 10.0 è il massimo assegnabile nella scala di gravità e viene riservato a un numero ristretto di vulnerabilità ogni anno. Il vettore completo assegnato a CVE-2026-72898 è AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: attacco eseguibile da remoto via rete, complessità bassa, nessun privilegio richiesto, nessuna interazione dell’utente necessaria, cambio di ambito (l’impatto va oltre l’applicazione stessa) e danno massimo su riservatezza, integrità e disponibilità dei dati.
In termini semplici: chiunque conosca l’indirizzo di un’istanza Metabase esposta su internet può, in teoria, prenderne il controllo completo senza dover indovinare password né sfruttare tecniche di ingegneria sociale. È lo scenario peggiore per un team di sicurezza, perché elimina quasi tutte le barriere che normalmente rallentano un attacco automatizzato su larga scala.
Versioni interessate e patch disponibili
Il problema riguarda sia l’edizione open source sia quella Enterprise di Metabase, in un intervallo di versioni piuttosto ampio che copre sei rami di sviluppo consecutivi, dalla serie 58 alla serie 63. Ecco il quadro completo pubblicato da Metabase insieme alle versioni corrette:
| Ramo | Versioni vulnerabili | Versione con patch | Edizione |
|---|---|---|---|
| 58.x | da 58.0 a <58.23 | 58.24 | OSS + Enterprise |
| 59.x | da 59.0 a <59.20 | 59.21 | OSS + Enterprise |
| 60.x | da 60.0 a <60.16 | 60.17 | OSS + Enterprise |
| 61.x | da 61.0 a <61.10 | 61.11 | OSS + Enterprise |
| 62.x | da 62.0 a <62.8 | 62.9 | OSS + Enterprise |
| 63.x | da 63.0 a <63.3 | 63.5 | OSS + Enterprise |
Metabase raccomanda esplicitamente di non fidarsi delle build immediatamente successive ai limiti superiori indicati nella tabella, a meno che non corrispondano esattamente alla versione con patch: i team IT devono aggiornare direttamente alla release indicata, non semplicemente a “una versione più recente” scelta a caso. Chi non può aggiornare subito dovrebbe restringere l’accesso di rete a Metabase dietro VPN o gateway SSO e, soprattutto, ruotare le credenziali dei database collegati, dato che potrebbero essere già state compromesse.
Cronologia: dallo zero-day al catalogo KEV di CISA
La sequenza degli eventi racconta una storia comune nel 2026: lo sfruttamento è iniziato prima che la vulnerabilità fosse pubblica. Metabase ha pubblicato l’advisory di sicurezza intorno al 6 agosto 2026. Il National Vulnerability Database (NVD) statunitense ha registrato ufficialmente CVE-2026-72898 il 10 agosto. Il giorno seguente, l’11 agosto 2026, CISA ha aggiunto la vulnerabilità al catalogo Known Exploited Vulnerabilities, la lista ufficiale delle falle per cui esiste evidenza concreta di sfruttamento attivo.
L’inserimento nel KEV comporta un obbligo preciso per le agenzie federali civili statunitensi, previsto dalla Binding Operational Directive 26-04: la scadenza per la messa in sicurezza è stata fissata al 14 agosto 2026, appena tre giorni dopo. Per le organizzazioni fuori dagli Stati Uniti quella scadenza non è vincolante, ma nella pratica funziona come segnale d’allarme che gli attaccanti stanno già sfruttando la falla su larga scala, non solo in test di laboratorio.
Secondo l’analisi di Dataminr, lo sfruttamento nel mondo reale ha preceduto sia la patch sia la divulgazione pubblica, la definizione tecnica di un vero attacco zero-day. Questo significa che, teoricamente, alcune organizzazioni potrebbero essere state compromesse settimane prima di sapere che la vulnerabilità esisteva.
Quante istanze Metabase sono esposte online
Le stime pubbliche parlano di “migliaia” di istanze Metabase self-hosted raggiungibili direttamente da internet, molte delle quali collegate a database di produzione. Dataminr, in un intel brief dedicato, ha titolato la propria analisi segnalando che il bug “espone migliaia di istanze self-hosted”, senza però pubblicare un conteggio esatto per singolo paese. Non esistono al momento numeri ufficiali specifici per l’Italia o per l’Europa nel suo complesso, ma diverse fonti concordano che il continente rappresenta una delle aree di maggiore concentrazione, insieme al Nord America, per settori come manifattura, retail, servizi finanziari e pubblica amministrazione che usano Metabase come alternativa gratuita alle suite BI commerciali.
È una lacuna informativa che vale la pena sottolineare: senza un conteggio verificato tramite motori di scansione come Shodan o Censys specifico per l’Italia, qualsiasi cifra locale sarebbe una stima non verificabile. Quello che si può dire con certezza è che Metabase è particolarmente popolare tra PMI e SaaS provider europei proprio perché è gratuito e semplice da installare su un server, la stessa caratteristica che lo rende ora un bersaglio comodo per chi scansiona internet alla ricerca di endpoint vulnerabili.
Il confronto con le altre falle critiche aggiunte al KEV ad agosto 2026
CVE-2026-72898 non è un caso isolato. Nelle stesse settimane, CISA ha aggiunto al catalogo KEV una serie di altre vulnerabilità critiche che toccano strumenti largamente usati anche in Europa, dai server di continuous integration ai firewall aziendali. Tra il 9 luglio e il 5 agosto 2026, l’agenzia ha inserito complessivamente 26 nuove voci nel catalogo sulla base di prove concrete di sfruttamento attivo. La tabella seguente mette a confronto le vulnerabilità più gravi aggiunte proprio nella settimana in cui è emersa la falla Metabase.
| CVE | Prodotto | Punteggio CVSS | Aggiunta al KEV | Scadenza federale USA |
|---|---|---|---|---|
| CVE-2026-72898 | Metabase (SQL injection non autenticata) | 10.0 | 11 ago 2026 | 14 ago 2026 |
| CVE-2026-63077 | JetBrains TeamCity (RCE via deserializzazione) | 9.8 | 5 ago 2026 | 8 ago 2026 |
| CVE-2026-8037 | Progress LoadMaster (command injection) | 9.8 | 7 ago 2026 | 10 ago 2026 |
| CVE-2026-20349 | Cisco ASA / Secure Firewall Threat Defense (DoS) | 8.6 | 11 ago 2026 | 14 ago 2026 |
| CVE-2026-68820 | Windows AFD.sys (escalation di privilegi locale) | 7.0 | 11 ago 2026 | 14 ago 2026 |
Quest’ultima voce, CVE-2026-68820, merita una menzione a parte: shattered.io ha già raccontato come il gruppo Lazarus l’abbia sfruttata contro obiettivi della difesa europea. Il fatto che tre vulnerabilità di gravità alta o critica siano state aggiunte al KEV nello stesso giorno, l’11 agosto, dà la misura di quanto sia diventato frenetico il ritmo delle scoperte nel 2026 rispetto agli anni precedenti.
Perché gli strumenti di business intelligence sono bersagli sempre più appetibili
CVE-2026-72898 si inserisce in un pattern più ampio che i ricercatori di sicurezza osservano da tempo: le piattaforme di business intelligence e analytics stanno diventando obiettivi di prima scelta per gli attaccanti, non solo per curiosità tecnica ma per convenienza operativa. Tre fattori spiegano il fenomeno.
Primo, questi strumenti aggregano per definizione dati sensibili provenienti da più fonti aziendali in un unico posto, il che rende un singolo attacco riuscito molto più redditizio che compromettere un server isolato. Secondo, spesso mantengono connessioni dirette verso i database di produzione, con credenziali salvate localmente per semplificare l’esperienza d’uso. Terzo, e forse il fattore decisivo, vengono frequentemente installati in autonomia da reparti dati o marketing senza il coinvolgimento del team di sicurezza, e finiscono esposti direttamente su internet senza controlli d’accesso adeguati.
Rispetto ad altre vulnerabilità BI emerse nel biennio 2025-2026, spesso legate a bug di deserializzazione o a configurazioni errate che richiedevano comunque un accesso autenticato, CVE-2026-72898 si distingue per essere completamente non autenticata su un’installazione di default. Questo la colloca al vertice della scala di gravità per l’intera categoria degli strumenti di analisi dati open source.
Cosa dicono le fonti tecniche
L’advisory ufficiale di Metabase non lascia spazio a interpretazioni sulla gravità del problema: “This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance” (“Si tratta di una vulnerabilità CRITICA che permette a un attaccante remoto non autenticato di iniettare SQL arbitrario nel database dell’applicazione Metabase, cosa che può garantirgli l’accesso come amministratore all’istanza”), si legge nella security advisory pubblicata su GitHub.
Il National Vulnerability Database descrive il meccanismo tecnico in termini altrettanto netti: “Metabase allows a remote, unauthenticated attacker to inject arbitrary SQL via the ‘/reset_password’ database endpoint and gain administrator access to the connected Metabase instance” (“Metabase permette a un attaccante remoto e non autenticato di iniettare SQL arbitrario tramite l’endpoint database ‘/reset_password’ e ottenere accesso da amministratore all’istanza Metabase collegata”), riporta la scheda ufficiale NVD.
ProjectDiscovery Cloud, piattaforma di intelligence sulla sicurezza usata da molti team di threat hunting, sintetizza così la causa tecnica: “Metabase contains a sql injection caused by improper sanitization of input in the ‘/reset_password’ database endpoint, letting remote unauthenticated attackers gain administrator access” (“Metabase contiene una SQL injection causata da una sanificazione impropria dell’input nell’endpoint database ‘/reset_password’, che permette ad attaccanti remoti non autenticati di ottenere accesso da amministratore”), spiega il riepilogo tecnico pubblicato da ProjectDiscovery.
Il blog di sicurezza ByteIota inquadra il problema dal punto di vista dell’esposizione pratica: “The flaw – tracked as GHSA-vwf4-m7j8-wcjf, CVSS 10.0 – lives in an unauthenticated public endpoint” (“La falla, tracciata come GHSA-vwf4-m7j8-wcjf con CVSS 10.0, vive in un endpoint pubblico non autenticato”), si legge nell’articolo di ByteIota.
Infine, l’analisi di Threadlinqs Intelligence descrive con precisione l’impatto finale sull’infrastruttura colpita: “Successful exploitation lets the attacker manipulate database records to promote themselves to an administrator account, effectively gaining full control of the instance” (“Uno sfruttamento riuscito permette all’attaccante di manipolare i record del database per promuoversi ad account amministratore, ottenendo di fatto il controllo completo dell’istanza”), secondo il report di threat intelligence pubblicato da Threadlinqs.
L’impatto sull’Italia e sul resto d’Europa
Il contesto italiano di agosto 2026 rende questa vulnerabilità ancora più preoccupante. Nella settimana tra il 6 e il 13 agosto, otto gruppi di estorsione diversi hanno rivendicato 15 attacchi contro organizzazioni italiane, quasi tutte piccole e medie imprese industriali o a conduzione familiare, un dato che shattered.io ha già analizzato in dettaglio. Sono proprio le PMI il tipo di organizzazione più esposto a una falla come CVE-2026-72898, perché tendono ad avere reparti IT più piccoli, patch management meno rigoroso e maggiore probabilità di lasciare strumenti come Metabase esposti direttamente su internet per comodità.
Il quadro normativo italiano aggiunge un ulteriore livello di rischio economico. A luglio 2026 il Garante per la protezione dei dati personali ha sanzionato l’operatore telefonico WINDTRE con una multa da 1,7 milioni di euro per carenze nei sistemi di sicurezza che avevano portato a due violazioni non autorizzate, con l’esposizione di dati personali di oltre 365.000 clienti. Un’azienda che lascia un’istanza Metabase vulnerabile esposta, con dati personali di clienti visibili nelle dashboard, rischia scenari sanzionatori analoghi in base al GDPR.
A livello europeo, il CERT-EU, l’organismo di risposta alle emergenze informatiche per le istituzioni dell’Unione, richiama nelle sue advisory 2026 proprio le vulnerabilità presenti nel catalogo KEV di CISA, sottolineando che l’inclusione in quella lista è già di per sé un segnale che l’exploit circola attivamente e che gli enti UE devono darne priorità nella remediation, indipendentemente dal fatto che la scadenza formale riguardi solo le agenzie federali statunitensi.
La risposta di Metabase e le raccomandazioni per i team IT
Metabase ha seguito un percorso di risposta agli incidenti abbastanza standard per una vulnerabilità di questa gravità. Dopo aver ricevuto la segnalazione, l’azienda ha pubblicato in tempi rapidi l’advisory tecnica, ha rilasciato le versioni con patch per tutti i sei rami interessati e ha riconosciuto pubblicamente lo sfruttamento attivo, un passaggio non scontato ma importante per la trasparenza verso i clienti.
Le raccomandazioni operative per chi gestisce un’istanza Metabase self-hosted si possono riassumere in tre passaggi concreti, elencati in ordine di priorità:
- Aggiornare immediatamente alla versione con patch specifica per il proprio ramo (58.24, 59.21, 60.17, 61.11, 62.9 o 63.5), non a una versione generica successiva.
- Restringere l’accesso di rete all’istanza Metabase se l’aggiornamento non è immediatamente possibile, posizionandola dietro VPN, gateway SSO o firewall applicativo, invece di lasciarla raggiungibile direttamente da internet.
- Ruotare le credenziali di tutti i database e servizi esterni collegati a Metabase, dato che potrebbero essere già state esposte prima della scoperta della falla.
Un esempio concettuale di come i team di sicurezza possono verificare rapidamente la versione in esecuzione della propria istanza, senza eseguire alcuna azione offensiva, è interrogare l’endpoint pubblico di stato dell’applicazione:
curl -s https://tuo-metabase.esempio.it/api/health
curl -s https://tuo-metabase.esempio.it/api/session/properties | grep versionSe la versione restituita rientra in uno degli intervalli vulnerabili elencati nella prima tabella, l’aggiornamento va considerato urgente, non pianificabile per il prossimo ciclo di manutenzione.
Il contesto storico: da SQL injection “vecchio stile” a bersaglio delle piattaforme dati moderne
La SQL injection è una delle categorie di vulnerabilità più antiche nella sicurezza applicativa, presente stabilmente nella top ten OWASP fin dalle prime edizioni pubblicate oltre vent’anni fa. Ciò che rende CVE-2026-72898 significativa non è la tecnica in sé, ben nota e teoricamente prevenibile con controlli di validazione dell’input ormai considerati basilari, ma il contesto in cui compare: una piattaforma moderna, ampiamente adottata, che gestisce per definizione l’accesso centralizzato a molteplici fonti di dati sensibili.
Negli ultimi due anni gli attaccanti hanno progressivamente spostato l’attenzione dai singoli server verso gli “hub” applicativi, gli strumenti cioè che aggregano l’accesso a più sistemi contemporaneamente: gestori di CI/CD come TeamCity, piattaforme RMM come N-able N-central e ora strumenti di analytics come Metabase. La logica è la stessa che guida gli attacchi alla supply chain del software: compromettere un singolo punto centrale, moltiplicare l’impatto su decine o centinaia di sistemi collegati.
Impatto sul mercato della business intelligence open source
Metabase compete in un mercato affollato di strumenti di analytics self-service, dalle suite commerciali di grandi vendor alle alternative open source come Apache Superset e Redash. La sua forza competitiva è sempre stata la combinazione di gratuità, facilità d’installazione e curva di apprendimento contenuta, caratteristiche che l’hanno resa una scelta popolare tra le PMI europee che non possono permettersi licenze BI enterprise costose.
Una vulnerabilità di questa portata mette alla prova proprio quella proposta di valore. Le organizzazioni che avevano scelto Metabase per la sua semplicità dovranno ora considerare un costo aggiuntivo, non economico ma organizzativo: investire in patch management più rigoroso, segmentazione di rete e, in alcuni casi, una revisione complessiva di come vengono esposti gli strumenti interni su internet. Per i concorrenti diretti, l’episodio è un’occasione per enfatizzare i propri controlli di sicurezza, anche se nessuno strumento è immune da vulnerabilità simili nel lungo periodo.
Previsioni: cosa aspettarsi nei prossimi mesi
Sulla base del ritmo delle scoperte registrato nell’estate 2026 e delle dinamiche già visibili nel settore, ecco cinque previsioni ragionevoli per la seconda metà dell’anno.
- Altre piattaforme BI finiranno sotto la lente. Dopo Metabase, è probabile che i ricercatori di sicurezza intensifichino l’analisi di strumenti concorrenti come Apache Superset e Redash, alla ricerca di pattern simili negli endpoint di autenticazione e reset password.
- Il ritmo del catalogo KEV continuerà ad accelerare. Con 26 vulnerabilità aggiunte in quattro settimane tra luglio e agosto, il trend suggerisce che CISA manterrà un ritmo elevato di aggiornamenti almeno fino a fine 2026.
- Le PMI italiane resteranno bersaglio preferenziale. La combinazione di patch management debole e strumenti self-hosted esposti continuerà ad attirare gruppi di estorsione opportunisti, come già visto con le 15 rivendicazioni registrate a inizio agosto.
- Crescerà la domanda di strumenti automatici di monitoraggio del KEV. Più organizzazioni europee integreranno feed automatizzati del catalogo CISA nei propri processi di vulnerability management, anche al di fuori degli obblighi normativi statunitensi.
- La segmentazione di rete diventerà una priorità di audit. Gli assicuratori informatici e i revisori di conformità inizieranno a chiedere esplicitamente se gli strumenti BI interni sono raggiungibili direttamente da internet, non solo se sono aggiornati.
Come proteggere la tua organizzazione adesso
Al di là delle tre azioni immediate già descritte, un’organizzazione che vuole ridurre l’esposizione a vulnerabilità come CVE-2026-72898 nel tempo dovrebbe considerare alcune pratiche più strutturali. La prima è mappare tutti gli strumenti interni raggiungibili da internet, non solo quelli “ufficiali” gestiti dal reparto IT: molte istanze Metabase vulnerabili sono probabilmente installazioni “shadow IT” avviate da singoli team senza coinvolgere la sicurezza.
La seconda è adottare un principio di minimo privilegio anche per gli strumenti di analytics: un’istanza Metabase non dovrebbe mai avere credenziali con permessi di scrittura su database di produzione se il suo unico scopo è generare report in sola lettura. La terza, più a lungo termine, è integrare la scansione delle vulnerabilità note (KEV-aware) direttamente nella pipeline di deployment, così da bloccare automaticamente il rilascio di componenti con CVE critiche già note.
Approfondimenti correlati
- CISA KEV: 7 Falle Aggiunte, 5 Hanno Oltre 15 Anni [2026]
- CVE-2026-68820: Lazarus Colpisce la Difesa UE [2026]
- Italia Sotto Ransomware: 15 Vittime in 7 Giorni [2026]
- Zero-Day SonicWall SMA1000: 380 Appliance Esposte [2026]
- Breach LiteLLM: 153 GB di Credenziali Rubate [2026]
- OWASP Top 10 2025 vs API Security Top 10 [2026]
Domande frequenti
Cos’è esattamente CVE-2026-72898?
È una vulnerabilità critica di SQL injection non autenticata nell’endpoint /api/session/reset_password di Metabase, che permette a un attaccante remoto di ottenere accesso amministrativo completo all’istanza senza credenziali. Ha ricevuto il punteggio massimo di gravità, CVSS 10.0, ed è stata aggiunta al catalogo KEV di CISA l’11 agosto 2026.
Quali versioni di Metabase sono vulnerabili?
Tutte le versioni dei rami dalla 58.x alla 63.x precedenti alle build 58.24, 59.21, 60.17, 61.11, 62.9 e 63.5, sia nell’edizione open source sia in quella Enterprise. Le versioni antecedenti alla serie 58 non risultano interessate secondo l’advisory ufficiale.
La mia istanza è stata già compromessa?
Non esiste un modo semplice per saperlo con certezza a posteriori senza un’analisi forense dei log applicativi e del database. Chi gestisce un’istanza in una versione vulnerabile ed esposta a internet dovrebbe trattare la situazione come una possibile compromissione, verificare la presenza di utenti amministratore non riconosciuti e ruotare tutte le credenziali collegate per precauzione.
Devo aggiornare anche se il mio Metabase non è raggiungibile da internet?
Sì. Anche se il rischio immediato è più basso per le istanze accessibili solo dalla rete interna, la patch va comunque applicata, perché un attaccante che ottiene già un primo accesso alla rete aziendale (ad esempio tramite phishing) potrebbe sfruttare CVE-2026-72898 per muoversi lateralmente e ottenere privilegi più elevati.
Cosa rischia concretamente un’azienda italiana che usa Metabase?
Oltre al furto diretto di dati aziendali e credenziali, un’azienda italiana rischia possibili violazioni del GDPR se nelle dashboard compromesse sono presenti dati personali di clienti o dipendenti, con conseguenze sanzionatorie che il Garante Privacy ha già dimostrato di applicare concretamente, come nel caso della multa da 1,7 milioni di euro a WINDTRE per carenze di sicurezza analoghe.
Posso continuare a usare la versione cloud di Metabase in sicurezza?
La vulnerabilità descritta nell’advisory riguarda specificamente le installazioni self-hosted, gestite direttamente dall’organizzazione sul proprio server o infrastruttura cloud personale. Chi usa un servizio gestito dovrebbe comunque verificare con il proprio fornitore quale versione del motore Metabase sia in esecuzione e se sia già stata applicata la patch.
Cosa devo fare se non posso aggiornare subito?
Nell’immediato, isola l’istanza dietro una VPN o un gateway di autenticazione, rimuovendo l’esposizione diretta a internet. In parallelo, ruota tutte le credenziali dei database collegati e pianifica l’aggiornamento alla versione con patch nel più breve tempo possibile: si tratta di una misura temporanea, non di una soluzione definitiva.
Dove trovo l’advisory ufficiale e i dettagli tecnici completi?
L’advisory ufficiale è pubblicata sul repository GitHub di Metabase con identificativo GHSA-vwf4-m7j8-wcjf, mentre la scheda tecnica ufficiale è consultabile sul National Vulnerability Database statunitense e sul catalogo KEV di CISA, entrambi linkati in questo articolo.
