PostgreSQL publicó el 12 de noviembre actualizaciones que corrigen 52 vulnerabilidades, entre ellas CVE-2026-6460: un fallo de confusión de tipos que puede permitir a un usuario capaz de crear objetos ejecutar código con los permisos de la cuenta del sistema que ejecuta la base de datos. La corrección no queda completa con cambiar los binarios del servidor: también hay que reconstruir las extensiones escritas en C.
El problema afecta a las versiones anteriores a 18.7, 17.12, 16.16, 15.20 y 14.25, según la rama. PostgreSQL no ha informado de ataques que exploten CVE-2026-6460; eso no elimina la necesidad de aplicar la actualización. La capacidad concreta de crear objetos depende de los permisos de la cuenta, y no está claro que los privilegios predeterminados basten para llegar a la ejecución de código.
«trigger this crash as a lowest-privileged login role»
— Mehmet Ince, investigador de seguridad
1. Identifica la versión y el tipo de instalación
Empieza por averiguar qué versión ejecuta cada instancia, no solo la que tienes instalada en tu equipo. IlSoftware.it indica que puedes consultar la versión desde una sesión SQL con:
SELECT version();Compara la rama principal que devuelve la consulta con la tabla y apunta qué servidores necesitan actualización. Si PostgreSQL procede de los repositorios de una distribución Linux, IlSoftware.it recomienda revisar también los avisos del proveedor: puede integrar una corrección en su paquete sin cambiar el número de versión que esperas ver.
| Rama afectada | Versión corregida |
|---|---|
| 18 | 18.7 |
| 17 | 17.12 |
| 16 | 16.16 |
| 15 | 15.20 |
| 14 | 14.25 |
La tabla recoge las versiones corregidas publicadas por el PostgreSQL Global Development Group. PostgreSQL 14.25 es la última versión de esa rama; PostgreSQL 14 ha llegado al final de su ciclo de vida. Si sigues en esa rama, aplica la última actualización disponible y planifica la migración a una versión con soporte.
2. Actualiza el servidor a la revisión de tu rama
Instala la versión corregida correspondiente: no hace falta saltar de rama principal para abordar este aviso. Las notas de PostgreSQL 18.7 dicen que quienes actualizan dentro de la serie 18 no necesitan volcar y restaurar la base de datos. No extrapoles esa indicación a una migración entre ramas: se refiere a ejecutar una actualización menor dentro de 18.x.
Si el servidor se ejecuta fuera de la unidad de servicio de su paquete —por ejemplo, bajo Patroni—, un mantenedor de los paquetes RPM recomienda reiniciarlo inmediatamente después de actualizar. Comprueba cómo se gestiona cada instancia y confirma que el proceso está ejecutando los binarios nuevos; no des por hecho que instalar el paquete basta.
3. Reconstruye las extensiones escritas en C
Esta tarea es parte de la corrección de CVE-2026-6460. PostgreSQL añadió comprobaciones para detectar valores compuestos cuyo tipo ya no coincide con el esperado, pero la protección completa requiere reconstruir las extensiones de lenguaje C contra la versión actualizada. Algunas necesitan además cambios en su código fuente.
Actualiza o recompila todas las extensiones C instaladas, y comprueba que los paquetes disponibles para tu sistema ya se han reconstruido. Si administras la compilación, sigue las instrucciones de cada extensión y prueba que vuelve a cargar en el servidor actualizado. La versión recompilada puede no cargar en servidores antiguos, así que coordina ambos cambios.
4. Actualiza las herramientas cliente
El servidor no es el único componente al que afectan los avisos. The Hacker News señala riesgos en utilidades cliente: un archivo de respaldo manipulado puede hacer que pg_restore ejecute código con los permisos del usuario que lo lanza; un servidor de origen comprometido puede hacer que psql ejecute código a través de un script de restauración incluido en una salida tar de pg_dump.
Actualiza pg_dump, pg_restore, reindexdb y vacuumdb en cada máquina que los utilice. Incluye servidores de administración, estaciones de trabajo y sistemas de automatización. No ejecutes restauraciones desde archivos que no sean de confianza ni asumas que actualizar el motor actualiza automáticamente las herramientas instaladas en otros equipos.
5. Revisa índices y copias de seguridad
Las notas de PostgreSQL 18.7 advierten de varios errores que pueden corromper índices y recomiendan examinar las entradas del registro de cambios que mencionan REINDEX. Identifica qué índices de tu instalación pueden estar afectados y reconstruye esos, siguiendo las instrucciones de las notas de la versión que corresponda; no conviertas la revisión en una reconstrucción indiscriminada de todos los índices.
Si usas copias de seguridad incrementales, considera no fiables las existentes: las notas indican que pueden haberse corrompido. Después de actualizar, crea una copia de seguridad completa nueva y úsala como base para las siguientes copias incrementales. No sigas encadenando incrementales sobre una base anterior a la actualización.
6. Confirma la situación de las instancias en la nube
Mehmet Ince compartió pruebas de concepto de forma privada con equipos de seguridad de varios proveedores, entre ellos AWS, Microsoft, Google, Supabase, Databricks y Ubicloud. Entre los servicios citados figuran Aurora y RDS, Azure PostgreSQL y AlloyDB. No se detalló el estado actual del parche de cada servicio.
Si utilizas PostgreSQL gestionado, comprueba con tu proveedor si la instancia ya recibió la corrección y qué acción te corresponde. No des por hecho que todos los servicios se actualizaron al mismo tiempo, ni intentes aplicar por tu cuenta los pasos de un servidor autogestionado si el proveedor administra el motor.
Errores que conviene evitar
No desactives composite_type_mismatch para sortear problemas de compatibilidad. PostgreSQL advierte que deshabilitar esas comprobaciones conlleva riesgos de seguridad; algunas extensiones pueden necesitar cambios de código precisamente para funcionar con la protección activa.
Tampoco trates el cortafuegos o la ausencia de ataques conocidos como sustitutos del parche. CVE-2026-6460 requiere una cuenta capaz de crear objetos, no una cuenta de superusuario según el aviso del proyecto. La actualización es la medida principal; revisar permisos innecesarios puede reducir la exposición, pero no la reemplaza.
Por último, no olvides los componentes que quedan fuera del proceso de actualización del servidor: extensiones C, utilidades cliente, índices potencialmente afectados y la base de las copias incrementales. Y si aún ejecutas PostgreSQL 14, ten presente que 14.25 cierra esa rama: la corrección no prolonga su soporte.
Fuentes: The Hacker News, IlSoftware.it, VONNG, PostgreSQL Global Development Group, PostgreSQL Global Development Group
