CVE-2025-1094 en PostgreSQL: cuándo una función de escape puede permitir SQL injection
Publicado el 2026-10-27 por frfrand
Explicamos el caso de SQL injection en funciones de escape de PostgreSQL, alcance preciso, versiones corregidas y mitigaciones.
El problema que nadie esperaba de una función de seguridad
En una base de datos solemos confiar en las funciones que preparan caracteres especiales para una consulta. Pero CVE-2025-1094, corregida en febrero de 2025, demostró que incluso esas defensas necesitan contexto. El problema afectó determinadas funciones de escape de la biblioteca cliente libpq y herramientas de línea de comandos de PostgreSQL. Bajo combinaciones específicas de entradas y codificaciones, un texto supuestamente preparado podía terminar alterando una instrucción SQL.
¿Qué es SQL injection y por qué preocupa?
La inyección SQL ocurre cuando datos externos se interpretan como parte de una orden enviada a la base. Dependiendo de los privilegios, puede modificar registros, leer información o alterar el comportamiento de una tarea. No toda SQL injection concede control total: los resultados dependen de qué consulta se construye y con qué usuario se ejecuta.
¿Qué corregía exactamente esta CVE?
El aviso oficial menciona PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() y PQescapeStringConn() en ciertas situaciones en las que la entrada no pasa la validación de codificación. Para las funciones de libpq, el escenario relevante incluye utilizar su resultado al construir entradas para psql, el cliente interactivo. También se describió un caso en utilidades de línea de comandos con combinaciones de codificación BIG5 y EUC_TW o MULE_INTERNAL. No es un defecto que afecte a toda consulta parametrizada de PostgreSQL.
¿Quién lo descubrió y cómo se estudia un fallo así?
El caso se documentó y corrigió mediante el proceso de seguridad de PostgreSQL. Para investigar vulnerabilidades de este tipo se compara cómo se interpreta una misma cadena en el cliente, el parser y la base, especialmente con caracteres inválidos o codificaciones poco habituales. No hay que atribuir una técnica o un investigador concreto sin consultar el crédito oficial del registro.
¿Cómo puede aprovecharlo alguien?
Un atacante necesita que la aplicación o un script permita introducir datos que acaben en una construcción SQL vulnerable. En el escenario descrito, el texto mal codificado puede escapar de las reglas de comillas esperadas al atravesar las herramientas implicadas. El dato clave es la forma de construir las órdenes, no solo la versión del servidor. Sin ese patrón de uso, la presencia de una versión histórica no demuestra explotación.
¿Qué versiones estaban afectadas?
El proveedor identifica las ramas anteriores a 17.3, 16.7, 15.11, 14.16 y 13.19 como afectadas en el aviso de febrero de 2025. Hoy conviene mantener una rama respaldada por el proyecto o por un distribuidor que documente parches; no instalar versiones históricas solo porque fueron el primer fix.
¿Cómo sé si mi aplicación corre riesgo?
1. Inventariá versiones de PostgreSQL, libpq, herramientas como psql y librerías cliente del backend. 2. Identificá scripts que concatenen instrucciones SQL o que generen archivos para psql. 3. Comprobá si se admiten datos de usuarios en esos flujos y cómo se validan codificaciones. 4. Revisá los permisos del rol de base de datos; nunca uses una cuenta superusuario para tareas normales. 5. Confirmá con los boletines de paquetes si tenés parches retroportados.
¿Cómo se corrige?
Aplicá la actualización pertinente en clientes y servidor cuando corresponda. Preferí consultas parametrizadas en lugar de concatenar SQL a mano; evitá construir órdenes de psql con entradas no confiables; y probá los procesos de importación y migración tras el parche. Un WAF web no ve necesariamente las tareas internas de datos que originan la exposición.
Preguntas rápidas
¿Afecta a Django? Django suele usar parámetros SQL, pero scripts auxiliares o integraciones personalizadas pueden utilizar otras rutas. Investigá el uso real.
¿La base está comprometida? No se puede deducir solo por una versión antigua.
¿PostgreSQL 17.x es siempre seguro? No: es necesario conocer la subversión y los parches.
Fuentes: Boletín oficial PostgreSQL CVE-2025-1094 · Registro CVE.
¿Dónde seguir alertas CVE y recibir orientación?
En ArduMaker CVE y soporte publicamos actualizaciones y centralizamos consultas sobre vulnerabilidades, comenzando por WordPress y sus tecnologías relacionadas. Si tu caso involucra otro runtime o una base de datos, especificá componente, versión, sistema operativo y exposición del servicio para contextualizarlo. El aviso de una CVE no prueba que tu servidor esté comprometido: la evaluación requiere inventario, configuración y evidencia.
Nota editorial — octubre de 2026: estas versiones corregidas son los hitos del aviso original. Al actualizar hoy, elegí una rama con soporte vigente y verificá el comunicado actual del fabricante.
Ejemplo práctico: parámetros en vez de construir SQL con texto
Situación: una API en Python consulta PostgreSQL por email. Un desarrollador escribe una consulta concatenando lo que llega del formulario. Eso es un antipatrón peligroso, aunque CVE-2025-1094 se refiere específicamente a funciones de escape/libpq y ciertos flujos con psql.
Patrón seguro con el driver psycopg:
email = request_data["email"]
cursor.execute(
"SELECT id, nombre FROM clientes WHERE email = %s",
(email,)
)
cliente = cursor.fetchone()El driver trata el email como valor, no como SQL. Para evaluar el CVE real también revisá la versión de libpq y psql, no solo SELECT version() en el servidor.
Antes: scripts que interpolan cadenas para pasarlas a psql. Después: parámetros siempre que sea posible, revisión de codificaciones, actualización de paquetes cliente y permisos mínimos del rol SQL.
¿Por qué ayuda el ejemplo? Enseña a eliminar la clase habitual de errores por concatenación, aunque no reemplaza el parche específico del fallo de escape registrado por PostgreSQL.