# PostgreSQL 18.7 cierra 52 fallos de seguridad y jubila la 14 > Las versiones 18.7, 17.12, 16.16, 15.20 y 14.25 corrigen 52 vulnerabilidades, 32 con 8.8, y 14.25 es la última de la rama 14. > Por José Maldonado · Ciberseguridad · 2026-11-13 Los desarrolladores de PostgreSQL publicaron este 12 de noviembre de 2026, las versiones 18.7, 17.12, 16.16, 15.20 y 14.25, junto a la segunda candidata de PostgreSQL 19. Lo que en el calendario del proyecto es una actualización menor ha salido como el mayor paquete de seguridad de su historia reciente: 52 vulnerabilidades corregidas y más de 140 errores, según el [registro oficial de vulnerabilidades de PostgreSQL](https://www.postgresql.org/support/security/). El dato que ordena la urgencia no es el volumen, sino la nota. Treinta y dos de los 52 CVE comparten un CVSS 3.1 de 8.8, la puntuación más alta del lote, y casi todos describen el mismo desenlace: confusión de tipos o memoria liberada que termina en ejecución de código con los privilegios del usuario del sistema operativo que corre la base de datos. El más bajo del paquete es un 3.1 que permite saltarse el privilegio EXECUTE en funciones de conversión. Hay una segunda noticia dentro del anuncio. La versión 14.25 es la última de la rama 14, que a partir de ahora no recibe parches de seguridad ni correcciones de errores. Quien siga en esa rama tiene un problema de calendario más que de configuración: cada mes sin migrar es un mes sin red, y el salto a la 15 o la 16 exige una ventana de mantenimiento que nadie reserva por gusto. ## Cinco versiones publicadas el mismo día El lote llegó en cinco versiones a la vez: 18.7 y 17.12; 16.16 y 15.20; y 14.25. La actualización es acumulativa, así que no hace falta pasar por pg\_upgrade ni exportar los datos: basta con parar el servidor, sustituir los binarios y volver a arrancar. Conviene revisar cuál de esas cinco ramas corre en cada máquina antes de decidir nada, porque la más antigua con soporte ya está en la 15 y el anuncio cierra la puerta a la 14 sin ceremonia. La [política de versiones de PostgreSQL](https://www.postgresql.org/support/versioning/) fija cinco años de soporte por rama desde su primera publicación. Casi todos los fallos de ejecución remota comparten forma técnica. PostgreSQL maneja valores con una etiqueta de tipo y, cuando esa etiqueta y el contenido real dejan de coincidir, el motor acaba interpretando bytes arbitrarios como si fueran otra estructura. El resultado va desde una lectura de memoria hasta el control del flujo de ejecución. ### Código y lenguaje legado Los nombres del listado dibujan los puntos calientes del código. Están PL/Perl y PL/Tcl en la capa de lenguajes embebidos; ts\_rank\_cd() en la búsqueda textual; la consulta en paralelo y la replicación lógica dentro del motor; y dblink con la importación de estadísticas en el borde de las extensiones. Son piezas que rara vez se auditan con la misma lupa que el núcleo y que, a la vez, están expuestas a cualquier usuario con permiso de conexión. CVE CVSS 3.1 Qué permite CVE-2026-6460 8.8 Ejecutar código tras un ALTER con cambio de tipo de dato CVE-2026-116330 8.8 Inyectar comandos psql al restaurar un tar creado con pg\_dump CVE-2026-116318 8.8 Inyectar SQL con el nombre de un constraint en pg\_dump CVE-2026-14661 8.1 Añadir contenido a archivos arbitrarios con dblink y suscripciones CVE-2026-116313 7.2 Ejecutar código como el usuario que lanza vacuumdb CVE-2026-116303 3.1 Saltarse el privilegio EXECUTE en funciones de conversión El caso más incómodo de la tabla es CVE-2026-6460. Un ALTER que cambia el tipo de un campo deja el valor anterior con la etiqueta nueva, y a partir de ahí el motor lee una dirección de memoria que no corresponde con lo que cree tener. La explotación no necesita nada exótico, solo permiso para crear y modificar objetos. ## Las herramientas del cliente también entran Tres de los fallos más graves no están en el servidor. pg\_dump permitía inyección SQL a través del nombre de un constraint y su modo tar generaba un restore.sql capaz de ejecutar comandos de psql, dos vías para que una copia de seguridad se convierta en el vector de entrada. Cualquiera que restaure volcados de bases donde otros usuarios pueden crear objetos debería actualizar también los binarios del cliente. El resto del paquete toca utilidades que se lanzan desde cron sin pensar demasiado. reindexdb no citaba bien los nombres de índice, vacuumdb con la opción de estadísticas incompletas permitía a un dueño de base ejecutar código como el usuario que lanza la herramienta, y dblink con las suscripciones lógicas podían añadir contenido a archivos arbitrarios del sistema. Ese detalle cambia la prioridad de un equipo pequeño. La base de datos suele parchearse con cuidado y las herramientas se olvidan, pese a que son las que tienen permisos sobre el sistema de archivos y las que se ejecutan con credenciales guardadas en scripts. ## Reindexar y rehacer la copia completa Instalar los binarios no cierra el trabajo. El lote corrige errores que podían dejar índices corruptos, así que conviene reconstruir los GIN sospechosos, los GiST de pg\_trgm con gist\_trgm\_ops y los B-tree sobre columnas bpchar declaradas sin longitud. Una tabla que devuelve errores de bloque perdido necesita un REINDEX TABLE completo antes de dar el incidente por resuelto. Las copias también requieren atención. Quien use copias incrementales debería tomar una copia completa nueva y basar las siguientes en ella, porque varios de los fallos corregidos podían producir respaldos corruptos de forma silenciosa. Un respaldo que falla al restaurar se descubre en el peor momento posible. Nada de esto figura en el titular del anuncio y todo ello aparece en el listado de cambios, un documento largo que conviene leer al menos por encima cuando la instalación sostiene servicios de terceros. La actualización de un servidor propio tiene algo de mantenimiento doméstico: el [repaso de qué montar y qué actualizar en 2026](https://observatorioblockchain.com/tecnologia/autohospedaje-2026-que-montar/) sirve de recordatorio de que el parche es solo una parte del trabajo. ## El fallo de 22 años que apareció con un agente de IA CVE-2026-6460 llegó con relato propio. El investigador Mehmet Ince publicó el 9 de noviembre de 2026 la tercera parte de su serie sobre riesgos del PostgreSQL gestionado, en la que cuenta cómo llegó a la primitiva de confusión de tipos que llevaba unos [22 años dentro del motor](https://mehmetince.net/part-3-6-how-i-ended-up-turning-a-22-year-old-postgresql-type-confusion-primitive-into-rce-cve-2026-6460/). El punto de partida no fue el núcleo, sino una extensión mal convertida que lo obligó a estudiar cómo el motor decide qué es cada valor. En su relato, un agente de IA le sirvió de profesor para recorrer las tripas del motor una pregunta a la vez, y la idea que conectó todo llegó de una conversación aparentemente ajena al problema. El detalle importa menos que la conclusión: la clase de fallo no era nueva, solo estaba sin encontrar. ### La rama 14 se queda sin parches La 14.25 cierra una rama que vio la luz el 30 de septiembre de 2021 y cuya fecha de caducidad era el 12 de noviembre de 2026, cinco años después, como fija esa misma política. Seguir en ella no es solo una decisión estética: a partir de diciembre, cualquier fallo nuevo que afecte a esa versión se quedará sin arreglo oficial, y el proyecto no mantiene parches a medida para ramas cerradas. La migración a la 15 o la 16 exige pg\_upgrade y una ventana de mantenimiento real, con pruebas de las extensiones y de las consultas más pesadas. Ese trabajo compite mal contra la urgencia del día, y es la razón por la que muchas instalaciones llegan al fin de soporte con años de retraso acumulados. ## Un parche que no cabe en la ventana mensual El ciclo habitual de un equipo pequeño es mensual y el de este lote es semanal. Treinta y dos fallos de 8.8 que permiten ejecutar código con permisos del sistema no se pueden dejar esperando a la próxima reunión de cambios, y menos cuando la explotación no exige nada más que una conexión válida y permiso para crear objetos. La otra lección es de inventario. Un parche que obliga a actualizar servidor y cliente a la vez, y que además pide reindexar y rehacer respaldos, castiga a quien no sabe con certeza qué versión corre en cada máquina. El [calendario de parches de .NET de este mismo noviembre](https://observatorioblockchain.com/ciberseguridad/dotnet-parche-fuera-de-banda-brotli/) apunta en la misma dirección. Las [doce entradas de CISA en diez días](https://observatorioblockchain.com/ciberseguridad/cisa-kev-doce-fallos-diez-dias-gitlab/) confirman el patrón, y dejan una consecuencia práctica para quien administra bases de datos: el ritmo de correcciones ya no lo marca el proveedor, sino quien encuentra antes el fallo.