Exploit para GeoServer analizado públicamente en 48 horas: ¿quién cerrará la vulnerabilidad antes, los administradores o los atacantes?

En GeoServer se detectó una vulnerabilidad crítica, que empezaron a comprobar en sistemas reales apenas unas horas después de publicarse las primeras informaciones. El fallo permite inyectar comandos en las consultas a la base de datos sin autenticación y, con una configuración insegura de PostgreSQL, puede llevar a la ejecución de comandos en el sistema operativo.

El problema fue revelado el 12 de agosto de 2026 por un especialista bajo el seudónimo @q1uf3ng. Posteriormente, otros especialistas analizaron de forma independiente el mecanismo de la vulnerabilidad y confirmaron la posibilidad de explotación. Al concluir el análisis el 14 de agosto no existía una corrección oficial para GeoServer.

GeoServer es un servidor de código abierto para publicar datos geográficos. Lo utilizan organismos estatales, servicios municipales, contratistas del sector defensa, proyectos medioambientales y otras organizaciones que necesitan servicios cartográficos públicos. Muchos de esos servidores aceptan solicitudes de usuarios sin autenticación, por lo que el fallo afecta a sistemas accesibles directamente desde internet.

La vulnerabilidad no está en el propio procesador de mapas, sino en la biblioteca GeoTools, de la que depende GeoServer. El código problemático convierte filtros CQL en consultas a PostgreSQL y PostGIS. La función jsonArrayContains inserta el valor recibido del usuario en la consulta SQL sin un tratamiento adecuado de los caracteres especiales.

Como resultado, un atacante puede alterar la estructura de la consulta a la base de datos. Para explotar la vulnerabilidad se requiere un servidor GeoServer con una versión vulnerable de GeoTools, una capa de datos basada en PostGIS, PostgreSQL versión 12 o posterior y acceso a las interfaces WFS o WMS correspondientes.

Los especialistas determinaron que las consecuencias dependen de la versión del protocolo y de la estructura de la consulta. WFS 2.0 genera una consulta anidada adicional que impide uno de los escenarios más peligrosos. En WFS 1.0 no existe esa envoltura, por lo que la consulta inyectada puede ejecutarse a nivel superior.

La variante más grave es posible si GeoServer se conecta a PostgreSQL con derechos de superusuario o con una cuenta que tenga el permiso pg_execute_server_program. En tal caso, una inyección SQL puede provocar la ejecución de comandos en el sistema operativo del servidor de base de datos.

Los privilegios limitados de PostgreSQL reducen el daño, pero no eliminan la vulnerabilidad. Un atacante aún puede obtener los datos a los que tiene acceso la cuenta de GeoServer, incluido el contenido de las tablas, información de servicio y otros datos de la base.

El código problemático apareció en GeoTools en el marco del cambio GEOT-7589 y se introdujo en varias ramas del proyecto. Según los autores del análisis, las versiones vulnerables de GeoServer podrían comenzar en la 2.25.3 con la configuración correspondiente de PostGIS.

Antes de que haya una corrección, se recomienda a los administradores restringir el acceso a WFS y WMS desde redes no confiables, revisar la configuración de PostGIS y desactivar la conversión de funciones a SQL si esa funcionalidad no es necesaria. También deben comprobar que GeoServer no se conecte a PostgreSQL con derechos de superusuario ni tenga el permiso pg_execute_server_program.