El 13 de agosto de 2026 el PostgreSQL Global Development Group publicó un release doble: la tanda de mantenimiento 18.6, 17.11, 16.15, 15.19 y 14.24 —que cierra de un saque 28 CVEs y más de 110 bugs— y la tercera beta de PostgreSQL 19, la versión que va a salir estable entre septiembre y octubre. No es un update cosmético: buena parte de esos CVEs permiten ejecución de código arbitrario con un usuario de base común. Si tenés Postgres en producción, esto es para hoy.

PostgreSQL 18.6 es la actualización menor de mantenimiento de la rama 18 de PostgreSQL, el motor de base de datos relacional open source del PostgreSQL Global Development Group. Corrige 28 vulnerabilidades (CVE) y más de 110 bugs sobre todas las ramas soportadas, es acumulativa y no requiere dump/reload. En paralelo, la 19 Beta 3 es la tercera prueba pública de la próxima versión mayor, todavía no apta para producción.

¿Por qué este parche de seguridad es más grave que un update menor típico?

Porque de los 28 CVEs, alrededor de una docena tienen CVSS 8.8 y terminan en ejecución de código arbitrario como el usuario de sistema que corre la base, disparable por un usuario de base sin privilegios especiales. Según el anuncio oficial del PostgreSQL Global Development Group, el patrón que se repite es el integer wraparound: un cálculo de tamaño se desborda, el servidor reserva menos memoria de la que necesita y después escribe fuera de los límites.

Los que más conviene mirar:

  • CVE-2026-14662 (CVSS 8.8): tsvector y tsquery hacen allocations subdimensionadas por integer wraparound. Si usás full-text search de Postgres, estás en la línea de fuego.
  • CVE-2026-19385 (CVSS 8.8): heap buffer overflow en pg_dump que ejecuta código arbitrario. El detalle feo: se dispara al hacer un backup de una base con contenido malicioso, así que un dump "de rutina" puede ser el vector.
  • CVE-2026-18408 (CVSS 8.8): el comando \unrestrict de psql permite a un superusuario ejecutar código arbitrario en el cliente psql, no en el servidor.
  • CVE-2026-14664, 14669, 14670, 14676 (CVSS 8.8): overflows en el motor de regexp, en to_char, en plperl y en pg_stat_statements —extensiones y funciones que están prendidas en casi cualquier instalación real.
  • CVE-2026-6464 (CVSS 8.1): un COPY FROM STDIN que falla temprano hace que psql interprete las líneas de datos como comandos. Peligroso en scripts de carga automatizados.
  • CVE-2026-6471 (CVSS 7.2): el decoding lógico puede hacer dlopen de un archivo arbitrario —relevante si tenés replicación lógica o CDC.

Hay también un par más silenciosos pero incómodos: CVE-2026-14663 (CVSS 6.5) hacía que pgcrypto "encriptara" a texto plano cuando el cifrado estaba deshabilitado en OpenSSL —es decir, datos que creías cifrados podían no estarlo— y CVE-2026-14672 expone un oráculo de existencia de usuarios vía discrepancia en scram_iterations.

¿De dónde viene esta tanda y qué la impulsó?

Viene del ciclo normal de releases trimestrales de PostgreSQL, pero con dos particularidades. Primero, es acumulativa sobre todas las ramas vivas (14 a 18), así que no importa qué versión corras: hay parche. Segundo, según el anuncio oficial, la 18.5 se saltó por una regresión detectada antes de publicar, y por eso la rama 18 pasó directo de 18.4 a 18.6.

El otro motor es el calendario: PostgreSQL 19 está en la recta final. La Beta 3 es la tercera ronda de testing público antes de los release candidates, y el equipo pide explícitamente probarla contra cargas reales (en entornos aislados) para reportar bugs mientras todavía se pueden arreglar sin romper compatibilidad. Esta beta, respecto de la 2, revirtió el GROUP BY ALL y ajustó cosas de replicación lógica de secuencias y de las tablas temporales con FOR PORTION OF.

¿Qué implica esto para una base en producción hoy?

Que tenés que actualizar el binario cuanto antes, y que en algunos casos el update no termina con reiniciar el servicio. Como toda actualización menor de PostgreSQL, es acumulativa: parás el servidor, reemplazás los binarios y arrancás. No hay dump/reload ni pg_upgrade para pasar de 18.4 a 18.6. Pero hay tres correcciones de esta tanda que solo tienen efecto completo si hacés un paso manual después:

  • Índices GIN construidos en paralelo: un bug dejaba reltuples en Infinity o NaN, lo que frena el autovacuum/autoanalyze de esas tablas. Revisá y corré ANALYZE en las afectadas.
  • Índices btree_gist sobre columnas float o bit: requieren REINDEX INDEX para tomar el fix de ordenamiento y manejo de NaN.
  • Índices ltree con 14.653 labels o más: también piden REINDEX por un overflow en las comparaciones.

