PostgreSQL ha publicado actualizaciones de seguridad que corrigen la vulnerabilidad CVE-2026-6471 (CVSS 7.2) en el mecanismo de logical decoding. El fallo permite que una cuenta de base de datos con el atributo REPLICATION cargue una biblioteca arbitraria y ejecute código con la identidad del usuario de sistema bajo el que se ejecuta el servidor. Se ven afectadas todas las ramas soportadas: PostgreSQL 14, 15, 16, 17 y 18 hasta las versiones 14.24, 15.19, 16.15, 17.11 y 18.6, respectivamente. La corrección, publicada el 13 de agosto de 2026, introduce un nuevo parámetro de configuración que puede interrumpir el funcionamiento de plugins de terceros tras la actualización si el administrador no realiza un ajuste adicional.
Naturaleza de la vulnerabilidad y vector de ataque
Según el boletín oficial de seguridad de PostgreSQL, el problema se clasifica como una ausencia de autorización en el núcleo del servidor durante el logical decoding. Un usuario con el privilegio REPLICATION podía indicar una biblioteca cargable arbitraria como plugin de salida, sin las comprobaciones que se aplican a las operaciones habituales de carga de bibliotecas mediante el comando LOAD.
Vector CVSS oficial: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H — vector de ataque por red, baja complejidad de explotación, pero altos requisitos de privilegios. El impacto se evalúa como alto en los tres parámetros: confidencialidad, integridad y disponibilidad. Para la explotación se requieren dos condiciones: una cuenta con el atributo REPLICATION y una configuración del servidor con el parámetro wal_level = logical.
El atributo REPLICATION se asigna a menudo a cuentas de servicio: herramientas de copia de seguridad, servidores réplica, pipelines de captura de cambios de datos (CDC) y sistemas de monitorización. Esto amplía la superficie de ataque potencial, pese al nivel formalmente alto de privilegios requeridos.
Mecanismo de corrección: parámetro output_plugin_libraries
Tal como se indica en las notas de la versión PostgreSQL 18.6, la corrección introduce el parámetro de servidor output_plugin_libraries, una lista blanca de bibliotecas que está permitido cargar como plugins de salida de logical decoding. El valor por defecto es 'pgoutput, test_decoding'.
Esto significa que, después de la actualización, cualquier plugin de terceros —incluidos los ampliamente utilizados wal2json y decoderbufs— será rechazado por el servidor mientras el administrador no lo añada explícitamente a la lista y no recargue la configuración. Al rechazarse, en el registro del servidor aparece el mensaje: ERROR: library "..." may not be used as an output plugin con una referencia al parámetro output_plugin_libraries.
El autor de la corrección, Jacob Champion, explicó en el commit que las restricciones estándar de LOAD no se aplicaron deliberadamente a la ruta de replicación: su introducción retroactiva habría exigido instalar todos los plugins de terceros en el directorio $libdir/plugins, lo que habría roto las instalaciones existentes.
Quién está en riesgo
La vulnerabilidad afecta a cualquier instalación de PostgreSQL versiones 14–18 en la que se cumplan simultáneamente dos condiciones: exista una cuenta con el atributo REPLICATION y el servidor funcione con wal_level = logical. Esta es una configuración típica para:
- Sistemas de replicación lógica entre clústeres de PostgreSQL
- pipelines CDC (Debezium, Kafka Connect y análogos)
- Herramientas de copia de seguridad basadas en logical decoding
- Plataformas de monitorización que utilizan slots de replicación
El código cargado mediante la explotación de la vulnerabilidad se ejecuta dentro del proceso del servidor con la identidad del usuario de sistema postgres, lo que potencialmente otorga al atacante control total sobre los datos y la posibilidad de afianzarse en el sistema.
Recomendaciones prácticas
Secuencia de acciones durante la actualización, según la documentación de PostgreSQL:
- Inventario de plugins: antes de actualizar, ejecute la consulta:
SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;La consulta mostrará los plugins que se hayan utilizado con éxito en algún momento. - Actualización a PostgreSQL 18.6, 17.11, 16.15, 15.19 o 14.24. Los paquetes están disponibles en los principales distribuidores: Amazon RDS (desde el 25 de agosto), Ubuntu (22.04, 24.04, 26.04 LTS), Debian y SUSE.
- Añadir los plugins de terceros a
output_plugin_librariesy recargar la configuración con el comandopg_ctl reloadoSELECT pg_reload_conf();; no es necesario reiniciar el servidor. - Al migrar desde PostgreSQL 17 o superior mediante pg_upgrade: establezca
output_plugin_librariesen el nuevo clúster antes de ejecutarpg_upgrade --check; de lo contrario, la comprobación finalizará con error si los slots del clúster antiguo usan plugins que no figuren en la lista.
Medidas temporales antes de la actualización
- Revocar el atributo REPLICATION de las cuentas que no lo necesiten
- Restringir en
pg_hba.conflos registros de replicación a direcciones IP conocidas - Bloquear el tráfico saliente desde los servidores de bases de datos en los puertos 445 (SMB) y 2049 (NFS)
Estado de explotación y cuestiones abiertas
En el momento de la publicación, no se ha confirmado la explotación activa de CVE-2026-6471. No se ha encontrado código público para reproducir el ataque en repositorios abiertos. La vulnerabilidad fue descubierta por los investigadores Vladimir Tokarev y Yu Kunpeng, tal como se indica en el anuncio oficial de la versión.
Debe tenerse en cuenta que PostgreSQL 14 —la última rama afectada— dejará de recibir actualizaciones de seguridad el 12 de noviembre de 2026. Las organizaciones que aún trabajen con esta versión deberían planificar la migración a una rama más reciente.
La actualización a las versiones corregidas de PostgreSQL debe realizarse con carácter prioritario, especialmente en los servidores con wal_level = logical. Es crítico no limitarse a instalar el parche: es necesario revisar la lista de plugins de salida utilizados, añadirlos a output_plugin_libraries y asegurarse de que la replicación lógica y los pipelines de CDC siguen funcionando tras la actualización. Omitir este paso provocará el fallo del logical decoding: un problema operativo, pero predecible y fácilmente solucionable.
