PostgreSQL corrigió una vulnerabilidad grave (CVE-2026-6460) que permitía a usuarios con permisos de creación de objetos ejecutar código en el servidor. Para solucionar este y otros 51 fallos, se recomienda actualizar a las versiones más recientes y reconstruir todas las extensiones en lenguaje C. No se han reportado ataques activos, pero es fundamental actualizar tanto el servidor como las herramientas de cliente.





Un fallo de confusión de tipos en PostgreSQL permite que un usuario de la base de datos que pueda crear objetos ejecute código en el servidor. Las actualizaciones publicadas ayer lo solucionan, junto con otras 51 vulnerabilidades de seguridad. Para obtener protección total contra este fallo, también necesitas recompilar cualquier extensión en lenguaje C instalada en el servidor.

El fallo, identificado como CVE-2026-6460, tiene una puntuación CVSS de 8.8. Cualquier código ejecutado de esta manera tiene los derechos del usuario del sistema operativo que ejecuta PostgreSQL. Todas las versiones anteriores a 18.7, 17.12, 16.16, 15.20 y 14.25 están afectadas.

El Grupo de Desarrollo Global de PostgreSQL, que publica las versiones de la base de datos, no ha informado de ningún ataque que utilice este fallo. La evaluación de CISA en el registro CVE también indica que no ha habido explotación.

El fallo afecta a los tipos compuestos, que son tipos creados a partir de campos con nombre, cada uno con su propio tipo de datos. El tipo de un campo puede cambiarse mientras los valores antiguos de ese tipo todavía se mantienen en otras partes del servidor.

El servidor podría entonces leer un valor antiguo como si tuviera el nuevo tipo. La solución, descrita en las notas de lanzamiento del proyecto, añade comprobaciones de versión para que el servidor pueda detectar un valor que ya no coincida con su tipo.

El investigador de seguridad Mehmet Ince describió un exploit funcional para el fallo, demostrado en PostgreSQL 18.6, en un artículo técnico publicado esta semana.

Su método consiste en preparar una consulta que contenga un valor, cambiar el tipo de uno de los campos de ese valor y luego ejecutar la consulta. El artículo incluye el SQL que provoca el colapso de un servidor sin parchear de esta manera y un segundo paso que filtra direcciones de memoria. No incluye el SQL para el paso final, que hace que el servidor ejecute un comando.

Escribió que podía "provocar este colapso como un rol de inicio de sesión con los privilegios más bajos". El aviso de seguridad del proyecto describe al atacante solo como alguien que puede crear objetos, sin especificar qué privilegios requiere eso.

Red Hat, que distribuye paquetes de PostgreSQL, afirma en su evaluación del CVE que un atacante necesita un inicio de sesión en la base de datos con capacidad para crear o modificar objetos. Ninguna de estas fuentes dice si una cuenta con solo privilegios predeterminados puede ir más allá del colapso y ejecutar código.



Ince rastrea la raíz del fallo hasta el 5 de mayo de 2004, cuando PostgreSQL obtuvo la capacidad de cambiar el tipo de una columna. Su técnica para ejecutar código se basa en un cambio posterior realizado el 14 de mayo de 2015.

También adaptó el exploit para servicios gestionados de PostgreSQL y compartió privadamente pruebas de concepto con sus equipos de seguridad en agosto. Los proveedores con los que trabajó incluyen AWS (Aurora y RDS), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks y Ubicloud. El artículo no detalla el estado actual de los parches de cada servicio.

El proyecto acredita a más de una docena de informantes por el CVE-2026-6460, incluido el investigador, y le acredita por otros cinco fallos en la misma versión.

El proyecto califica 32 de los 52 fallos con un 8.8, la puntuación más alta de la versión. Basándose en las puntuaciones de su índice de vulnerabilidades, solo un fallo en el servidor no requiere ni inicio de sesión ni acción del usuario. Ese fallo, CVE-2026-116322, permite que un cliente no autenticado provoque un reinicio de los servidores PostgreSQL 18.

Varias otras correcciones se encuentran en las herramientas del cliente. Un archivo manipulado puede hacer que pg_restore ejecute código como el usuario que lo ejecuta. Un servidor de origen comprometido puede hacer que psql ejecute código a través del script de restauración en la salida tar de pg_dump.

Qué deben hacer los administradores

1. Actualiza el servidor a 18.7, 17.12, 16.16, 15.20 o 14.25, según tu versión principal.
2. Recompila o actualiza cada extensión en lenguaje C al mismo tiempo que el servidor. Las extensiones creadas para versiones anteriores todavía se cargan, pero "podrían no estar protegidas contra las vulnerabilidades corregidas en esta versión", según un aviso del repositorio de los mantenedores del paquete RPM del proyecto. Algunas extensiones también necesitarán cambios en el código fuente.
3. Las extensiones recompiladas para las nuevas versiones pueden fallar al cargarse en servidores antiguos. Los paquetes de extensiones en los repositorios RPM del proyecto ahora requieren la nueva versión menor.
4. Si PostgreSQL se ejecuta fuera de su propia unidad de servicio del paquete, por ejemplo bajo Patroni, reinícialo inmediatamente después de actualizar, afirma un mantenedor de los paquetes RPM en una entrada de blog de empaquetado.
5. Actualiza las herramientas del cliente como pg_dump, pg_restore, reindexdb y vacuumdb en cada máquina que las ejecute.
6. No utilices el nuevo ajuste composite_type_mismatch para desactivar las comprobaciones. El proyecto indica que hacer esto conlleva riesgos de seguridad.
7. El aviso y las notas de lanzamiento del proyecto no ofrecen ninguna solución alternativa para los servidores que aún no puedan actualizarse.
8. PostgreSQL 14 ha llegado al final de su vida útil, y la 14.25 es su última versión. Las versiones principales más antiguas también están afectadas y no recibieron actualización.
9. Después de actualizar, sigue los pasos de reindexación en el anuncio de lanzamiento. Si utilizas copias de seguridad incrementales, realiza una nueva copia de seguridad completa y basa las siguientes copias incrementales en ella.

Fuente:
THN