Un defecto de PostgreSQL que no se dio cuenta durante aproximadamente doce años permite a los atacantes convertir una cuenta de replicación simple en acceso completo al servidor. Descubierto por el investigador de Cyera Vladimir Tokarev y llamado «PostGREShell», CVE-2026-6471 escala el acceso de replicación de bajos privilegios a la ejecución de códigos, los derechos de superusuario permanentes y un backdoor persistente.
Un nombre de plugin no comprobado aterriza directamente en dlopen
La causa raíz se encuentra en la decodificación lógica de PostgreSQL. Cuando un cliente crea una ranura de reproducción, elige libremente el nombre del plugin de salida. Según el asesor, ese nombre se transmite a dlopen() – o a LoadLibrary() en Windows – sin ninguna validación. Utilizando las trayectorias transversales o de la UNC, un atacante puede cargar código compilado arbitrario en el proceso PostgreSQL, que luego se ejecuta con los privilegios del postgres cuenta del sistema.
El requisito: un atacante necesita una cuenta con el atributo REPLICATION, no derechos de superusuario, y el servidor debe funcionar con wal_level = logical. En Windows el ataque es completamente remoto sobre SMB, en Linux puede desencadenar a través de monturas automáticas NFS.
Superuser a través de la manipulación de catálogos y la persistencia
El código inyectado puede manipular directamente el interior pg_authid tabla para otorgarse superusuario estatus. Para la persistencia, Cyera describe la reescritura pg_hba.conf, registrarse en shared_preload_libraries y repetidamente re-aplicar privilegios. Una caza en VirusTotal ya superó 114 plugins de PostgreSQL maliciosos.
Versiones y atenuaciones afectadas
Cada liberación de 9.4 a 18 se ve afectada; el defecto, valorado CVSS 7.2, se fija en 18.6, 17.11, 16.15, 15.19 y 14.24. Los administradores deben parchear rápidamente, eliminar el atributo REPLICATION de cuentas que no lo necesitan, restringir las entradas de replicación en pg_hba.conf a direcciones conocidas, y bloquear el tráfico SMB (puerto 445) y NFS (puerto 2049) de servidores de bases de datos.
Fuentes: Cyera Research · SecurityWeek · PostgreSQL Security
