Qué hacen estas dos vulnerabilidades
CVE-2026-6471 (CVSS 7.2) afecta al mecanismo de decodificación lógica introducido en PostgreSQL 9.4. Una cuenta con el atributo REPLICATION puede especificar un plugin de salida arbitrario al crear un slot de replicación lógica. Antes del parche, PostgreSQL cargaba el archivo solicitado mediante dlopen sin verificar su procedencia, lo que permitía ejecutar código con los privilegios de la cuenta del sistema postgres. El atacante no necesita acceso de red directo a su instancia: basta con un par de replicación comprometido, una herramienta CDC o un usuario interno con el atributo REPLICATION. El parche añade un parámetro output_plugin_libraries que enumera las librerías permitidas — por defecto pgoutput y test_decoding únicamente.
CVE-2026-14669 (CVSS 8.8) es un desbordamiento de buffer en el heap en la función to_char(timestamptz). La función construye un buffer de trabajo a partir de la cadena de formato, pero las rutas de procesamiento de zonas horarias POSIX copian la abreviatura proporcionada por el usuario en ese buffer sin verificar la longitud. Cualquier usuario autenticado ordinario puede activar la vulnerabilidad pasando una abreviatura de zona horaria excesivamente larga, lo que sobrescribe estructuras adyacentes del heap y desvía la ejecución para lograr ejecución de código arbitrario con los privilegios del usuario de sistema postgres.
Comparativa de los dos CVE
Desplace la tabla
| Criterio | CVE-2026-6471 | CVE-2026-14669 |
|---|---|---|
| Puntuación CVSS | 7.2 (Alto) | 8.8 (Alto) |
| Componente | Decodificación lógica | `to_char(timestamptz)` |
| Vector de ataque | Red | Red |
| Privilegio mínimo requerido | Atributo REPLICATION | Usuario autenticado |
| ¿Requiere acceso público? | No | No |
| Tipo de impacto | Ejecución de código arbitrario | Ejecución de código arbitrario |
| Fecha de corrección | 2026-08-13 | 2026-08-13 |
Versiones afectadas y versiones corregidas
Ambos CVE afectan a todas las ramas mantenidas de PostgreSQL. Las versiones corregidas, publicadas simultáneamente el 13 de agosto de 2026, son: PostgreSQL 18.6, 17.11, 16.15, 15.19 y 14.24. Cualquier instancia que funcione con una versión anterior a estos números está expuesta. PostgreSQL 13 y anteriores han alcanzado el fin de vida y ya no reciben parches. Las aplicaciones que incluyen PostgreSQL — Supabase, NocoDB, Gitea, Twenty CRM, Planka — están afectadas si aún no han actualizado su imagen base.
Antes del parche: auditar los roles de replicación
Antes de aplicar el parche, conviene saber cuántas cuentas tienen el atributo REPLICATION en sus instancias. La siguiente consulta lista todos los roles afectados:
SELECT rolname, rolreplication, rolsuper FROM pg_roles WHERE rolreplication = true OR rolsuper = true ORDER BY rolsuper DESC, rolname;
Si encuentra cuentas con REPLICATION que no sirven para una replicación activa (backup, CDC, monitorización), revoque el atributo: ALTER ROLE nombre_del_rol NOREPLICATION;. Es una medida de mitigación parcial mientras se espera el parche, y una buena práctica permanente.
Parchear mediante apt en Debian y Ubuntu
Verificar la versión actual
Conéctese a su instancia y compruebe la versión actual:
psql -U postgres -c 'SELECT version();'. Anote la rama (14, 15, 16, 17 o 18) para instalar el paquete de destino correcto.Asegurarse de que el repositorio PGDG está configurado
Los repositorios estándar de Debian y Ubuntu suelen incluir versiones desactualizadas. Para obtener los parches más recientes, utilice el repositorio oficial de PostgreSQL. Si aún no está configurado:
sudo apt install -y postgresql-common && sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh.Actualizar los paquetes
Una actualización menor (17.10 → 17.11, 16.14 → 16.15, etc.) no requiere
pg_upgradeclustery conserva sus datos en su lugar. Ejecute:sudo apt update && sudo apt install postgresql-17(sustituya17por su rama). Para otras ramas:sudo apt install postgresql-16,postgresql-15,postgresql-14según corresponda.Reiniciar el servicio
El servicio debe reiniciarse para cargar el nuevo binario:
sudo systemctl restart postgresql. A continuación, verifique que el servicio se ha reiniciado correctamente:sudo systemctl status postgresql.Confirmar la versión después del parche
Vuelva a conectarse y verifique que la versión mostrada corresponde al parche:
psql -U postgres -c 'SELECT version();'. Debería ver 17.11, 16.15, 15.19, 14.24 o 18.6 según su rama.
Parchear mediante Docker
Descargar la imagen corregida
Las imágenes oficiales
postgresen Docker Hub han sido actualizadas con las versiones corregidas. Descargue la imagen correspondiente a su rama:docker pull postgres:17.11, o con la etiqueta menor de su rama (postgres:16.15,postgres:15.19,postgres:14.24). Para imágenes Alpine:docker pull postgres:17.11-alpine.Reiniciar el contenedor
Si usa Docker Compose, actualice la etiqueta de imagen en su
docker-compose.ymly luego:docker compose pull && docker compose up -d. Para un contenedor lanzado directamente:docker stop postgres-container && docker rm postgres-container, y luego relánzelo con la nueva imagen. Sus datos permanecen en el volumen montado — verifique que el volumen está declarado antes de eliminar el contenedor.Verificar la versión dentro del contenedor
Conéctese al contenedor y confirme la versión:
docker exec -it postgres-container psql -U postgres -c 'SELECT version();'. La salida debe mostrar la versión corregida.
Medidas de mitigación si el parche es temporalmente imposible
Si no puede reiniciar la instancia de inmediato, tres medidas reducen la exposición a CVE-2026-6471 sin aplicar el parche:
Primero, revocar el atributo REPLICATION de las cuentas que no lo necesitan (ALTER ROLE nombre NOREPLICATION;). Segundo, restringir las entradas de replicación en pg_hba.conf a las direcciones IP de los pares legítimos únicamente — sustituir una regla host replication all 0.0.0.0/0 por entradas específicas para cada host autorizado. Tercero, si su instancia no usa la replicación lógica en absoluto, puede establecer wal_level = replica en postgresql.conf — esto deshabilita la decodificación lógica y cierra el vector de ataque de CVE-2026-6471.
Para CVE-2026-14669, no hay ninguna mitigación a nivel de aplicación documentada: el único remedio es actualizar el binario.
Verificar las aplicaciones que incluyen PostgreSQL
Supabase, NocoDB, Gitea, Twenty CRM y Planka incluyen PostgreSQL en sus imágenes Docker o charts de Helm. Para estas aplicaciones, actualizar PostgreSQL significa actualizar la imagen de la aplicación en sí. Consulte las notas de versión de cada aplicación: desde el 13 de agosto de 2026, las distribuciones que publicaron una actualización deberían haber integrado PostgreSQL 17.11, 16.15 o equivalente. Si no hay actualización disponible para su aplicación, puede desplegar un contenedor PostgreSQL separado en la versión corregida y apuntar la aplicación hacia él.
El comando SELECT version(); en psql no es suficiente para confirmar que el parche está activo si coexisten varios binarios de PostgreSQL en el mismo host. Verifique qué binario está ejecutándose realmente: pg_lsclusters en Debian/Ubuntu lista todos los clústeres con su versión. Asegúrese de que el clúster activo usa el binario actualizado, no un binario residual de una instalación anterior.
Desplegar PostgreSQL con acceso root para aplicar parches usted mismo
En un alojamiento compartido o en un entorno PaaS, no tiene acceso al binario de PostgreSQL: la actualización depende de su proveedor. En un VPS con acceso root, usted aplica este parche en menos de diez minutos, sin depender de terceros. Usted elige la ventana de reinicio, mantiene el control sobre pg_hba.conf y audita sus propios roles de replicación. Este es el modelo que se aplica de forma natural a cualquier stack auto-alojado.
