PostgreSQL corrige 52 fallos: qué versión debe usar tu web

El proyecto PostgreSQL publicó el 12 de noviembre de 2026 las versiones 18.7, 17.12, 16.16, 15.20 y 14.25. Corrigen 52 fallos de seguridad, 32 de ellos con una gravedad de 8,8 sobre 10, y ponen fin al soporte de PostgreSQL 14. Afecta a webs y aplicaciones que guardan sus datos en PostgreSQL.

Lo que se sabe

  • Las versiones: según el anuncio del PostgreSQL Global Development Group, salieron el 12 de noviembre de 2026 para las cinco ramas con soporte: 18.7, 17.12, 16.16, 15.20 y 14.25. Con ellas llegó la segunda versión candidata de PostgreSQL 19.
  • Cuántos fallos: el anuncio lista 52 vulnerabilidades, cada una con su CVE, y más de 140 errores corregidos. Según esa lista, 32 tienen una puntuación CVSS de 8,8 y la mayoría de esas permiten ejecutar código.
  • El más citado (CVE-2026-6460): según su ficha en postgresql.org, una confusión de tipos permite a un usuario con permiso para crear o modificar objetos ejecutar código con el usuario del sistema operativo que corre la base de datos. Hace falta una cuenta con ese permiso. Afecta a las ramas 14 a 18 antes de las versiones corregidas.
  • Uno sin contraseña (CVE-2026-116322): solo afecta a PostgreSQL 18 antes de la 18.7. Según su ficha, un cliente sin autenticar que llegue al servidor por la red puede forzar un reinicio. No expone datos, pero corta el servicio. Gravedad 5,3.
  • Fin de PostgreSQL 14: el anuncio dice que la 14.25 es la última versión de esa rama y que ya no recibirá arreglos. La tabla oficial de versiones marca el fin de la 15 para el 11 de noviembre de 2027.
  • PostgreSQL 19: la versión estable está prevista para el 19 de noviembre de 2026, salvo que haga falta otra versión candidata.
  • Ataques: el anuncio no habla de explotación en curso.

Qué cambia y qué no

Cambia que todas las ramas con soporte tienen arreglos que conviene aplicar ya, y que quien siga en PostgreSQL 14 o en una versión anterior se queda sin parches. Como muchos de los fallos graves exigen una cuenta con ciertos permisos, el riesgo es mayor, según la lectura de este artículo, donde varias aplicaciones o clientes comparten un servidor o donde una aplicación se conecta con más permisos de los que necesita.

No cambia la forma de actualizar dentro de la misma rama: el anuncio indica que son versiones acumulativas y que basta con parar el servicio y cambiar los binarios, sin volcar y recargar los datos ni usar pg_upgrade. Lo que sí añade son tareas después de actualizar en casos concretos.

Cómo saber si te afecta

  1. Averigua si tu web usa PostgreSQL. WordPress funciona con MySQL o MariaDB, así que una web de WordPress normal no está afectada. Drupal puede usar PostgreSQL: en el archivo `settings.php`, la conexión lo dice con `'driver' => 'pgsql'`. Muchas aplicaciones a medida y plataformas de base de datos gestionada también funcionan sobre PostgreSQL. Si no lo sabes, pregúntale a quien mantiene tu web.
  2. Mira la versión del servidor. Con acceso a la base, la consulta `SHOW server_version;` devuelve el número. Está al día si es igual o superior a 18.7, 17.12, 16.16, 15.20 o 14.25 dentro de su rama. Ojo: `psql --version` muestra la versión del programa cliente, no la del servidor.
  3. Si estás en la 14 o antes, planifica el salto. La 14.25 cierra la rama. Pasar a la 15 o superior sí es un cambio de versión mayor, con pg_upgrade o con volcado y recarga, así que conviene probarlo antes en una copia de la web.
  4. Si la base es gestionada o está en tu hosting, pregunta. Si no administras el servidor, pide al proveedor la versión exacta, la fecha en que aplica las versiones corregidas y qué plan tiene para quien siga en la 14.
  5. Revisa las tareas de después. El anuncio pide reindexar en casos concretos: índices GIN si se sospecha corrupción, índices GiST con `gist_trgm_ops` (de la extensión pg_trgm, habitual en buscadores internos por similitud) e índices B-tree sobre columnas `bpchar` sin longitud. También pide revisar las restricciones `NOT NULL NO INHERIT` en tablas particionadas y, si se usan copias incrementales, hacer una copia completa nueva tras actualizar.
  6. Ajusta los permisos. Comprueba que el usuario con el que se conecta tu web tiene solo los permisos que necesita y no es superusuario. Ayuda a limitar daños, pero no sustituye a actualizar.

Relacionado: Apache 2.4.71 corrige un fallo crítico en HTTP/2

Fuentes

Actualizaciones: cuando salga PostgreSQL 19 estable o haya novedades sobre estos fallos, se añadirán aquí con su enlace.