Para el primer caso, esta consulta te dice qué tablas con índice GIN quedaron con reltuples raro:

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
JOIN pg_index i ON t.oid = i.indrelid
JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

Y las corregís con un ANALYZE nombre_tabla; en cada una. Un detalle operativo aparte: la tanda actualiza los datos de zona horaria a tzdata 2026c (Alberta pasa a UTC-06 permanente, Marruecos a UTC+00), así que si tenés lógica sensible a cambios de horario, vale revisarlo.

¿PostgreSQL 14 sigue estando soportada?

Sí, pero por poco: PostgreSQL 14 llega a su fin de vida (EOL) el 12 de noviembre de 2026. Después de esa fecha no recibe más parches de seguridad ni de bugs, ni siquiera para vulnerabilidades como las de esta tanda. Esta 14.24 es, en la práctica, de las últimas actualizaciones que vas a ver para esa rama. Si tenés una 14 en producción, el reloj para planificar el salto a 15+ ya arrancó.

¿Qué trae PostgreSQL 19 y por qué vale la pena mirarla desde ahora?

PostgreSQL 19 apunta a rendimiento, operación en caliente y nuevas capacidades SQL. Todavía es beta —no la pongas en producción—, pero las funciones que ya se ven en la Beta 3 marcan hacia dónde va el motor y qué conviene ir probando en staging:

  • Checksums de datos online: se pueden activar o desactivar sin reiniciar el cluster ni reinicializarlo. Hoy eso implica downtime; en la 19 deja de implicarlo.
  • Comando REPACK unificado: una forma nativa de reorganizar tablas e índices, terreno que antes cubrían herramientas externas.
  • Datos temporales con FOR PORTION OF: soporte para actualizar/borrar solo un tramo temporal de una fila, útil para históricos y versionado.
  • SQL/PGQ (property graph): consultas de grafo dentro de SQL estándar, sin sumar otra base al stack.
  • LZ4 como compresión TOAST por defecto: menos CPU que el pglz histórico para valores grandes.
  • Async I/O que escala solo: la 19 se apoya en el subsistema de I/O asíncrono que estrenó la 18, y ahora io_method=worker ajusta la cantidad de workers automáticamente entre io_min_workers y io_max_workers.

Si querés más contexto sobre las bases de la 18, tenemos la nota "PostgreSQL 18: async I/O y skip scan, qué prender en producción", que explica el subsistema de I/O sobre el que la 19 sigue construyendo.

¿Qué podés hacer hoy con todo esto?

Concreto y en orden: primero, actualizá a la menor de tu rama (18.6, 17.11, 16.15, 15.19 o 14.24) y aplicá los ANALYZE/REINDEX que correspondan. Segundo, si estás en la 14, agendá el upgrade antes de noviembre. Tercero, si te interesa la 19, levantá una instancia aislada con la Beta 3 y probá tus queries pesadas contra REPACK, checksums online y LZ4 —y reportá lo que rompa, que para eso está la beta.

¿La 18.6 requiere reiniciar o migrar la base?

Requiere reiniciar el servicio, no migrar. Es una actualización menor acumulativa: parás PostgreSQL, reemplazás los binarios y arrancás, sin pg_upgrade ni dump/reload. Lo único extra son los ANALYZE/REINDEX puntuales en índices GIN, btree_gist y ltree afectados.

¿Cuántos de los 28 CVEs permiten ejecución de código?

Aproximadamente una docena de los CVEs cerrados tienen CVSS 8.8 y terminan en ejecución de código arbitrario como el usuario del sistema operativo que corre la base, según el anuncio oficial. La mayoría son disparables por un usuario de base sin privilegios, lo que los hace especialmente peligrosos en entornos multiusuario o con SQL de terceros.

¿Puedo usar PostgreSQL 19 Beta 3 en producción?

No. La Beta 3 es una versión de prueba: no está garantizada la compatibilidad ni la estabilidad, y su formato de datos puede cambiar antes del release final. Sirve para testear tus cargas en un entorno aislado y reportar problemas, no para atender tráfico real.

¿Cuándo deja de estar soportada PostgreSQL 14?

El 12 de noviembre de 2026. Desde esa fecha no recibe más correcciones de seguridad ni de bugs. Si tenés una 14 en producción, planificá el upgrade a una rama soportada antes de ese día.

Fuentes

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

  • Performance que te sorprenderá
  • Rápida escalabilidad y sin limitaciones
  • Arquitectura de alta disponibilidad
  • Soporte experto y ejecutivos de cuenta
  • Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting

Panel de Cloud Servers de Donweb mostrando la creación de un servidor con stacks como Django, GitLab, LAMP y NodeJS