Angrepsforsøk mot GeoServer startet timer etter at feilen ble offentlig kjent

En sårbarhet i GeoServer ble offentliggjort av forskeren q1uf3ng på X onsdag 12. august 2026, før prosjektet selv var klart med en rettelse. Sikkerhetsselskapet watchTowr oppgir at utnyttelsesforsøk startet innen timer, og at selskapet siden har registrert hundrevis av forsøk fra et lite antall avsenderadresser. GeoServer beskriver feilen som en SQL-injeksjon vurdert til høy alvorlighetsgrad, og oppgir at den krever en tekst- eller JSON-kolonne og rammer PostGIS fra versjon 12 og oppover. Rettelsen kom i GeoServer 3.0.1 den 14. august. Sårbarheten har foreløpig ikke fått noe CVE-nummer.

Hva som skjer teknisk

GeoServer er en åpen tjener for å publisere og dele geografiske data over nett, og den brukes blant annet i offentlig forvaltning, landbruk, telekom og samferdsel. Feilen ligger i filterfunksjonen jsonArrayContains, som brukes til å slå opp om et JSON-felt inneholder en bestemt verdi. Funksjonen kan brukes mot datakilder i PostGIS og Oracle JDBC. Ifølge omtalen hos SecurityWeek oppstår injeksjonen sannsynligvis fordi argumenter fra brukeren ikke blir tilstrekkelig renset før de settes inn i databasespørringen.

Her går kildene fra hverandre, og det er verdt å merke seg. GeoServer klassifiserer selv feilen som SQL-injeksjon, altså at en angriper kan påvirke spørringen som sendes til databasen. SecurityWeek og watchTowr beskriver at den under visse oppsett kan føre helt til kjøring av kode på tjeneren. Forskjellen mellom de to er stor i praksis, og hvilken av dem som gjelder for din installasjon avhenger av hvordan databasen og rettighetene er satt opp. Prosjektets egen beskrivelse er den snevreste, og den er samtidig den eneste som kommer fra dem som har lest koden.

Det watchTowr faktisk har observert, er avgrenset. Jake Knott i selskapet oppgir at forsøkene så langt går ut på å undersøke om systemer er sårbare, og at det ikke er sett videre aktivitet etterpå. Han peker samtidig på at GeoServer har vært et mål før, og at flere GeoServer-sårbarheter allerede står i CISAs katalog over utnyttede sårbarheter. Fraværet av videre aktivitet i dag er derfor ikke et argument for å vente. Rettelsen ligger i GeoServer 3.0.1, som ble gitt ut sammen med GeoTools 35.1 og GeoWebCache 2.0.1.

Hva det betyr for deg som drifter GeoServer selv

Har du GeoServer stående, er tidslinjen her det du bør ta med deg. Det gikk to dager fra feilen ble kjent til rettelsen forelå, og forsøkene kom innen timer. Det betyr at det ikke fantes noe vedlikeholdsvindu å planlegge i. Vår vurdering er at spørsmålet du kan gjøre noe med, er om instansen i det hele tatt skal svare på internett. En GeoServer som bare betjener interne kart trenger sjelden å være åpen for alle, og det er den avgjørelsen som avgjorde hvem som ble skannet i forrige uke.

Det er også en praktisk felle her som er lett å gå i. Sårbarheten har ennå ikke noe CVE-nummer, og verktøy som sporer sårbarheter på CVE-nummer vil derfor ikke vise den. Har du en oversikt som bygger på CVE alene, står denne saken ikke i den, uansett hvor eksponert du er. Vår vurdering er at slike saker må kunne føres inn manuelt, ellers har du en oversikt som er stille om nettopp de feilene som utnyttes raskest. Etter NIS2 artikkel 21 hører dette til håndtering av sårbarheter, og et sporingssystem som bare kjenner CVE-nummer oppfyller ikke kravet alene.

Berigo anbefaler

• Oppdater til GeoServer 3.0.1, som kom 14. august og retter feilen.
• Undersøk om GeoServer-instansen svarer på internett, og steng den ute dersom den ikke må være åpen.
• Let i loggene etter forespørsler som bruker filterfunksjonen jsonArrayContains, og etter databasespørringer du ikke kjenner igjen.
• Kontroller om datakilden er PostGIS versjon 12 eller nyere, og om laget bruker tekst- eller JSON-kolonner, siden det er der feilen slår ut.
• Før saken inn i sårbarhetsoversikten manuelt, slik at den ikke faller ut fordi den mangler CVE-nummer.