📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Cada semana hago lo mismo en mi flota de VPS: aplicar los parches del sistema, revisar que no haya nada raro en los logs, y los updates de base de datos los dejo para el final, con calma. Esta vez esa calma casi me pesó. El 12 de noviembre el proyecto PostgreSQL publicó 18.7, 17.12, 16.16, 15.20 y 14.25 para cerrar una falla que llevaba veintidós años dormida: una confusión de tipos que permite ejecutar código arbitrario, con CVSS 8.8 y sin necesitar nada más que un acceso de login a la base.
El truco: preparar, alterar, ejecutar
La secuencia que documentó el investigador Mehmet Ince es insultantemente simple. Creas un composite type con un campo uuid y preparas una consulta con PREPARE que lo use. Después alteras el tipo de ese atributo con ALTER TYPE. Y cuando el motor llega al EXECUTE, lee los 16 bytes del UUID como si fuera bytea: los primeros bytes que en un UUID son pura identidad, ahí se interpretan como encabezado de longitud de un binario. El motor pierde el control de lo que hay en memoria y, con las piezas correctas, eso termina en ejecución remota de código con los privilegios del usuario del sistema que corre la base.
¿Y por qué funciona? Porque en PostgreSQL un Datum no sabe lo que es. Son 8 bytes opacos: es el código que los consume el que decide cómo leerlos, según lo que diga el catálogo de tipos en ese momento. Si el tipo cambia entre la preparación y la ejecución, el motor queda leyendo memoria con el manual equivocado en la mano. No es una raza mal escrita: es una suposición del diseño que nadie podía romper con el SQL de entonces.
Veintidós años no es un descuido, es un diseño
Lo que más me llamó la atención es la datación: la primitiva entra el 5 de mayo de 2004, con el commit que introdujo ALTER TABLE … ALTER COLUMN … TYPE. Veintidós años de código corriendo bancos, hospitales y todo lo que se te ocurra, con esta ventana abierta el tiempo completo. El parche mismo lo admite: el fix introduce versioning de datums de tipos compuestos y pide recompilar las extensiones en C, porque el problema era sistémico y no lo arreglan dos líneas de defensa parcial.
Otro detalle que no es menor: el commit acredita a más de diez reporteros, entre ellos el equipo de seguridad de OpenAI, el programa de open source de Anthropic y pentesters como Mehmet Ince, que llegó hasta acá persiguiendo bugs en extensiones de servicios Postgres administrados. Los modelos de IA ya no solo ayudan a escribir código: están firmando CVEs reales. Yo lo veo como el cambio de década en seguridad ofensiva, y me parece que a los administradores nos toca asumir que el ruido de advisories va a aumentar de calidad y de volumen a la vez.
Qué hacer hoy
Si administras tus propias bases, verifica la versión con psql –version y actualiza a 18.7, 17.12, 16.16, 15.20 o 14.25, según la serie que corras. Si usas un proveedor administrado, no te fíes del marketing: pregunta por la versión de tu instancia, porque precisamente los servicios administrados de Postgres fueron el punto de partida de la investigación. Y si tienes extensiones en C, recompílalas contra la versión nueva; el parche lo pide explícitamente.
Mi conclusión personal: los sistemas que duran dos décadas no se caen por accidente, se caen por decisiones de diseño que en su momento se vendieron como pragmáticas. La deuda técnica no es una metáfora bonita: es memoria que alguien va a leer con el manual equivocado, algún día. Y la próxima vez que un parche de base de datos te parezca rutinario, revisa primero qué cerró: a veces cierran una ventana de veintidós años.
Fuente del tema: How I Ended Up Turning a 22-Year-Old PostgreSQL Type-Confusion Primitive into RCE (CVE-2026-6460), el análisis del investigador Mehmet Ince.
Fuente de inspiración: How I Ended Up Turning a 22-Year-Old PostgreSQL Type-Confusion Primitive into RCE (CVE-2026-6460)
