Zero-day di GeoServer già sfruttata: la falla può portare alla RCE

Sfruttamento iniziato poche ore dopo la divulgazione

Una vulnerabilità zero-day non corretta di GeoServer è già oggetto di attività ostili. WatchTowr ha rilevato il fenomeno il 14 agosto 2026, poche ore dopo la divulgazione pubblica del difetto da parte del ricercatore q1uf3ng, attraverso un post su X.

Gli attaccanti hanno avviato scansioni e tentativi di sfruttamento quasi subito dopo la pubblicazione. WatchTowr riferisce di aver osservato centinaia di richieste provenienti da un numero limitato di indirizzi IP sorgente.

Finora il comportamento rilevato è riconducibile al sondaggio di sistemi potenzialmente vulnerabili. Non risultano compromissioni confermate, persistenza, movimento laterale o sottrazione di dati. L’assenza di queste evidenze, tuttavia, non riduce la priorità per le organizzazioni che espongono GeoServer su Internet.

La vulnerabilità non dispone ancora di una patch del vendor. Non sono stati inoltre comunicati un identificativo CVE, una versione specifica interessata o payload completi utilizzati dagli aggressori.

Il difetto riguarda i filtri JSON e può trasformarsi in RCE

Il problema interessa la funzione jsonArrayContains, un’espressione filtro di GeoServer utilizzata per interrogare campi JSON che contengono array. Il suo scopo è verificare se un determinato valore sia presente all’interno di questi insiemi di dati.

Secondo la descrizione tecnica disponibile, gli argomenti controllati dall’utente non verrebbero validati o sanificati in modo sufficiente prima di essere inseriti nelle query destinate al database. In condizioni specifiche, un aggressore può quindi tentare di manipolare la query attraverso una SQL injection.

Il difetto coinvolge i datastore basati su PostGIS e Oracle JDBC. La riuscita dell’attacco dipende dalla configurazione dell’istanza, dai permessi assegnati al servizio e dal modo in cui GeoServer comunica con il database.

Il rischio non si limita all’accesso o alla manipolazione delle informazioni archiviate. In determinati scenari, la SQL injection può diventare il punto di partenza per l’esecuzione di codice da remoto, consentendo all’attaccante di eseguire comandi sul sistema che ospita GeoServer.

Non è noto se tutti gli ambienti che utilizzano PostGIS o Oracle JDBC siano esposti allo stesso modo. Servono quindi una valutazione della configurazione locale e indicazioni ufficiali del progetto per stabilire con precisione l’insieme delle installazioni vulnerabili.

Perché GeoServer è un bersaglio rilevante

GeoServer è una piattaforma open source per pubblicare, condividere ed elaborare dati geospaziali. Le sue interfacce possono fornire accesso a informazioni cartografiche e territoriali, oltre a collegarsi a database utilizzati da applicazioni operative.

Il prodotto è adottato da organizzazioni governative e da aziende nei settori agricolo, delle telecomunicazioni e dei trasporti. Una compromissione può quindi avere conseguenze diverse in base al ruolo dell’istanza: dalla modifica dei dati geospaziali fino all’accesso al server e alle reti collegate.

L’impatto concreto dipende soprattutto dai privilegi del processo GeoServer. Un servizio eseguito con autorizzazioni eccessive potrebbe offrire all’attaccante maggiori possibilità di lettura, modifica o esecuzione. Anche la connettività verso i datastore è determinante: un server capace di raggiungere direttamente database sensibili amplia la superficie di attacco.

WatchTowr considera improbabile che il semplice probing rimanga l’unica attività a lungo. GeoServer ha già attirato campagne di sfruttamento su larga scala, e la disponibilità pubblica di dettagli tecnici può accelerare la trasformazione della falla in strumenti automatizzati.

Il precedente delle vulnerabilità già sfruttate

Diverse vulnerabilità di GeoServer risultano incluse nel catalogo Known Exploited Vulnerabilities (KEV) della CISA. Questo elemento colloca il nuovo episodio in una storia di difetti del prodotto già sfruttati concretamente dagli attaccanti, invece di trattarlo come un rischio puramente teorico.

La presenza nel KEV riguarda vulnerabilità precedenti e non implica, sulla base delle informazioni disponibili, che questa falla sia già stata inserita nello stesso catalogo. Non sono noti per il nuovo difetto né la data di un’eventuale inclusione né una scadenza di remediation stabilita dalla CISA.

Il dato più urgente resta comunque lo sfruttamento osservato poco dopo la divulgazione. In questo caso la distanza tra pubblicazione delle informazioni e attività ostile è stata ridotta a poche ore.

Cosa devono fare gli amministratori

In assenza di una correzione, le organizzazioni dovrebbero partire dall’inventario delle installazioni GeoServer. Occorre individuare le istanze raggiungibili da Internet, verificare quali espongano funzionalità di interrogazione e stabilire quali utilizzino datastore PostGIS o Oracle JDBC.

Quando l’accesso pubblico non è indispensabile, la misura più efficace consiste nel limitarlo o rimuoverlo. Le interfacce possono essere rese disponibili soltanto attraverso reti interne, VPN o sistemi di accesso controllato. Firewall e segmentazione dovrebbero inoltre impedire a GeoServer di raggiungere senza necessità database e sistemi non correlati.

La patch ufficiale dovrà essere installata non appena sarà pubblicata. Al momento non è indicata una versione corretta e non è disponibile un workaround specifico che elimini il difetto alla fonte.

Nel frattempo, i team di sicurezza dovrebbero esaminare:

• log applicativi e del web server relativi a richieste verso jsonArrayContains;
• parametri anomali o compatibili con tentativi di SQL injection;
• connessioni provenienti dagli indirizzi IP osservati da WatchTowr;
• query insolite nei database PostGIS e Oracle;
• errori inattesi generati da GeoServer;
• nuove connessioni in uscita dal server verso infrastrutture esterne.

L’analisi non dovrebbe fermarsi alla ricerca del probing. È necessario verificare eventuali comandi eseguiti sul sistema, account creati o modificati, alterazioni dei dati geospaziali, accessi anomali ai database e cambiamenti nella configurazione del servizio.

Se vengono rilevate attività successive alla scansione, l’istanza dovrebbe essere isolata e sottoposta a un’indagine completa. La sola presenza di richieste sospette non dimostra una compromissione, ma una catena composta da SQL injection, comandi remoti o comunicazioni verso l’esterno richiede una risposta da incidente di sicurezza.