PostgreSQL CVE-2026-6460: los usuarios de la base de datos que pueden crear objetos pueden ejecutar código en el servidor

Qué ocurrió

El 12 de noviembre de 2026, el PostgreSQL Global Development Group publicó PostgreSQL 18.7, 17.12, 16.16, 15.20 y 14.25. Según The Hacker News, estas versiones corrigen 52 fallos de seguridad. El más grave es CVE-2026-6460 (CVSS 8.8), un fallo de confusión de tipos en el servidor principal.

Un usuario de la base de datos que puede crear objetos puede usar ALTER ... SET DATA TYPE para que el servidor lea un valor obsoleto como si tuviera un nuevo tipo. Otras sentencias DDL pueden hacer lo mismo, por ejemplo ALTER TABLE ... ADD COLUMN; ROLLBACK; ALTER TABLE ... ADD COLUMN. Esto permite al usuario ejecutar código arbitrario con el usuario del sistema operativo que ejecuta PostgreSQL. La corrección añade comprobaciones de versión para que el servidor pueda detectar valores que ya no coinciden con su tipo.

El investigador de seguridad Mehmet Ince ha publicado un informe técnico con un exploit funcional, que demostró en PostgreSQL 18.6. El informe incluye el SQL que bloquea un servidor sin parchear y un paso que filtra direcciones de memoria. No incluye el paso final que ejecuta un comando. Él escribió que pudo provocar el fallo con un rol de inicio de sesión de mínimos privilegios. Las fuentes no indican si una cuenta con solo los privilegios predeterminados puede llegar más lejos y ejecutar código. Red Hat afirma que el atacante necesita un inicio de sesión en la base de datos que pueda crear o modificar objetos.

El proyecto PostgreSQL no ha informado de ataques que aprovechen este fallo, y CISA no lo incluye como explotado.

Las mismas versiones corrigen otros fallos, entre ellos CVE-2026-116322, que permite a un cliente no autenticado forzar el reinicio de servidores PostgreSQL 18. También corrigen fallos en las herramientas cliente: un archivo manipulado puede hacer que pg_restore ejecute código con el usuario que lo lanza, y un servidor de origen comprometido puede hacer que psql ejecute código a través del script de restauración de la salida tar de pg_dump.

Quién está afectado

• PostgreSQL 18 anterior a 18.7, 17 anterior a 17.12, 16 anterior a 16.16, 15 anterior a 15.20 y 14 anterior a 14.25.
• Las versiones principales más antiguas también están afectadas y no recibirán actualización. PostgreSQL 14 ya ha llegado al fin de su vida útil, y 14.25 es su última versión.
• El riesgo es mayor en servidores donde hay personas en las que no confía plenamente que tienen un inicio de sesión en la base de datos que puede crear o modificar objetos. Esto incluye el alojamiento compartido, las bases de datos entregadas a clientes y las aplicaciones web cuya cuenta de base de datos es propietaria de su esquema. Si un atacante toma el control de una aplicación así, por ejemplo mediante inyección SQL, podría usar su cuenta de base de datos de esta forma.
• Servicios gestionados: el investigador compartió pruebas de concepto con AWS (RDS, Aurora), Microsoft (Azure PostgreSQL), Google (AlloyDB), Supabase, Databricks y Ubicloud. Se desconoce su estado actual de parches. Consulte los avisos de su proveedor.
• Los servidores que no ejecutan PostgreSQL no están afectados. MySQL y MariaDB no están afectados.

Qué hacer ahora

1. Haga una copia de seguridad de su configuración de PostgreSQL (por ejemplo postgresql.conf y pg_hba.conf) y asegúrese de tener una copia de seguridad actualizada de la base de datos.
2. Actualice el servidor a la versión corregida de su versión principal: 18.7, 17.12, 16.16, 15.20 o 14.25. Si utiliza paquetes de su distribución (Debian, Ubuntu, RHEL y derivadas), instale los paquetes corregidos que aparecen en el aviso de su distribución en cuanto estén disponibles. Después, use el gestor de paquetes como de costumbre (apt update && apt upgrade o dnf upgrade).
3. Actualice o recompile todas las extensiones escritas en C al mismo tiempo que el servidor. Los responsables de los paquetes RPM del proyecto advierten que las extensiones compiladas con versiones anteriores siguen cargándose, pero pueden no estar protegidas. Algunas extensiones también necesitan cambios en el código fuente. Los paquetes de extensiones en los repositorios RPM de PostgreSQL ya exigen la nueva versión menor.
4. Reinicie PostgreSQL. Si se ejecuta fuera de la unidad de servicio de su paquete, por ejemplo bajo Patroni, reinícielo manualmente justo después de actualizar.
5. Siga los pasos de reindexación del anuncio oficial de la versión. Si usa copias de seguridad incrementales, haga una nueva copia completa y base en ella las copias incrementales futuras.
6. Actualice herramientas cliente como pg_dump, pg_restore, psql, reindexdb y vacuumdb en todas las máquinas que las usen, incluidos los servidores de copias de seguridad y las estaciones de administración.
7. No use el nuevo parámetro composite_type_mismatch para desactivar las nuevas comprobaciones. El proyecto indica que hacerlo entraña riesgos de seguridad.
8. Si no puede actualizar de inmediato, tenga en cuenta que el proyecto no ofrece ninguna solución alternativa. Mientras tanto, revise qué cuentas pueden crear o modificar objetos, sobre todo las usadas por aplicaciones web o entregadas a clientes, y asegúrese de que PostgreSQL no sea accesible desde internet salvo que sea necesario.
9. Si todavía utiliza PostgreSQL 14 o una versión anterior, planifique una actualización a una versión principal con soporte.

Cómo comprobar si está afectado

• Compruebe la versión del servidor en ejecución con psql -c 'SELECT version();' o SHOW server_version;. Las versiones inferiores a 18.7, 17.12, 16.16, 15.20 o 14.25 dentro de su serie principal están afectadas.
• Compruebe los binarios y paquetes instalados con postgres -V, dpkg -l | grep postgresql o rpm -qa | grep postgresql. Reinicie el servidor si la versión en ejecución es anterior a la instalada.
• Liste las extensiones instaladas con SELECT extname, extversion FROM pg_extension; en cada base de datos. Asegúrese de que todas las extensiones en C se hayan actualizado o recompilado para la nueva versión.
• Revise los registros de PostgreSQL por caídas inesperadas de procesos del servidor, como procesos terminados por una señal. El exploit publicado hace caer los servidores sin parchear, así que estas caídas merecen una revisión detallada.

Fuentes

• https://nvd.nist.gov/vuln/detail/CVE-2026-6460
• https://www.postgresql.org/support/security/CVE-2026-6460/