Alerta de seguridad Drupal vulnerabilidad crítica de inyección SQL en PostgreSQL obliga a actualizar de inmediato

Drupal ha publicado actualizaciones de seguridad para una vulnerabilidad calificada como "altamente crítica" que afecta a Drupal Core y permite a un atacante lograr inyección SQL arbitraria en sitios que utilicen bases de datos PostgreSQL, con posibles consecuencias que van desde la divulgación de información hasta la escalada de privilegios y la ejecución remota de código. El fallo, registrado como CVE-2026-9082 y con una puntuación CVSS media de 6.5/10 según CVE.org, reside en la capa de abstracción de base de datos que Drupal utiliza para validar y sanear las consultas; una validación defectuosa posibilita que peticiones especialmente diseñadas salten esas protecciones cuando el backend es PostgreSQL (CVE-2026-9082). Es importante subrayar que la explotación puede realizarse por usuarios anónimos, lo que incrementa la urgencia de aplicar parches.

Las ramas soportadas que ya tienen lanzamientos que corrigen el problema son, entre otras, Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 y 10.4.10; Drupal 7, por su parte, no se ve afectado. Drupal ha indicado además que las publicaciones para las ramas soportadas incluyen actualizaciones upstream para Symfony y Twig, por lo que es crucial instalar las versiones completas publicadas y no limitarse a parches parciales. Para instrucciones oficiales sobre cómo actualizar el núcleo conviene remitirse a la documentación de actualizaciones de Drupal (Actualización de Drupal Core), y a la página de seguridad del proyecto para avisos y paquetes oficiales (Drupal Security).

Desde el punto de vista operativo y de riesgo, esta vulnerabilidad reúne varios factores preocupantes: afecta solo a instalaciones con PostgreSQL —por tanto, muchos sitios MySQL/MariaDB quedan fuera—, pero la posibilidad de explotación por usuarios anónimos y el potencial de escalada hasta ejecución remota convierte a las instalaciones vulnerables en objetivos prioritarios. Además, Drupal ha publicado parches manuales como “best effort” para ramas en fin de vida como Drupal 9 y 8, pero esos parches no sustituyen la cobertura de seguridad completa; las ramas EOL seguirán teniendo otras vulnerabilidades conocidas sin parche oficial, por lo que la mejor estrategia a medio plazo es migrar a una rama soportada.

Para administradores y responsables de seguridad la hoja de ruta inmediata debe incluir aplicar las actualizaciones publicadas en cuanto sea posible tras una validación mínima en entorno de pruebas, hacer copias de seguridad completas antes de tocar producción y revisar permisos de la cuenta de base de datos para reducir el blast radius en caso de explotación. Si por restricciones no es posible actualizar de inmediato, conviene mitigar con reglas temporales a nivel de Web Application Firewall que bloqueen patrones sospechosos, endurecer reglas de acceso a la interfaz administrativa y restringir el acceso a la base de datos desde la red pública. También es recomendable rotar credenciales de base de datos y claves, y asegurar los backups.

Además de actualizar, es importante buscar indicadores de compromiso derivados de inyecciones SQL: consultas inusuales, creación de usuarios administrativos inesperados, modificaciones de código o ficheros en el sistema de archivos, presencia de web shells y tráfico saliente desde el servidor hacia destinos desconocidos. La monitorización de logs del servidor web y de PostgreSQL puede revelar intentos de explotación; herramientas de detección de intrusiones y análisis de integridad de ficheros ayudan a confirmar si una intrusión tuvo éxito. Si detecta actividad anómala, aísle el sistema afectado y realice un análisis forense antes de restaurar desde una copia segura.

En términos más amplios, este incidente vuelve a destacar la necesidad de mantener una política de gestión de versiones y parches: usar versiones soportadas, automatizar actualizaciones críticas cuando sea posible, y testear dependencias upstream como Symfony y Twig, que en este caso se actualizaron en las ramas corregidas. Para entender mejor el riesgo de la inyección SQL y las mejores prácticas para mitigarla a nivel de aplicación puede consultarse la guía de OWASP sobre SQL Injection (OWASP SQL Injection). Finalmente, si su organización carece de capacidad interna para responder a un posible compromiso, considere contratar soporte especializado o servicios de respuesta a incidentes para asegurar una remediación completa y una recuperación controlada.