Vulnerabilidad en PostgreSQL: 12 años con la puerta abierta

Una vulnerabilidad en PostgreSQL estuvo disponible durante doce años sin que nadie la detectara. Se trata de CVE-2026-6471, bautizada PostGREShell por Cyera Research Labs, y alcanza a todas las versiones desde la 9.4 (2014) hasta la 18. El detalle incómodo: una cuenta con permisos de replicación, sin ser administradora, podía terminar ejecutando código con los privilegios del propio motor de base de datos.

Cómo funciona la vulnerabilidad en PostgreSQL

El fallo está en el mecanismo de replicación lógica. Cuando una cuenta con el atributo REPLICATION crea un slot de replicación, PostgreSQL carga el plugin de salida indicado mediante dlopen() sin validar la ruta. Ahí está el problema: nadie comprobaba de dónde venía esa librería.

Un atacante puede aprovechar ese descuido para apuntar a un archivo que no debería estar ahí. Sirven rutas relativas, recursos UNC por SMB en Windows o montajes automáticos NFS en Linux y macOS. El resultado es código propio corriendo dentro del motor, con acceso equivalente a superusuario y la posibilidad de mantener persistencia.

Doce años, dos líneas de código

Lo llamativo es la desproporción entre el impacto y la corrección. Según Cyera, el parche del equipo de seguridad de PostgreSQL consistió en dos líneas de C que validan la ruta antes de cargar el plugin. La investigación se reportó el 21 de febrero de 2026, se confirmó el 27 del mismo mes y la actualización llegó el 22 de agosto.

En cuanto a exposición, Cyera calcula más de 39.000 empresas verificadas ejecutando versiones afectadas, entre ellas plataformas del tamaño de Netflix, Instagram, Spotify o Uber. Además, durante su búsqueda de amenazas el equipo identificó 114 plugins maliciosos de PostgreSQL ya circulando, lo que sugiere que la técnica no era del todo desconocida.

Qué hacer si usas PostgreSQL

• Aplica la última versión menor de tu rama de PostgreSQL. Es la única solución real.
• Retira el atributo REPLICATION de todas las cuentas que no lo necesiten de verdad.
• Restringe la replicación en pg_hba.conf a direcciones IP de confianza.
• Bloquea el tráfico saliente por SMB (puerto 445) y NFS (puerto 2049) desde los servidores de base de datos.
• Vigila la creación de slots de replicación fuera de lo habitual.

PostGREShell deja una lección que va más allá del parche: los permisos que parecen inofensivos, como los de replicación, muchas veces esconden un camino directo al control total. Revisar quién los tiene y por qué es tan importante como actualizar.

Fuentes: Cyera Research Labs, PostgreSQL Security