PostgreSQL CVE-2026-6460: verifica el parche completo

PostgreSQL CVE-2026-6460 permite a quien puede crear objetos en la base de datos ejecutar código con los permisos del usuario del sistema operativo que ejecuta PostgreSQL. La corrección está disponible en PostgreSQL 18.7, 17.12, 16.16, 15.20 y 14.25. Para un equipo pequeño de SaaS, hay un detalle decisivo: actualizar solo el servidor puede dejar el trabajo a medias. PostgreSQL indica que, para obtener una protección completa, también hay que recompilar las extensiones escritas en C; algunas necesitan cambios en el código fuente. Comprueba el despliegue en ejecución y sus extensiones antes de dar por resuelta la vulnerabilidad. (Aviso de seguridad, notas de la versión.)

Un ingeniero actualiza la imagen de la base de datos, la aplicación vuelve a conectarse y la tarea del parche parece lista para cerrarse. Es un buen comienzo. Pero queda una pregunta: ¿incluye el sistema desplegado todos los componentes de la corrección?

Esta versión da un motivo concreto para preguntárselo. El servidor incorpora comprobaciones para los valores compuestos cuya estructura ya no coincide con el tipo utilizado para interpretarlos. Las extensiones nativas también intervienen en esa comprobación. Un reinicio sin errores y el número de versión esperado no bastan para demostrar que esas extensiones se han recompilado correctamente.

El trabajo consiste en reunir pruebas suficientes para explicar qué se ha actualizado, qué está en ejecución y qué dudas quedan. Así puedes hacerlo sin convertir una actualización menor de seguridad en una migración innecesaria de la base de datos.

Determina qué acceso requiere la vulnerabilidad

La condición previa que señala el aviso, poder crear objetos, debe guiar tu evaluación de la exposición. Quien puede crear objetos en la base de datos tiene una relación con PostgreSQL distinta de la de un cliente que solo puede utilizar los formularios de tu aplicación.

En tu despliegue, identifica quién puede conectarse a la base de datos y crear objetos: roles de la aplicación, roles de migración, desarrolladores, automatizaciones y cualquier acceso SQL que ofrezcas a clientes. Incluye los permisos efectivos obtenidos por pertenecer a otros roles. Si usuarios con un menor nivel de confianza pueden ejercer esas capacidades, comunícaselo a quien programa la aplicación del parche.

Esto es un inventario de accesos, no una mitigación completa. No des por hecho que bloquear una operación SQL concreta resuelve el problema; PostgreSQL describe varias vías mediante DDL. Del mismo modo, que el servidor ejecute una versión afectada no demuestra por sí solo que un visitante sin autenticar pueda explotar tu aplicación SaaS. Necesitas pruebas de la vía que lleva desde ese visitante hasta la capacidad requerida en la base de datos. (Aviso de PostgreSQL.)

Delimita también el impacto con precisión. Ejecutar código con los permisos del usuario del sistema operativo de PostgreSQL es grave. Que eso permita administrar el servidor, acceder a los datos de otro cliente o alcanzar otro servicio depende del despliegue que lo rodea. Ninguno de esos efectos adicionales debe figurar como un hecho demostrado en el registro del incidente sin pruebas que lo respalden.

Para un equipo pequeño, esta evaluación puede recogerse en una nota breve: qué base de datos está afectada, qué roles intervienen, quién se encarga de actualizarla y qué accesos siguen bajo investigación. Si necesitas pasar del mantenimiento a la respuesta a incidentes, un plan de respuesta a incidentes de una página ayuda a dejar claras las responsabilidades.

Elige la versión corregida de tu rama actual

El aviso del proyecto enumera estas primeras versiones menores corregidas, publicadas el 12 de noviembre de 2026:

Fuente: aviso de CVE-2026-6460.

Empieza por la versión correspondiente a tu rama principal actual. PostgreSQL distingue entre una actualización menor y un cambio de versión principal: las versiones menores conservan el formato de almacenamiento de los datos y, por lo general, requieren detener el servidor, instalar los binarios actualizados y reiniciarlo. Un cambio de versión principal tiene su propio proceso de migración. Lee siempre las notas de la versión para conocer los pasos adicionales, incluidas las de las versiones que te hayas saltado. (Política de versiones.)

Por ejemplo, pasar un despliegue de PostgreSQL 17 a 17.12 es una tarea distinta de pasarlo a PostgreSQL 18. Gestiona el parche urgente y cualquier cambio de versión principal previsto como cambios separados, cada uno con sus propios criterios de aceptación.

Un servicio gestionado o una distribución pueden ofrecer la corrección adaptada a una versión anterior con otro identificador de compilación. En ese caso, pide pruebas que vinculen la compilación desplegada con esta CVE. Que la cadena de versión difiera de la versión corregida del proyecto es un motivo para investigar, no información suficiente para declarar que el servicio está corregido o es vulnerable.

Incluye las extensiones nativas en la actualización

El requisito relativo a las extensiones es el detalle con más probabilidades de perderse entre el aviso, la tarea de despliegue y el comentario de cierre.

