GeoNetwork heeft twee kwetsbaarheden gerepareerd die samen kunnen worden misbruikt tot een unauthenticated RCE-keten. De impact is groot, omdat GeoNetwork een open-source catalogus voor geospatiale metadata is en achter veel geoportalen van overheden en agentschappen draait.
Volgens de bevindingen kan een aanvaller zonder authenticatie eerst schadelijke formatterbestanden uploaden en vervolgens via een tweede component code laten uitvoeren op de server. De projectupdate verscheen op 8 juli 2026 (versies 4.4.12 en 4.2.17), terwijl de details op 31 augustus werden gepubliceerd.
Wat is de unauthenticated RCE-keten bij GeoNetwork?
De kern van de aanval zit in een samenloop van twee fouten. De eerste kwetsbaarheid mist een autorisatiecontrole op een endpoint waar formatters worden geüpload. Daardoor krijgt een anonieme gebruiker de mogelijkheid om bestanden naar een formatterdirectory van GeoNetwork te schrijven.
De tweede kwetsbaarheid betreft een onveilige configuratie van de Saxon XSLT-transformaties-engine. Die engine is bedoeld om formatters te renderen, maar in deze situatie kan een stylesheet (die via de upload-route binnenkomt) instructies uitvoeren waarmee uiteindelijk OS-commando’s worden gestart.
Belangrijk: elk probleem afzonderlijk kent voorwaarden. De XSLT-engine vereist normaal gesproken privileges om een formatter te kunnen uploaden. Door de uploadfout te combineren met de onveilige rendering ontstaat de unauthenticated RCE-keten: de voorwaarde valt weg, omdat de upload zelf zonder authenticatie bereikbaar is.
De kwetsbaarheden op een rij (CVE’s en impact)
CVE-2026-63219: ontbrekende autorisatie bij formatter upload
De eerste bug, CVE-2026-63219 (CVSS 8,6), is een missing authorization check op het formatter-uploadendpoint. Het gevolg: een aanvaller kan als anonieme gebruiker arbitraire formatterbestanden uploaden met extensies .xsl of .zip naar de GeoNetwork formatterdirectory.
Op zichzelf is dit al ongewenst, omdat het neerkomt op ongeautoriseerde schrijfrechten op serveropslag. De projectadvisory omschrijft dit expliciet als het uploaden van willekeurige stylesheet- of pakketbestanden naar de server.
CVE-2026-58400: onveilige Saxon XSLT-transformaties
De tweede issue, CVE-2026-58400 (CVSS 9,1), gaat over de manier waarop de Saxon XSLT-processor is ingesteld voor het verwerken van formatters. In de beschreven configuratie staat de verwerking wel op “secure processing”, maar Java extension functies zijn uitgeschakeld—waardoor de stylesheet alsnog kan leiden tot het aanroepen van runtime- en procesfuncties zoals java.lang.Runtime.exec() of java.lang.ProcessBuilder.
Hierdoor kan de stylesheet OS-commando’s laten uitvoeren onder de gebruiker waaronder GeoNetwork draait. Dit is de stap die het uiteindelijk tot RCE maakt zodra een aanvaller een kwaadaardige stylesheet kan leveren via de eerste fout.
Hoe werkt de aanval in de praktijk?
Uit de analyse volgt een scenario met twee stappen. Eerst uploadt de aanvaller een malafide formatterbestand via het onbeschermde uploadendpoint. Daarna triggerde men een verwerking door een openbare record te benaderen.
Concreet wordt er een GET-verzoek gedaan naar een public record, waarna GeoNetwork de Saxon-engine inzet om de formatter te laden en uit te voeren. In die renderstap komt de stylesheet tot leven en vindt de code-executie plaats.
Bereikbaarheid vanaf GeoNetwork 4.0.6
Beveiligingsonderzoeker Ethiack (met rapportage door Rafael Castilho) stelt dat de keten te bereiken is vanaf versie 4.0.6. In die periode werd de formatter-endpoint refactor uitgevoerd en werd een autorisatielijn weggehaald, waardoor de upload-route anoniem bereikbaar werd.
Welke GeoNetwork-versies zijn getroffen?
De kwetsbaarheden raken niet alleen één release, maar meerdere minor versies binnen 4.4.x en 4.2.x. Het project geeft aan dat:
- Alle 4.4.x releases t/m 4.4.11 kwetsbaar zijn.
- Alle 4.2.x releases t/m 4.2.16 kwetsbaar zijn.
De fix zit in:
- 4.4.12
- 4.2.17
GeoNetwork moedigt beheerders aan om zo snel mogelijk te upgraden naar 4.4.12 of 4.2.17.
Impact op exposed deployments: wat zegt Ethiack?
Ethiack rapporteert dat er 121 internet-exposed GeoNetwork-installaties zijn teruggevonden met versies die getroffen zijn, verspreid over 39 landen. Het gaat om fingerprinting van blootgestelde instanties, niet om bevestigde slachtoffers of vastgestelde compromissen.
Van die blootgestelde deployments zou 89% gelinkt zijn aan overheid, militaire of nationale agentschappen. De cijfers zijn volgens de bron single-sourced aan de vendor en beschrijven dus vooral blootstelling door bereikbaar verkeer.
Wat kun je nu doen als je niet meteen kunt upgraden?
Als patching nog niet meteen mogelijk is, adviseert het project om tijdelijke mitigaties door te voeren bij de reverse proxy. Daarbij wordt de mogelijkheid beperkt om formatterupload-methoden toe te staan op de formatterlocatie.
Apache httpd: methoden blokkeren
Voor Apache httpd geldt volgens de interimregels: deny POST, PUT en PATCH requests naar de locatie /geonetwork/srv/api/formatters.
Nginx: alleen veilige methoden toestaan
Bij Nginx wordt dezelfde locatie beperkt tot GET, HEAD en OPTIONS. Zo voorkom je dat uploads (waar de keten mee begint) via de omweg naar de server plaatsvinden.
Let op: deze maatregelen blokkeren niet alleen “kwaadwillende” traffic, maar ook legitieme formatteruploads via de admin console. Het doel is dus vooral om het risico tijdelijk te verlagen tot je een upgrade kunt plannen.
Waarom dit soort ketenaanvallen extra aandacht vraagt
Deze case laat duidelijk zien hoe één zwakke plek op zich soms “net niet” genoeg is voor directe code-executie, maar dat een tweede fout het pad opent. In software waarin extensie- of transformatiefunctionaliteit aanwezig is (zoals XSLT rendering) kan een onjuiste configuratie snel leiden tot vergaande gevolgen zodra een aanvaller content kan aanleveren.
Voor organisaties die geoportalen of andere metadata-omgevingen draaien, is dit een extra reden om niet alleen naar kwetsbaarheden los te kijken, maar ook naar combinaties: bereikbaarheid, authenticatie/autoristatie en de uitvoering van content op de server.
Vergelijkbare beveiligingsrisico’s: supply chain en uitvoeringspaden
Hoewel GeoNetwork een eigen domein heeft, passen de lessen bij bredere patronen in beveiliging. Denk aan scenario’s waarin aanvallers via onbedoelde paden code kunnen laten draaien—bijvoorbeeld wanneer build- of runtime-omgevingen worden misbruikt of updates op het verkeerde moment worden uitgeschakeld.
Als je meer wilt lezen over het risico van misbruikbare configuraties en uitvoeringslogica, is dit artikel relevant: Git-config misbruikt om AI-agent code te laten draaien. Ook daar gaat het om hoe een keten van kleine fouten een groot effect kan krijgen.
Daarnaast kun je achtergrond over het beveiligen van geavanceerde agent- en runtime-achtige flows gebruiken als extra kader: AI agent controle.
Conclusie: upgrade GeoNetwork om de RCE-keten te stoppen
GeoNetwork heeft een unauthenticated RCE-keten verholpen door fixes in 4.4.12 en 4.2.17. De aanval combineert een ontbrekende autorisatiecontrole bij formatteruploads (CVE-2026-63219) met een onveilige Saxon XSLT-transformatiesetup (CVE-2026-58400).
Omdat aanvallen zonder authenticatie kunnen starten en de keten via een publieke trigger kan worden doorgezet, is de veiligste route: upgrade. Lukt dat niet direct, gebruik dan de reverse-proxy mitigaties om formatterupload-methoden te blokkeren totdat de patch is geïmplementeerd.
Bron: https://thehackernews.com/2026/09/geonetwork-fixes-unauthenticated-rce.html
