Vulnerabilidad en PostgreSQL
PostgreSQL ha emitido actualizaciones para abordar una vulnerabilidad de seguridad que permite a las cuentas con el atributo REPLICATION ejecutar código arbitrario como el usuario del sistema operativo que ejecuta el servidor de la base de datos. Esta falla, identificada como CVE-2026-6471 y con un puntaje de CVSS de 7.2, ha estado presente desde que se introdujo la decodificación lógica en PostgreSQL 9.4 en 2014. Las versiones afectadas son anteriores a PostgreSQL 18.6, 17.11, 16.15, 15.19 y 14.24.
La explotación de esta vulnerabilidad requiere una cuenta con el atributo REPLICATION y un servidor que esté configurado con wal_level = logical. Herramientas de copia de seguridad, servidores en espera, change data capture (CDC) y sistemas de monitoreo suelen poseer este atributo. La corrección, lanzada el 13 de agosto, agrega un parámetro del servidor llamado output_plugin_libraries, que especifica qué bibliotecas pueden ser cargadas como plugins de salida de decodificación lógica, estableciendo por defecto 'pgoutput, test_decoding'. Cualquier instalación que utilice un plugin de salida diferente, como wal2json o decoderbufs, verá rechazada la decodificación lógica tras la actualización hasta que un administrador añada la biblioteca a esta lista y recargue la configuración del servidor.
"Anteriormente, un usuario de replicación podía seleccionar cualquier biblioteca cargable para la decodificación lógica, permitiendo diversos tipos de explotación. Para restringir esto sin romper configuraciones previas, se introdujo una lista blanca de plugins de salida permitidos", explicó el PostgreSQL Global Development Group en las notas de la versión 18.6.
El proyecto PostgreSQL ha acreditado a Vladimir Tokarev y Yu Kunpeng por reportar el problema. Tokarev detalló la vulnerabilidad en un artículo del 1 de septiembre para la firma de seguridad de datos Cyera Research, que ha denominado la falla PostGREShell. El nombre del plugin proporcionado en un comando CREATE_REPLICATION_SLOT se pasa directamente a la función que carga la biblioteca. Cyera añadió que la restricción existente de PostgreSQL sobre las rutas de plugins, que limita a los no superusuarios a un único directorio controlado por un administrador, nunca se aplica en la ruta de replicación. El analizador del protocolo de replicación acepta casi cualquier carácter dentro de un nombre de plugin entre comillas dobles, incluidos separadores de ruta y ../, lo que permite que una ruta completa del sistema de archivos llegue al cargador como se escribió.
En Windows, el servidor resuelve una ruta de red a través de Server Message Block (SMB) y obtiene la biblioteca de una máquina controlada por el atacante, sin escribir nada en el objetivo. En Linux y macOS, el mismo resultado requiere habilitar el montaje automático del Network File System (NFS). En otros contextos, el atacante necesita una forma existente de escribir un archivo en el disco del servidor. El código cargado de esta manera se ejecuta dentro del proceso de backend de la base de datos como el usuario del sistema operativo postgres. El plugin de prueba de Cyera luego escribió directamente en el catálogo de roles para convertir la cuenta de replicación en un superusuario de PostgreSQL, además de establecer tres mecanismos de persistencia que sobreviven a un reinicio del servidor.
Cyera describe el atributo REPLICATION como una credencial de bajo privilegio para copias de seguridad, pero PostgreSQL calificó la vulnerabilidad con un nivel de Privilegios Requeridos alto, una evaluación también reflejada en la propia valoración de SUSE. PostgreSQL rechazó aplicar su restricción de LOAD a la ruta de replicación. "Los usuarios de REPLICATION no estaban sujetos anteriormente a restricciones sobre las rutas de plugins de salida, lo que les permitía eludir las protecciones durante la carga", explicó Jacob Champion, autor de la corrección, en el mensaje de confirmación.
Los fallos de carga se registran en el log del servidor como ERROR: la biblioteca '...' no puede ser utilizada como un plugin de salida, con una pista que nombra la configuración, según la documentación del parámetro. Se aconseja a los administradores que sigan estos pasos: ejecutar `SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;` antes de actualizar para identificar los plugins de salida en uso, que solo mostrarán los plugins que se hayan utilizado correctamente en algún momento.
Es necesario actualizar a las versiones 18.6, 17.11, 16.15, 15.19 o 14.24, o a los paquetes de distribución equivalentes. Cualquier plugin que no sea el predeterminado debe añadirse a output_plugin_libraries y recargar la configuración con `pg_ctl reload` o `SELECT pg_reload_conf()`. No se requiere un reinicio. Establecer las output_plugin_libraries del nuevo clúster antes de ejecutar `pg_upgrade --check` al migrar desde la versión 17 o posterior es crucial, ya que la verificación falla si la lista no permite los plugins del clúster antiguo. Los paquetes corregidos están disponibles en Amazon RDS para las cinco ramas, así como en Debian, SUSE y Ubuntu. El aviso de PostgreSQL cubre las ramas soportadas del 14 al 18 y no aborda versiones anteriores. PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026, según el anuncio de la versión. La corrección upstream "requiere cambios adicionales en la configuración si se utilizan algunas extensiones", advierte el aviso de Debian, mencionando sus paquetes wal2json y decoderbufs. El USN-8653-1 de Ubuntu, que lanzó la corrección para 22.04, 24.04 y 26.04 LTS el 20 de agosto, no menciona el parámetro y solo indica a los administradores que reinicien PostgreSQL tras la actualización. Hasta el 4 de septiembre, el proyecto wal2json había actualizado su documentación para instruir a los usuarios a añadir el plugin a output_plugin_libraries, citando la CVE.