Los frameworks de abstracción de base de datos prometen que la inyección SQL es un problema resuelto. El CVE-2026-9082 demuestra que esa promesa descansa en la premisa de que la abstracción es correcta para todos los drivers, todos los patrones de input, todos los caminos de código. Cuando la abstracción falla, la caída es más dura porque nadie la espera.
El bug que no debería existir
La Database Abstraction API de Drupal existe para impedir la inyección SQL. Es la capa que separa al desarrollador del SQL raw, que sanitiza placeholders, que garantiza que el input del usuario nunca se convierte en código ejecutable. Excepto cuando se convierte.
El PostgreSQL EntityQuery condition handler procesa filtros vía JSON:API. Cuando un atacante envía filter[name][condition][value][]=v, el PHP lo parsea en arrays asociativos donde las claves son controladas por el atacante. El código en Condition.php hace foreach(condition['value'] as key => value) y concatena key en el nombre del placeholder SQL: LOWER(:db_placeholder_key).
Claves controladas por el atacante en el nombre del placeholder. Eso escapa de la gramática preparada e inyecta SQL raw en la cláusula WHERE. La abstracción que debería impedir la inyección SQL es exactamente el vector de inyección SQL.
El fix: array_values(). Una función. Elimina las claves y fuerza índices numéricos. El parche entero es una línea. ¿Qué es más revelador: la simplicidad de la corrección o la fragilidad que expone? "Casi correcta" es "totalmente vulnerable".
El camino de ataque: anónimo, rápido, escalable
JSON:API está habilitado por defecto desde Drupal 8.8. Los endpoints /user/login?_format=json y los filtros JSON:API son los dos caminos anónimos confirmados que alcanzan el code path vulnerable. Sin autenticación. Sin sesión. Sin privilegios. Solo un HTTP request especialmente construido.
El PoC público genera HTTP 500 con SQLSTATE[HY093], prueba de que el payload fue concatenado en el SQL. La distancia entre ese error y la extracción de datos es corta. La distancia hasta RCE es aún menor.
En PostgreSQL, pg_execute_server_program permite COPY (SELECT ...) TO PROGRAM 'sh -c "cmd"'. El usuario de base de datos de Drupal tiene privilegios elevados para schema migrations. La cadena completa: inyección SQL → dump de la tabla users → escritura de backdoor PHP en el webroot → login como admin → RCE. En automatización, segundos. Un script que recorre esa cadena no necesita intervención humana.
Los números que importan
Imperva registró 15.000+ intentos contra aproximadamente 6.000 sitios en 65 países en las primeras 48h. El 50% de los ataques concentrados en gaming y servicios financieros, según Imperva, sectores donde los datos de usuarios y las transacciones financieras son el objetivo principal.
Drupal estimó que menos del 5% de las instalaciones usan PostgreSQL. Pero Drupal corre en cientos de miles de sitios: gobierno, universidades, enterprise. El 5% sigue siendo miles de objetivos. Y esos objetivos tienden a ser los más grandes: gobiernos y grandes organizaciones frecuentemente eligen PostgreSQL por requisitos de compliance y licenciamiento.
CISA agregó el CVE al KEV (Known Exploited Vulnerabilities). Plazo federal para corrección: 27 de mayo. Cuando el gobierno de EE. UU. da un plazo, es porque el riesgo es real y la explotación está ocurriendo.
La discrepancia que engaña
Drupal lo clasificó inicialmente 20/25 y lo actualizó a 23/25 tras detectar explotación in the wild, "Highly Critical". La descripción: "all non-public data accessible, all data modifiable or deletable". NVD asignó CVSS 6.5, impacto "Low".
Cuando el vendor dice "todos los datos no públicos accesibles" y el NVD dice "impacto bajo", confíe en el vendor. El NVD no modela RCE vía COPY TO PROGRAM. El scoring del CVSS no captura cadenas de explotación que cruzan capas, desde la base de datos hasta el sistema operativo. Esta discrepancia no es académica: los equipos de seguridad que priorizan por CVSS van a subestimar el riesgo. Los equipos que priorizan por la clasificación del vendor van a actuar correctamente.
Lo vemos repetidamente en nuestra operación: scores del NVD que no reflejan la realidad de explotación. El CVSS es un input, no un veredicto. La clasificación del vendor, el contexto de la infraestructura y la existencia de cadenas de explotación públicas son indicadores más confiables.
La historia se repite
El Drupalgeddon de 2014 (CVE-2014-3704) estaba en la misma capa de abstracción. Mismo resultado: inyección SQL a través de la API que debería impedir la inyección SQL. La misma premisa quebrada. La misma confianza mal colocada.
Doce años después, la historia se repite. No porque los desarrolladores de Drupal sean negligentes, son excelentes. Se repite porque la premisa de que una capa de abstracción cubre todos los casos es estructuralmente frágil. Cada nuevo driver, cada nuevo formato de input, cada nuevo code path es una superficie de ataque que la abstracción no probó. El hecho de que funcione para el 95% de los casos no protege el 5% restante, y el 5% restante puede ser el más crítico.
La lección no es "no use abstracciones". La lección es: las abstracciones reducen riesgo, no lo eliminan. Y cuando el riesgo residual se materializa, usted necesita una capa independiente que funcione cuando la abstracción falla.
Defensa en profundidad, no confianza en una sola capa
El parche es necesario y urgente. Pero el parche es reactivo: usted lo aplica después de que la vulnerabilidad es descubierta, después de que los ataques comienzan, después de que CISA lo agrega al KEV. La ventana entre la divulgación y la corrección es donde ocurren los daños.
Un WAF con reglas de inyección SQL bloquea los payloads antes de que lleguen a la aplicación. No reemplaza el parche, pero protege durante la ventana crítica. Y más importante: protege contra la próxima vulnerabilidad en la misma capa. Porque si la historia se repite cada 12 años en la misma API, la próxima falla de abstracción no es una cuestión de "si", es una cuestión de "cuándo".
En Tech86 operamos con el principio de que ninguna capa de protección es suficiente por sí sola. La abstracción del framework es la primera línea. El WAF es la segunda. El monitoreo de anomalías es la tercera. Cuando una falla, las demás siguen en pie. Eso es lo que llamamos Blindagem Perímetro, y es exactamente el tipo de protección que el CVE-2026-9082 hace evidente.