GeoServer zero-day sotto tiro: centinaia di exploit in ore, patch rilasciate

Una vulnerabilità zero-day in GeoServer, divulgata pubblicamente il 12 agosto 2026, ha generato centinaia di tentativi di exploit da una ristretta pool di indirizzi IP nel giro di poche ore. Il difetto, una SQL injection nella funzione jsonArrayContains, consente l'esecuzione di codice remoto quando il server applicativo si connette a PostgreSQL con privilegi elevati. I maintainer del progetto hanno rilasciato le versioni corrette 3.0.1, 2.28.5 e 2.27.6 dopo il disclosure iniziale.

Il disclosure e la corsa all'exploit

Alle 10:46 UTC del 12 agosto 2026, il ricercatore @q1uf3ng ha pubblicato su X i dettagli della vulnerabilità. La divulgazione ha innescato immediatamente attività di sfruttamento.

Jake Knott, principal security researcher di watchTowr, ha dichiarato: "Within hours of public disclosure, we began observing exploitation attempts and have since recorded hundreds of attempts originating from a small number of source IP addresses". La stessa fonte riporta che gli aggressori stanno attualmente sondando per identificare sistemi vulnerabili, generando errori di server senza procedere oltre la fase di ricognizione.

Knott ha aggiunto: "Currently, we're seeing attackers probe to identify vulnerable systems across the internet, triggering errors and not proceeding further". Tuttavia, ha anche sottolineato che "this is unlikely to remain the case for long: GeoServer has a track record of being targeted and exploited at scale, with multiple vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog".

Il ritmo di weaponizzazione conferma un pattern consolidato per il software geospaziale. GeoServer è stato bersaglio di exploitation a scala negli anni precedenti. Il rischio di transizione da ricognizione a compromissione effettiva rimane elevato, considerando la tipologia di deployment del software in settori sensibili.

Meccanismo tecnico: da SQL injection a RCE condizionata

La vulnerabilità risiede nel package Maven org.geotools:gt-jdbc-postgis, nella funzione jsonArrayContains del filtro OGC. Secondo Melvin Lammerts di Hadrian, citato nella fonte primaria, "An attacker-controlled value is interpolated directly into a PostgreSQL jsonb_path_exists() expression without escaping". Questo consente l'iniezione arbitraria di istruzioni SQL.

L'escalation a esecuzione di codice remoto è subordinata a una condizione di configurazione specifica. Il server GeoServer deve connettersi a PostgreSQL utilizzando un account superuser o un ruolo dotato del privilegio pg_execute_server_program. In questa configurazione, secondo Lammerts, "this escalates to OS command execution on the database host".

Senza privilegi elevati, il bug resta SQL injection senza percorso documentato verso il sistema operativo sottostante. La fonte specifica che il vettore WFS 1.0 fornisce un path per l'esecuzione di una seconda istruzione. Il componente vulnerabile richiede PostGIS 12 o successivo con campo di tipo String o JSON.

La regressione di CVE-2023-25158

Un aspetto rilevante emerge dalla classificazione stessa dei maintainer: il bug è una regressione di CVE-2023-25158, una SQL injection con identico punteggio CVSS 9.8 corretta nel 2023 nella medesima classe di componenti GeoTools per il trattamento JDBC dei filtri OGC.

La ricomparsa di una vulnerabilità identica in funzionalità aggiuntive successive solleva interrogativi sulla copertura dei test di sicurezza regressivi nel ciclo di sviluppo di GeoServer e GeoTools. Il progetto ha assegnato l'identificatore GHSA-mqjf-5f49-2fjh al problema. Nessun CVE risulta menzionato nelle fonti disponibili al momento della verifica.

"GeoServer jsonArrayContains unauthorized SQL injection, and in the case of the sa [system administrator] database, it's naturally possible to achieve RCE" — @q1uf3ng, disclosure originale

Cosa fare adesso

• Applicare immediatamente le patch rilasciate: versioni 3.0.1, 2.28.5 e 2.27.6, secondo le release notes ufficiali citate nelle fonti.
• Identificare le istanze GeoServer esposte su internet: la superficie di attacco include deployment governativi, infrastrutture critiche, agricoltura, telecomunicazioni e trasporti.
• Ridurre l'esposizione di rete: per le istanze non aggiornabili tempestivamente, limitare l'accesso ai soli endpoint autorizzati in attesa di patching.
• Verificare i privilegi di connessione PostgreSQL: assicurarsi che l'utenza utilizzata da GeoServer non disponga di superuser o pg_execute_server_program se non strettamente necessario.

Lettura: quando la memoria breve del codice diventa debito tecnico di sicurezza

La regressione documentata non è un malfunzionamento isolato: indica un deficit sistematico nella tracciabilità delle vulnerabilità attraverso l'evoluzione del codebase. GeoServer, per la sua ubiquità nei sistemi informativi territoriali e governativi, accumula rischio in modo non lineare. Ogni nuova funzione che replica pattern JDBC senza ereditare le sanificazioni precedenti ricostruisce lo stesso ponte di attacco.

La rapidità di weaponizzazione—ore, non giorni—impone agli operatori di infrastruttura un margine di reazione estremamente compresso. L'assenza di un CVE assegnato al momento del disclosure non ha rallentato gli aggressori, evidenziando come la visibilità pubblica del difetto bastasse a innescare la catena.

Per le organizzazioni con istanze in ambienti sensibili, la priorità è duplice: applicare le patch disponibili e verificare che le configurazioni di connessione al database non amplifichino il rischio attraverso privilegi eccessivi. La finestra di esposizione resta aperta per chi non agisce con la stessa velocità degli aggressori.