Une zero-day SQL non corrigée dans GeoServer est déjà sondée par les attaquants
Révélée le 12 août 2026, une injection SQL non authentifiée dans la fonction jsonArrayContains de GeoServer peut mener à une exécution de code à distance, et aucune rustine n’est encore publiée. Les attaquants sondent déjà les instances exposées : isolez-les avant le correctif.
12 août 2026. Un chercheur publie une zero-day sur X. Quelques heures plus tard, des centaines de sondes atteignent des instances GeoServer exposées. À ce jour, aucune rustine n’est publiée et aucun CVE n’a encore été attribué.
C’est le scénario que tout RSSI redoute : une faille rendue publique avant qu’un correctif n’existe, et des attaquants qui n’attendent pas. La faille touche GeoServer, le serveur géospatial open source, et elle permet une exécution de code à distance dans certaines configurations.
Une injection SQL non authentifiée dans jsonArrayContains
La vulnérabilité, divulguée par le chercheur @q1uf3ng le 12 août 2026, se situe dans la fonction jsonArrayContains de GeoServer. Elle autorise une injection SQL non authentifiée : un attaquant peut faire exécuter au serveur des requêtes SQL arbitraires sans disposer du moindre compte.
La gravité tient à un enchaînement précis. Lorsque l’instance est connectée à une base de données via un compte privilégié — le compte administrateur « sa », super-utilisateur par défaut de bases comme H2 ou SQL Server — l’injection SQL bascule vers une exécution de code à distance complète. Le serveur devient alors un point d’ancrage vers les données géographiques, les services en amont et le reste du réseau.
GeoServer n’est pas un logiciel anecdotique. Il publie et partage des données géospatiales via des services web (WMS, WFS), et on le trouve dans les portails du secteur public, les plateformes environnementales, les projets de cartographie, les régies d’eau et d’énergie, les systèmes de transport et des applications métier internes. Une instance joignable depuis Internet expose donc rarement un simple serveur de cartes — elle expose des données, des identifiants et parfois une route vers un réseau plus large.
Déjà sondée : la reconnaissance précède l’exploitation
watchTowr a documenté la chronologie, et elle est serrée. « Dans les heures qui ont suivi la divulgation publique, nous avons commencé à observer des tentatives d’exploitation, et avons depuis enregistré des centaines de tentatives provenant d’un petit nombre d’adresses IP », explique Jake Knott, chercheur chez watchTowr.
Pour l’instant, ces tentatives restent de la reconnaissance : les attaquants déclenchent des erreurs sur les instances vulnérables et comparent les réponses pour dresser la liste des cibles à exploiter plus tard. Aucune exploitation en profondeur n’a encore été observée — mais Knott prévient que cela ne durera pas : GeoServer « a l’habitude d’être ciblé et exploité à grande échelle ».
Le précédent est documenté. En 2024, la faille critique CVE-2024-36401 dans la bibliothèque GeoTools sous-jacente — un score CVSS de 9,8 — avait été exploitée pour enrôler des serveurs GeoServer dans des botnets DDoS, des opérations de minage de cryptomonnaie et des réseaux de proxy résidentiels. Plusieurs vulnérabilités GeoServer figurent d’ailleurs au catalogue KEV de la CISA. L’histoire ne garantit pas que chaque instance exposée sera compromise cette fois, mais elle rend la complaisance difficile à défendre.
Des données géospatiales, donc une cible critique
Le point aveugle de cet incident, c’est la nature des données. GeoServer sert de la donnée géographique : tracés de réseaux, emprises, plans de bâtiments, zonages, capteurs. Ce sont exactement les données qui intéressent un attaquant préparant une opération physique, un ciblage d’infrastructure ou une simple revente.
Une instance GeoServer exposée cumule trois problèmes. Elle est souvent mal inventoriée — déployée par un service métier ou un prestataire, hors du périmètre officiel. Elle est souvent sous-patchée, car perçue comme un outil interne et non comme un actif d’infrastructure. Et elle est souvent sur-privilégiée, connectée à une base avec un compte large pour simplifier l’administration. Cette combinaison est précisément ce que l’injection jsonArrayContains transforme en RCE.
Que faire quand il n’y a pas de correctif
L’absence de rustine change la réponse habituelle. On ne peut pas « programmer une mise à jour et passer à autre chose ». Le travail, ici, est de réduire l’exposition et de préparer le correctif.
Trois actions s’imposent. Inventorier d’abord : recensez toutes les instances GeoServer — elles vivent parfois hors du périmètre officiel, dans un service métier ou un laboratoire. Restreindre ensuite : placez l’instance derrière un VPN, un reverse proxy, une liste blanche d’IP ou toute couche de contrôle d’accès si le service n’a pas besoin d’être public. Surveiller enfin : inspectez les journaux à la recherche de sondes d’injection SQL et d’erreurs de base de données inhabituelles.
# Détecter les sondes d'injection SQL dans les logs d'accès du frontal web
grep -iE "jsonArrayContains|union select|pg_sleep|sleep\(" /var/log/nginx/access.log /var/log/apache2/access.log 2>/dev/nullSur les instances qui doivent rester publiques, réduisez au minimum les privilèges du compte de base de données utilisé par l’application : c’est précisément la présence d’un compte « sa » qui transforme l’injection SQL en exécution de code. Un compte limité en lecture seule, sans privilège d’écriture ni de commande, ne neutralise pas la faille, mais il casse la chaîne qui mène au RCE.
La mécanique de l’injection : une concaténation non neutralisée
La fonction jsonArrayContains sert aux filtres CQL que GeoServer applique aux couches cartographiques : elle vérifie si une valeur appartient à un tableau JSON. Son implémentation assemble des fragments de requête SQL à partir de paramètres fournis par l’utilisateur sans les neutraliser correctement — le schéma exact de toute injection SQL. Une requête forgée fait donc exécuter au serveur, au nom de son compte de base de données, du SQL que le développeur n’a jamais prévu.
La conséquence opérationnelle est simple : tant qu’aucune rustine n’existe, le pare-feu applicatif (WAF) et la détection d’anomalies SQL sont vos deux seuls filets. Un WAF bien réglé bloque les signatures d’injection classiques, mais il rate les variantes ; la détection dans les journaux de base de données remonte, elle, les requêtes anormales déjà exécutées. Les deux se complètent, aucun ne remplace l’isolation de l’instance.
# Repérer les requêtes SQL anormales dans les journaux de la base
grep -iE "jsonArrayContains|pg_sleep|information_schema" /var/log/postgresql/*.log 2>/dev/nullUne requête pg_sleep ou information_schema que vous n’avez pas émise est le signe le plus net qu’une sonde d’injection a déjà atteint la base.
L’enjeu dépasse la technique : le calendrier réglementaire
Pour les opérateurs concernés par NIS2, l’incident touche un point sensible : la plateforme géospatiale d’une entité essentielle est un système d’information critique au sens de la directive. Une exploitation réussie d’une zero-day sur ce périmètre est un incident significatif — alerte précoce sous 24 heures, rapport détaillé sous 72 heures. L’isolation préventive n’est donc pas qu’une mesure technique : c’est aussi une protection contre la chaîne de reporting qui s’enclenche.
Trouver sa propre exposition avant les attaquants
Reste une étape qui n’attend pas la rustine : trouver votre propre exposition avant qu’un attaquant ne le fasse. Les sondes observées par watchTowr proviennent d’un petit nombre d’adresses — le profil d’une reconnaissance méthodique, pas d’un balayage aléatoire. Vérifiez donc vous-même si vos points de terminaison WMS/WFS et l’interface d’administration /geoserver/web/ sont joignables depuis Internet. Toute instance joignable atterrira sur la liste d’un attaquant en quelques jours ; si vous ne pouvez pas citer toutes vos instances GeoServer aujourd’hui, ce trou-là est votre vraie exposition, avant même la rustine manquante.
Verdict
Si vous exploitez GeoServer et qu’il n’a aucune raison d’être public, isolez-le immédiatement derrière un accès contrôlé — c’est la mesure qui rapporte le plus, et elle est réversible quand la rustine arrivera.
Si une exposition publique est inévitable, traitez-la comme une exception à haut risque : listez l’instance, surveillez ses journaux en continu, réduisez les privilèges de son compte de base de données et tenez-vous prêt à appliquer le correctif OSGeo dès sa publication.
Le signal de fond, au-delà de GeoServer, est la vitesse de la fenêtre : une zero-day devient exploitable dans les heures qui suivent sa divulgation. Votre capacité à isoler une instance en quelques heures vaut désormais plus que votre calendrier de correctifs.