Las notas de PostgreSQL indican que la protección completa requiere recompilar las extensiones escritas en C y que algunas necesitarán cambios en el código fuente. También describen composite_type_mismatch, un parámetro del servidor que permite desactivar las nuevas comprobaciones, con los riesgos de seguridad que ello conlleva. Por tanto, la compatibilidad de las extensiones y la configuración de la protección deben constar en el registro del parche. (Notas de PostgreSQL 17.12.)

Antes de desplegar, pregunta al responsable de la imagen, al distribuidor de paquetes o al proveedor de la base de datos cómo se ha tenido en cuenta el cambio al compilar sus extensiones. Para las extensiones que compila tu equipo, asigna a alguien la comprobación de compatibilidad y la creación de la compilación de sustitución. No des por hecho que instalar el último paquete del servidor también sustituye todos los componentes nativos que se cargan en él.

Puedes obtener un inventario inicial con consultas SQL de solo lectura:

SELECT version();
SHOW server_version;
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Ejecútalas contra el punto de conexión de la base de datos que quieras verificar. PostgreSQL documenta la información de versión del servidor en sus funciones de información del sistema; la versión de un cliente instalado en tu portátil responde a otra pregunta.

La lista de extensiones te ayuda a identificar las tareas pendientes. Sus etiquetas de versión no demuestran que se hayan recompilado los binarios nativos subyacentes. Acompaña la lista de un registro del paquete, la imagen, la compilación o el proveedor que permita comprobar el cumplimiento del requisito de las extensiones. Si alguien ha desactivado las nuevas comprobaciones para que funcione una extensión, deja constancia explícita de esa decisión de seguridad pendiente de resolver.

Distingue las tareas del operador de las pruebas que necesita tu equipo

Si alojas PostgreSQL en tu propia infraestructura, tu equipo puede encargarse de los binarios o la imagen del servidor, las extensiones, el reinicio y las comprobaciones de la aplicación. En un servicio gestionado, el proveedor puede asumir la mayoría de esas operaciones. Aun así, debe haber alguien en tu equipo responsable de reunir las pruebas.

Plantea al proveedor una pregunta que pueda responder para tu despliegue: ¿incluye la compilación actual de este servicio la corrección de CVE-2026-6460 y cómo se han tratado sus extensiones nativas? Pregunta si el cliente debe realizar alguna tarea de mantenimiento y si la nueva protección está activada. Guarda la respuesta junto con el identificador del servicio y el registro de mantenimiento.

El análisis técnico del investigador explica por qué los servicios gestionados de PostgreSQL formaron parte de la investigación. No demuestra el estado actual del parche en tu proveedor o instancia. Úsalo como contexto; para cerrar la tarea, utiliza pruebas específicas del despliegue.

El mismo rigor se aplica a la infraestructura que opera tu equipo. Cambiar la referencia de una imagen expresa una intención. Un registro de despliegue y una consulta al servidor en ejecución ayudan a comprobar el resultado. Repite la comprobación en las instancias y los puntos de conexión pertinentes, en lugar de tomar una conexión correcta como prueba de que toda la infraestructura está actualizada.

Cierra la tarea con un registro breve de las pruebas

Un comentario de cierre útil permite a otro ingeniero entender el resultado sin reconstruir el despliegue a partir de mensajes de chat.

Elige las comprobaciones de la aplicación según lo que hace tu producto: conectarse, leer y escribir datos representativos y ejecutar funciones importantes que dependan de extensiones. Son comprobaciones de aceptación del cambio, no una prueba de que se cumplen todas las propiedades de seguridad.

Si se desconoce el estado de compilación de una extensión, deja ese punto abierto. Si el proveedor confirma una corrección adaptada a una versión anterior, conserva la referencia exacta de su compilación. Es el mismo principio que explica cómo verificar la corrección en los sistemas dependientes: importan tanto lo que has cambiado como los sistemas que dependen de ello.

Si gestionas la vulnerabilidad en Kit, su flujo de triaje de informes permite reunir la asignación del informe, la correspondencia y la decisión humana de verificar la corrección. Tu equipo de infraestructura o tu proveedor aportan las pruebas del parche que sustentan esa decisión.

Mantén visibles las tareas posteriores a la actualización

La versión de noviembre también contiene correcciones con sus propios requisitos de mantenimiento. Revisa las notas de migración de la rama correspondiente para conocer las acciones de reparación de índices y copias de seguridad que puedan aplicarse. Para los equipos que utilizan copias de seguridad incrementales, PostgreSQL recomienda expresamente realizar una nueva copia completa después de actualizar y utilizarla como base de las siguientes copias incrementales. Son tareas posteriores a la actualización; no significan que CVE-2026-6460 haya dañado tus índices o copias de seguridad. (Anuncio de la versión.)

PostgreSQL 14 añade otra decisión: 14.25 es su última versión y el proyecto ha anunciado el fin de su soporte. Aplica la corrección disponible mientras planificas el paso a una versión principal con soporte. Asigna un responsable y un calendario a esa migración, en lugar de incorporarla sin más al parche urgente.

El registro del parche debe terminar con una relación clara de las pruebas: la compilación del servidor desplegada, el estado de recompilación de las extensiones, la configuración de la protección y cualquier tarea pendiente. Así, el siguiente ingeniero tendrá algo concreto que revisar y tu equipo dispondrá de una razón fundamentada para cerrar la tarea.