PostgreSQL corrige 52 vulnerabilidades y deja sin soporte a la versión 14

0 0 votos

Valora la Publicación

El proyecto PostgreSQL publicó el 12 de noviembre las versiones 18.7, 17.12, 16.16, 15.20 y 14.25, que corrigen 52 vulnerabilidades y más de 140 errores. La mayoría de las fallas tienen un puntaje CVSS de 8.8 sobre 10 y permiten ejecutar código en el servidor con un usuario de base de datos común.

La misma publicación avisa que 14.25 es la última versión de PostgreSQL 14: desde ahora no recibe más parches de seguridad. No se conocen ataques que exploten estas fallas, pero ya hay detalles técnicos públicos de una de ellas.

Qué se corrigió

PostgreSQL es la base de datos de código abierto que usan muchísimas aplicaciones, y la que está detrás de servicios administrados como Amazon RDS y Aurora, Azure Database for PostgreSQL, Google Cloud SQL y AlloyDB, o Supabase.

Casi todas las vulnerabilidades son de memoria: el servidor lee un dato como si fuera de otro tipo (confusión de tipos), usa memoria que ya liberó o escribe fuera del espacio reservado. Un usuario que puede conectarse y correr consultas arma una secuencia a propósito y termina corriendo su propio código con los permisos del proceso de la base.

Las que más importan, según el anuncio oficial de PostgreSQL:

CVE-2026-6460 (CVSS 8.8): confusión de tipos después de un ALTER ... SET DATA TYPE. Es el arreglo general para una familia de fallas que viene de un cambio de 2004.
Casi 30 CVE más con CVSS 8.8 y ejecución de código con privilegios bajos, entre ellas varias en los lenguajes de procedimientos plperl y pltcl, en plpgsql, en dblink y en las funciones de búsqueda de texto.
CVE-2026-116314 y CVE-2026-116330 (CVSS 8.8): pg_restore y la restauración de un backup en formato tar pueden ejecutar código si alguien restaura un archivo armado por un atacante. No piden usuario, pero sí que la víctima restaure ese archivo.
CVE-2026-120145 (CVSS 8.8): un servidor que publica datos por replicación lógica puede escribir en las tablas de sistema del suscriptor y ejecutar código ahí.
CVE-2026-116322 (CVSS 5.3): un pedido de cancelación sin autenticación puede trabar el servidor. Solo afecta la disponibilidad.

La falla de 22 años

El investigador Mehmet Ince publicó el 9 de noviembre cómo convirtió CVE-2026-6460 en ejecución remota de código. Según su análisis, el origen es un cambio de mayo de 2004 que permitió cambiar el tipo de una columna, y lo pudo disparar con el rol de menor privilegio que puede iniciar sesión.

Ince dice que probó servicios administrados de varios proveedores y que no encontró ninguno que no estuviera afectado. Compartió las pruebas de concepto con los proveedores en privado; su texto muestra el mecanismo, pero no publica un exploit completo.

Por qué importa aunque la base no esté en internet

Ninguna de las fallas graves deja entrar a alguien sin usuario. El riesgo está en quién ya tiene una cuenta: una aplicación comprometida, un usuario de reportes, un proveedor, o los clientes de una plataforma que da bases de datos compartidas.

Con estas fallas, cualquiera de esas cuentas puede pasar de leer sus tablas a controlar el servidor. Por eso pegan más fuerte en entornos multiusuario y en servicios que venden PostgreSQL administrado.

PostgreSQL 14 queda sin soporte

La comunidad mantiene cada versión mayor durante cinco años. La 14 salió en septiembre de 2021 y la 14.25 es su último parche: cualquier vulnerabilidad nueva ya no se va a corregir ahí.

Pasar de una versión mayor a otra (de 14 a 17 o 18) no es un parche: pide pg_upgrade o un pg_dump y restauración, pruebas de la aplicación y una ventana de mantenimiento. PostgreSQL 19 está en su segunda versión candidata y la versión final está prevista para el 19 de noviembre.

Qué hacer

Actualizar a 18.7, 17.12, 16.16, 15.20 o 14.25. Es una actualización menor: alcanza con frenar el servicio, cambiar los binarios y reiniciar, sin migrar datos.
En servicios administrados, revisar la ventana de mantenimiento y si el proveedor ya aplicó la versión nueva, o pedir la actualización.
Seguir los pasos posteriores del anuncio cuando apliquen: reindexar los índices GIN y los GiST con gist_trgm_ops si hay sospecha de corrupción, reindexar los B-tree sobre columnas bpchar sin largo y hacer un backup completo nuevo si usan backups incrementales.
Revisar qué cuentas pueden conectarse y crear objetos, y sacar los lenguajes plperl o pltcl donde no se usen.
No restaurar con pg_restore archivos de origen dudoso hasta actualizar las herramientas cliente.
Si siguen en PostgreSQL 14, armar el plan de migración a una versión con soporte.

¿Cuántas de sus bases siguen en PostgreSQL 14?

Entre las bases propias, las de cada proveedor y las que quedaron olvidadas en algún servidor, el inventario suele dar sorpresas. ¿Ya saben qué versión corre cada una? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →