PostgreSQL corrige un fallo de hace 22 años que permite ejecutar código en el servidor

El proyecto PostgreSQL publicó el 12 de noviembre las actualizaciones 18.7, 17.12, 16.16, 15.20 y 14.25. Según el proyecto, corrigen 52 vulnerabilidades y más de 140 errores de otro tipo. La más comentada es CVE-2026-6460, con una puntuación de 8,8 sobre 10: un usuario de la base con permiso para crear objetos puede ejecutar su propio código en el servidor con los permisos del usuario del sistema que ejecuta PostgreSQL. El proyecto dio la misma puntuación a otras 31 vulnerabilidades de esta versión. No se han detectado ataques que aprovechen CVE-2026-6460.

Por qué el fallo tiene 22 años

El fallo afecta a los tipos compuestos, es decir, tipos formados por varios campos con nombre. Se puede cambiar el tipo de un campo mientras quedan valores antiguos guardados en otras partes del servidor, y entonces el servidor lee un valor antiguo como si ya tuviera el tipo nuevo. En su aviso, el proyecto admite que el sistema no seguía bien el tipo de los valores. El investigador Mehmet Ince, que mostró un exploit funcional en la versión 18.6, sitúa el origen del problema el 5 de mayo de 2004, cuando PostgreSQL permitió cambiar el tipo de una columna, según The Hacker News.

Ince afirma que pudo tumbar un servidor sin parchear con el rol de menos privilegios. Ninguna de las fuentes aclara si con esa cuenta se puede llegar a ejecutar código. En agosto adaptó el exploit a las bases de datos gestionadas y lo compartió con los equipos de seguridad de AWS, Microsoft Azure, Google, Supabase, Databricks y Ubicloud. No se sabe si todos han aplicado ya el parche.

A quién afecta

Sobre todo a quien deja entrar a otras personas en la misma base: proveedores de alojamiento, servicios en la nube y cualquier proyecto que da a sus clientes su propia cuenta de PostgreSQL. Si solo su aplicación usa la base, un atacante externo primero tendría que conseguir permisos dentro. También se corrigieron herramientas cliente: un archivo manipulado puede hacer que pg_restore ejecute código en el equipo de quien restaura la base. Solo una de las 52 vulnerabilidades funciona sin iniciar sesión, y permite reiniciar un servidor PostgreSQL 18.

No es la única actualización de servidor de la semana que conviene instalar cuanto antes: hace poco escribimos sobre un fallo de HTTP/2 en Apache.

Qué hacer

• Actualice el servidor a 18.7, 17.12, 16.16, 15.20 o 14.25 según su versión principal. No hace falta volcar y recargar la base.
• Recompile o actualice todas las extensiones en C al mismo tiempo. Las compilaciones antiguas siguen cargando, pero según los responsables de los paquetes RPM pueden quedar sin protección.
• Actualice pg_dump, pg_restore, reindexdb y vacuumdb en todos los equipos donde se usen.
• Si PostgreSQL se ejecuta fuera de la unidad de servicio del paquete, por ejemplo con Patroni, reinícielo justo después de actualizar.
• No desactive las nuevas comprobaciones con el ajuste composite_type_mismatch: el proyecto advierte de que es un riesgo de seguridad.
• Siga los pasos de la sección «Updating» del anuncio: reconstruir los índices afectados (GIN, GiST con pg_trgm, B-tree en columnas bpchar) y, si usa copias incrementales, hacer una nueva copia completa.
• Si usa la versión 14 o anterior, planifique la migración: después de la 14.25 no habrá más correcciones.