El proyecto PostgreSQL ha publicado el 12 de noviembre de 2026 las versiones 18.7, 17.12, 16.16, 15.20 y 14.25, que corrigen 52 vulnerabilidades de seguridad y más de 140 errores. Treinta y dos de esos fallos tienen una puntuación CVSS de 8,8 y muchos permiten ejecutar código en el servidor con los permisos del usuario del sistema que ejecuta PostgreSQL. Esta actualización es además la última de PostgreSQL 14, que queda sin soporte. No hay constancia de ataques, pero el parche exige pasos adicionales: recompilar extensiones en C, reiniciar el servicio en algunos entornos y actualizar también las herramientas cliente.
Las claves de la actualización de PostgreSQL en 20 segundos
- Las versiones 18.7, 17.12, 16.16, 15.20 y 14.25 corrigen 52 fallos.
- El más grave, CVE-2026-6460, permite ejecutar código en el servidor.
- PostgreSQL 14 queda sin soporte con esta versión.
- Hay que recompilar extensiones en C y actualizar pg_dump y pg_restore.
La publicación incluye también la segunda versión candidata de PostgreSQL 19. Las versiones antiguas ya sin soporte también están afectadas por muchos de estos fallos, pero no reciben parche, así que la única solución en ellas es migrar a una versión soportada.
Los fallos más graves
El más destacado es CVE-2026-6460 (CVSS 8,8), una confusión de tipos que se produce tras un ALTER ... SET DATA TYPE sobre tipos compuestos. Según el aviso del proyecto, un usuario con permiso para crear o modificar objetos puede aprovecharlo para ejecutar código arbitrario en el servidor con los privilegios del usuario del sistema operativo que ejecuta PostgreSQL. El origen se remonta a un cambio de 2004. La corrección añade comprobaciones de versión para que el servidor detecte cuándo un valor ya no coincide con su tipo, y por eso la protección completa exige recompilar las extensiones escritas en C.
Hay una larga lista de fallos con el mismo patrón de riesgo. Entre los de CVSS 8,8 figuran CVE-2026-18447, una confusión de tipos en parámetros de salida; CVE-2026-116304, un uso de memoria liberada en el manejo paralelo de registros; CVE-2026-116306, ligado a cambios de tipos compuestos durante la asignación de campos, y CVE-2026-116307 y CVE-2026-116309, en el lenguaje procedimental PL/Perl. Otros, con menor puntuación, permiten añadir contenido a archivos arbitrarios desde dblink y las suscripciones (CVE-2026-14661, CVSS 8,1), ejecutar SQL arbitrario por un mal manejo de esquemas en scripts de extensiones (CVE-2026-6467, CVSS 7,2) o saltarse políticas de seguridad de filas.
Según The Hacker News, solo un fallo del servidor, CVE-2026-116322, no requiere autenticación ni interacción: permite a un cliente no autenticado reiniciar servidores PostgreSQL 18. También hay fallos en las herramientas cliente: un archivo de copia manipulado puede hacer que pg_restore ejecute código con los permisos de quien lo lanza, y un servidor de origen comprometido puede hacer que psql ejecute código a través del script de restauración de un volcado tar de pg_dump.
El investigador Mehmet Ince figura entre los descubridores de CVE-2026-6460 y de otros cinco fallos, aunque el proyecto atribuye ese CVE a más de una docena de personas. Ince compartió en agosto pruebas de concepto con proveedores de PostgreSQL gestionado como AWS, Microsoft Azure, Google AlloyDB, Supabase, Databricks y Ubicloud; no consta en qué punto está la actualización de cada uno. Su análisis muestra un cierre inesperado del servidor con un rol de bajos privilegios y una fuga de direcciones de memoria, pero no publica el paso final hasta la ejecución de código. El proyecto no ha informado de ataques y el registro CVE de la CISA indica que no hay explotación conocida.
Qué hacer al actualizar
No existe una mitigación alternativa para los servidores que no se puedan actualizar todavía, así que la recomendación es pasar cuanto antes a la versión corregida de cada rama y, a la vez, tener en cuenta varios pasos que señalan el proyecto y The Hacker News:
- Extensiones en C: recompilarlas o actualizarlas al mismo tiempo que el servidor. Las compiladas para versiones anteriores pueden no estar protegidas y algunas necesitan cambios en el código. Los paquetes RPM de extensiones ya exigen la nueva versión menor.
- Reinicio: si PostgreSQL no se gestiona con la unidad de servicio del paquete, por ejemplo bajo Patroni, reiniciarlo justo después de actualizar.
- Clientes: actualizar
pg_dump,pg_restore,reindexdbyvacuumdben todas las máquinas que los ejecutan, no solo en el servidor. - No desactivar las comprobaciones: el ajuste
composite_type_mismatchpermite relajar la nueva verificación de tipos, pero hacerlo reabre el riesgo. - Tras actualizar: seguir los pasos de reindexado de las notas de la versión y, si se usan copias incrementales, hacer una copia completa nueva y basar en ella las siguientes.
Quien siga con PostgreSQL 14 debe planificar ya la migración, porque los próximos fallos no tendrán parche. Antes de cualquier cambio de versión conviene tener una copia verificada; en Administración de Sistemas explicamos cómo hacerlo con pgBackRest.
Preguntas frecuentes
¿Qué versiones de PostgreSQL corrigen los fallos?
Las 18.7, 17.12, 16.16, 15.20 y 14.25, publicadas el 12 de noviembre de 2026.
¿Qué es CVE-2026-6460?
Una confusión de tipos con CVSS 8,8 que permite a un usuario con permiso para crear o modificar objetos ejecutar código en el servidor con los permisos del usuario que ejecuta PostgreSQL.
¿Sigue teniendo soporte PostgreSQL 14?
No. La versión 14.25 es la última; PostgreSQL 14 deja de recibir correcciones de seguridad.
Fuentes:
