PostgreSQL 14 llega a su fin: 52 parches de seguridad

¿Qué incluye la actualización de PostgreSQL 18.7, 17.12, 16.16, 15.20 y 14.25?

El PostgreSQL Global Development Group publicó una actualización simultánea de todas las versiones soportadas del motor: 18.7, 17.12, 16.16, 15.20 y 14.25, junto con la segunda release candidate de PostgreSQL 19. El paquete cierra 52 vulnerabilidades de seguridad y corrige más de 140 bugs reportados en los últimos meses.

Para un founder, el número que importa no es la cantidad de versiones, sino el tipo de fallas. Una parte considerable de los CVEs listados permite ejecución de código arbitrario y llega con puntaje CVSS v3.1 de 8.8, el más alto del lote. Y no se trata de configuraciones exóticas: los parches tocan rutinas que cualquier equipo usa a diario, como pg_dump, pg_restore, REINDEX CONCURRENTLY, dblink o los tipos tsvector y tsquery del motor de búsqueda de texto.

La buena noticia operativa es que las actualizaciones menores de PostgreSQL son acumulativas: no hace falta hacer dump y reload ni usar pg_upgrade. Basta con detener el servidor y actualizar los binarios.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué vulnerabilidades de seguridad corrige esta versión?

El grupo de desarrollo publicó el detalle de cada falla con su puntaje. Estos son los casos críticos, todos con CVSS 8.8:

ALTER … SET DATA TYPE permite ejecutar código arbitrario.
RECORD typmod use-after-free permite ejecutar código arbitrario.
plperl con prepared-query use-after-free permite ejecutar código arbitrario.
pg_restore ejecuta código arbitrario por falta de validación en archivos que no son de formato plano.
tsvectordelete() y tsrank_cd() tienen heap buffer overflow que puede ejecutar código.
pg_dump es vulnerable a SQL injection a través del nombre de una constraint not-null.
return_next() con use-after-free permite ejecutar código arbitrario.
pltcl con conversión de resultado reentrante permite ejecutar código arbitrario.
REINDEX CONCURRENTLY no bloquea DROP INDEX durante las funciones de índice.

Por debajo del umbral de 8.8 hay un segundo grupo de impacto alto: dblink y las suscripciones pueden añadir contenido a archivos arbitrarios (8.1), reindexdb permite SQL injection por el quoting de nombres de índice (8.0) y vacuumdb –missing-stats-only permite que el dueño de una base de datos ejecute código como el usuario que corre vacuumdb (7.2).

Completan la lista fallas de severidad media y baja: INSERT … ON CONFLICT puede leer o modificar filas pese a la condición WHERE de una vista auto-actualizable (5.4), DROP OWNED puede eliminar políticas restrictivas de row security de tablas ajenas (5.4), MERGE puede colocar la fila equivocada en una trigger transition table (5.4), pg_basebackup puede usar el contenido del manifiesto de backup como formato de string (3.7) y el privilegio EXECUTE sobre funciones de cast aparece con 3.1.

¿Por qué PostgreSQL 14 llega a su fin de vida?

Esta es la última entrega de PostgreSQL 14. La rama queda oficialmente end-of-life y dejará de recibir correcciones de seguridad y de bugs. Si tienes producción sobre 14, el mensaje del proyecto es explícito: hay que planificar la migración a una versión soportada.

Traducido a riesgo de negocio: cualquier vulnerabilidad descubierta después de este anuncio quedará sin parche en 14, y eso incluye las clases de fallas que este mismo lote corrigió. Para una startup con datos de clientes o pagos, mantener una rama sin soporte de seguridad es una decisión que conviene documentar con el equipo y con los inversionistas, no un pendiente técnico que se arrastra.

¿Qué reindexados hay que hacer después de actualizar?

Este punto es donde más equipos se van a tropezar. La actualización corrige casos de corrupción de índices que, en algunas configuraciones, hacían que las búsquedas omitieran filas que sí coincidían. La corrección no repara los índices ya afectados: hay que reconstruirlos a mano.

Si usas pg_trgm, reindexa los índices GiST que utilizan la clase de operadores gist_trgm_ops.
Si al leer una tabla aparecen errores de tipo missing chunk number, reindexa la tabla completa, lo que también reconstruye su tabla TOAST.
Si tienes índices B-tree sobre columnas bpchar sin longitud, reindexarlos es obligatorio. Las columnas declaradas como char(n) no están afectadas.

Los comandos son directos:

REINDEX INDEX your_index_name;
REINDEX TABLE your_table_name;

El proyecto recomienda además revisar las constraints NOT NULL NO INHERIT en tablas particionadas, un problema que podía permitir que una partición contuviera valores NULL donde no debía. La consulta de diagnóstico es:

SELECT conrelid::regclass, conname
FROM pg_constraint
WHERE contype = 'n' AND connoinherit
  AND conrelid IN (SELECT oid FROM pg_class WHERE relkind = 'p');

Las constraints que no quieras se eliminan con ALTER TABLE ... DROP CONSTRAINT. Las que quieras conservar se reparan con ALTER TABLE ... ALTER CONSTRAINT ... INHERIT, que fallará si alguna partición tiene NULL en esa columna.

Y si usas backups incrementales, el proyecto recomienda tomar una nueva copia completa después de actualizar y usarla como base de las siguientes incrementales. Este release también ajusta el manejo del archivo pg_control y evita copias truncadas o con relleno de archivos como postgresql.auto.conf que se reemplazan mientras el backup corre.

¿Cuándo sale PostgreSQL 19 y qué cambia en la RC 2?

La RC 2 de PostgreSQL 19 debería ser casi idéntica a la versión final: el proyecto solo aplicaría correcciones puntuales antes del lanzamiento general. La fecha planificada para la disponibilidad general es el 19 de noviembre de 2026.

A diferencia de las actualizaciones menores, pasar a la 19 sí exige una estrategia de upgrade de versión mayor, con pg_upgrade o pg_dump / pg_restore. Y hay un detalle que ya rompió upgrades en pruebas: si usas pg_upgrade con índices de full text search, pg_trgm o fuzzystrmatch, revisa la sección de migración a la versión 19 de las release notes, porque puede que necesites reindexarlos.

Durante el periodo de la RC 1 se aplicaron correcciones relevantes, entre ellas fallas en expresiones JSON_ARRAY() y JSON_OBJECT() sobre arrays, tipos compuestos y tipos range usados en índices de expresión, columnas generadas y claves de partición. Si creaste esos objetos probando la 19, hay que eliminarlos o redefinirlos antes de subir, porque pg_upgrade fallará al recrearlos. También se corrigieron GROUPING SETS, las funciones first_value() y nth_value() con IGNORE NULLS y ciertas opciones de frame EXCLUDE, una cola de LISTEN / NOTIFY que podía quedar trabada y un cálculo de work_mem.

El release incorpora además tzdata 2026f. Desde noviembre de 2026, los Northwest Territories de Canadá (America/Inuvik) quedan en UTC-06 todo el año y Manitoba (America/Winnipeg) en UTC-05 todo el año. El release asume que sus abreviaturas serán CST y EST, aunque el proyecto advierte que eso podría cambiar. También refleja que Cuba mantendrá el horario de verano este invierno y que los nombres de zona EST5EDT, CST6CDT, MST7MDT y PST8PDT ahora usan su offset UTC indicado para timestamps antiguos, en lugar de la historia de las ciudades asociadas.

¿Qué significa esto para tu startup?

Actualizar no es solo higiene técnica: es la diferencia entre tener 52 vulnerabilidades abiertas y ninguna. Estas son las acciones concretas que puedes ejecutar esta semana.

Programa la ventana de mantenimiento. Al ser un release acumulativo, el procedimiento es detener el servidor, actualizar binarios y reiniciar. Aprovecha para correr primero el upgrade en un entorno de staging con una copia de producción y verificar tus consultas críticas: la corrección de CVE-2026-6464 introdujo regresiones en AT TIME ZONE dentro de una cláusula FROM, en alias de tabla llamados set y en valores tsvector y tsquery que podían fallar al recargarse.
Convierte el reindexado en una tarea con dueño. Los índices GiST de pg_trgm, los B-tree sobre columnas bpchar sin longitud y las tablas con errores de chunk faltante requieren reconstrucción manual. Mide cuánto tarda en staging antes de hacerlo en producción, porque REINDEX bloquea escrituras.
Audita tus constraints de particionado. Corre la consulta de diagnóstico y decide cuáles eliminar y cuáles reparar. Si tu tabla ya tiene NULL donde no debía, la reparación fallará y ese es el momento de enterarte, no en un incidente.
Define un plan de salida de PostgreSQL 14. Si sigues en 14, pon fecha a la migración. Documenta el riesgo: sin soporte, la próxima vulnerabilidad crítica no tendrá parche para tu versión.
Si usas un servicio gestionado, verifica en el panel de tu proveedor si la versión menor ya está publicada antes de asumir que tu base está parcheada. Los proveedores suelen tener su propio calendario, y entre el anuncio y la disponibilidad real tu instancia sigue expuesta.
Si estás evaluando la 19, espera la versión final prevista para el 19 de noviembre de 2026 para producción y usa la RC 2 solo en entornos de prueba.

El ecosistema de herramientas se mueve al mismo ritmo: Devart presentó dbForge 2026.2, con un depurador embebido para PostgreSQL que permite fijar breakpoints y ejecutar el código línea por línea sin instalar extensiones, según SD Times. Es la señal de que la presión por actualizar también viene de las herramientas que usan tus equipos.

Conclusión

Esta actualización concentra el mayor riesgo y la mayor oportunidad del trimestre para quien opera PostgreSQL: 52 vulnerabilidades cerradas, más de 140 bugs corregidos y el fin de vida de la 14, que obliga a tomar una decisión que muchos equipos vienen postergando. Actualizar los binarios es la parte fácil. Lo que separa a un equipo maduro del resto es ejecutar los reindexados, auditar las constraints y poner fecha a la migración. Hazlo ahora, mientras el parche ya existe.