Error de inyección SQL de Drupal Core explotado activamente y agregado a CISA KEV – CYBERDEFENSA.MX

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha agregado una falla de seguridad crítica recientemente reparada que afecta a Drupal Core a sus vulnerabilidades explotadas conocidas (KEV) catálogo, basado en evidencia de explotación activa.

La vulnerabilidad en cuestión es CVE-2026-9082 (Puntuación CVSS: 6,5), una vulnerabilidad de inyección SQL que afecta a todas las versiones compatibles de Drupal Core.

«Drupal Core contiene una vulnerabilidad de inyección SQL que podría permitir la escalada de privilegios y la ejecución remota de código a través de solicitudes especialmente diseñadas enviadas con la API de abstracción de la base de datos», dijo CISA.

La noticia de la explotación llega menos de dos días después de que Drupal publicara correcciones para la falla. Actualmente no se sabe cómo se explota la vulnerabilidad y cuáles son los objetivos finales de esos ataques.

Ciberseguridad

Hay parches disponibles para las siguientes versiones:

  • Drupal 11.3.10
  • Drupal 11.2.12
  • Drupal 11.1.10
  • Drupal 10.6.9
  • Drupal 10.5.10
  • Drupal 10.4.10
  • Drupal 9.5 (se requiere parcheo manual)
  • Drupal 8.9 (se requiere parcheo manual)

En una actualización de su aviso del 22 de mayo de 2026, Drupal admitido que «ahora se están detectando intentos de explotación en la naturaleza». Imperva, propiedad de Thales, dijo que ha observado más de 15.000 intentos de ataque dirigidos a casi 6.000 sitios individuales en 65 países.

«Hasta ahora, los ataques se dirigen principalmente a sitios de juegos y servicios financieros, en conjunto casi el 50% de todos los ataques», dijo la compañía. dicho. «La mayor parte de la actividad observada hasta ahora parece ser de sondeo».

«Este patrón sugiere que los atacantes y los escáneres intentan principalmente identificar sitios Drupal expuestos que ejecutan configuraciones vulnerables respaldadas por PostgreSQL. Si bien la actividad actualmente está dominada por el reconocimiento y la validación, la naturaleza de la vulnerabilidad significa que una explotación exitosa podría pasar rápidamente de la investigación a la extracción de datos o la escalada de privilegios».

Se recomendó a las agencias del Poder Ejecutivo Civil Federal (FCEB) que apliquen las correcciones antes del 27 de mayo de 2026 para una protección óptima.

Ivanti, Fortinet, SAP, VMware, parche n8n RCE, inyección SQL, fallas de escalada de privilegios – CYBERDEFENSA.MX

Ivanti, Fortinet, n8n, SAP y VMware han lanzado correcciones de seguridad para varias vulnerabilidades que podrían ser aprovechadas por delincuentes para eludir la autenticación y ejecutar código arbitrario.

Encabezando la lista está un defecto crítico impactando a Ivanti Xtraction (CVE-2026-8043, puntuación CVSS: 9.6) que podría explotarse para lograr divulgación de información o ataques del lado del cliente.

«El control externo de un nombre de archivo en Ivanti Xtraction antes de la versión 2026.2 permite a un atacante remoto autenticado leer archivos confidenciales y escribir archivos HTML arbitrarios en un directorio web, lo que lleva a la divulgación de información y posibles ataques del lado del cliente», Ivanti dicho en un aviso.

Fortinet publicó avisos sobre dos deficiencias críticas que afectan a FortiAuthenticator y FortiSandbox, FortiSandbox Cloud y FortiSandbox PaaS que podrían resultar en la ejecución de código:

  • CVE-2026-44277 (Puntuación CVSS: 9.1): una vulnerabilidad de control de acceso inadecuado en FortiAuthenticator que puede permitir que un atacante no autenticado ejecute código o comandos no autorizados a través de solicitudes diseñadas. (Corregido en las versiones 6.5.7, 6.6.9 y 8.0.3 de FortiAuthenticator)
  • CVE-2026-26083 (Puntuación CVSS: 9.1): una vulnerabilidad de autorización faltante en FortiSandbox, FortiSandbox Cloud y FortiSandbox PaaS WEB UI que puede permitir que un atacante no autenticado ejecute código o comandos no autorizados a través de solicitudes HTTP. (Corregido en FortiSandbox versiones 4.4.9 y 5.0.2, FortiSandbox Cloud versión 5.0.6 y FortiSandbox PaaS versiones 4.4.9. y 5.0.2)
Ciberseguridad

SAP también enviado correcciones para dos vulnerabilidades críticas:

  • CVE-2026-34260 (Puntuación CVSS: 9,6) – Una vulnerabilidad de inyección SQL en SAP S/4HANA
  • CVE-2026-34263 (Puntuación CVSS: 9,6): falta una verificación de autenticación en la configuración de la nube de SAP Commerce

«La vulnerabilidad es causada por una configuración de seguridad demasiado permisiva con un orden de reglas inadecuado, lo que permite a un usuario no autenticado realizar una carga de configuración maliciosa e inyección de código, lo que resulta en la ejecución arbitraria de código del lado del servidor», Onapsis dicho sobre CVE-2026-34263.

Por otro lado, un atacante podría aprovechar CVE-2026-34260 para inyectar declaraciones SQL maliciosas y potencialmente afectar la confidencialidad y disponibilidad de la aplicación. Sin embargo, dado que el código afectado sólo permite acceso de lectura a los datos, la vulnerabilidad no compromete la integridad de la aplicación.

«Permite que un atacante autenticado y con pocos privilegios inyecte código SQL malicioso a través de entradas controladas por el usuario, exponiendo potencialmente información confidencial de la base de datos y colapsando la aplicación», Pathlock dicho.

Broadcom también lanzó parches para una falla de alta gravedad en VMware Fusion (CVE-2026-41702, puntuación CVSS: 7.8) que podría allanar el camino para una escalada de privilegios locales. El problema se solucionó en la versión 26H1.

«VMware Fusion contiene una vulnerabilidad TOCTOU (Tiempo de verificación y tiempo de uso) que ocurre durante una operación realizada por un binario SETUID», Broadcom dicho. «Un actor malicioso con privilegios de usuario local no administrativo puede aprovechar esta vulnerabilidad para escalar privilegios a root en el sistema donde está instalado Fusion».

Para completar la lista hay un conjunto de cinco vulnerabilidades críticas que afectan a n8n:

  • CVE-2026-42231 (Puntuación CVSS: 9,4): una vulnerabilidad en la biblioteca xml2js utilizada para analizar los cuerpos de solicitud XML en el controlador de webhook de n8n que permite la contaminación de prototipos a través de una carga útil XML diseñada, lo que permite a un usuario autenticado con permiso crear o modificar flujos de trabajo para lograr la ejecución remota de código en el host n8n. (Corregido en las versiones 1.123.32, 2.17.4 y 2.18.1 de n8n)
  • CVE-2026-42232 (Puntuación CVSS: 9,4): un usuario autenticado con permiso para crear o modificar flujos de trabajo podría lograr una contaminación global del prototipo a través del nodo XML, lo que lleva a la ejecución remota de código cuando se combina con otros nodos que explotan la contaminación del prototipo. (Corregido en las versiones 1.123.32, 2.17.4 y 2.18.1 de n8n)
  • CVE-2026-44791 (Puntuación CVSS: 9,4): una omisión para CVE-2026-42232 que podría provocar la ejecución remota de código en el host n8n. (Corregido en las versiones 1.123.43, 2.20.7 y 2.22.1 de n8n)
  • CVE-2026-44789 (Puntuación CVSS: 9,4): un usuario autenticado con permiso para crear o modificar flujos de trabajo podría lograr una contaminación global del prototipo a través de un parámetro de paginación no validado en el nodo de solicitud HTTP, lo que llevaría a la ejecución remota de código en el host n8n. (Corregido en las versiones 1.123.43, 2.20.7 y 2.22.1 de n8n)
  • CVE-2026-44790 (Puntuación CVSS: 9,4): un usuario autenticado con permiso para crear o modificar flujos de trabajo podría inyectar indicadores CLI en la operación Push del nodo Git, lo que permitiría a un atacante leer archivos arbitrarios del servidor n8n y provocar un compromiso total. (Corregido en las versiones 1.123.43, 2.20.7 y 2.22.1 de n8n)
Ciberseguridad

Parches de software de otros proveedores

Otros proveedores también han publicado actualizaciones de seguridad durante las últimas semanas para rectificar varias vulnerabilidades, que incluyen:

LiteLLM CVE-2026-42208 Inyección SQL explotada dentro de las 36 horas posteriores a la divulgación – CYBERDEFENSA.MX

En otro caso más de actores de amenazas que se suben rápidamente al carro de la explotación, una falla de seguridad crítica recientemente revelada en BerriAI LiteLLM El paquete Python ha sido objeto de explotación activa en la naturaleza dentro de las 36 horas posteriores a que el error se hiciera público.

La vulnerabilidad, identificada como CVE-2026-42208 (puntuación CVSS: 9,3), es una inyección SQL que podría explotarse para modificar la base de datos proxy LiteLLM subyacente.

«Una consulta de base de datos utilizada durante las comprobaciones de claves de API de proxy mezcló el valor de clave proporcionado por la persona que llama en el texto de la consulta en lugar de pasarlo como un parámetro separado», mantenedores de LiteLLM dicho en una alerta la semana pasada.

Ciberseguridad

«Un atacante no autenticado podría enviar un encabezado de Autorización especialmente diseñado a cualquier ruta API de LLM (por ejemplo, POST /chat/completions) y acceder a esta consulta a través de la ruta de manejo de errores del proxy. Un atacante podría leer datos de la base de datos del proxy y puede modificarlos, lo que conduciría a un acceso no autorizado al proxy y a las credenciales que administra».

La deficiencia afecta a las siguientes versiones:

Si bien la vulnerabilidad se abordó en la versión 1.83.7-estable Lanzado el 19 de abril de 2026, el primer intento de explotación se registró el 26 de abril a las 16:17 UTC, aproximadamente 26 horas y siete minutos después de que el aviso de GitHub fuera indexado en la base de datos global de avisos de GitHub. La actividad de inyección de SQL, según Sysdig, se originó en la dirección IP 65.111.27[.]132.

«La actividad maliciosa se dividió en dos fases impulsadas por el mismo operador a través de dos IP de salida adyacentes, seguidas de una breve investigación no autenticada de los puntos finales de administración de claves», dijo el investigador de seguridad Michael Clark. dicho.

Específicamente, se dice que el actor de amenaza desconocido apuntó a tablas de bases de datos como «litellm_credentials.credential_values» y «litellm_config» que contienen información relacionada con las claves del proveedor del modelo de lenguaje grande (LLM) ascendente y el entorno de ejecución del proxy. No se observaron sondas en tablas como «litellm_users» o «litellm_team».

Esto sugiere que el atacante no sólo estaba al tanto de estas tablas, sino que también persiguió aquellas que contienen secretos confidenciales. En la segunda fase del ataque, observada después de 20 minutos, el actor de la amenaza utilizó una dirección IP diferente («65.111.25[.]67»), esta vez abusando del acceso para ejecutar una investigación similar.

LiteLLM es un popular software AI Gateway de código abierto con más de 45.000 estrellas y 7.600 bifurcaciones en GitHub. El mes pasado, el proyecto fue objeto de un ataque a la cadena de suministro orquestado por el grupo de hackers TeamPCP para robar credenciales y secretos de los usuarios intermedios.

«Una sola fila litellm_credentials a menudo contiene una clave de organización OpenAI con límites de gasto mensual de cinco cifras, una clave de consola Anthropic con derechos de administrador del espacio de trabajo y una credencial AWS Bedrock IAM», dijo Sysdig. «El radio de explosión de una extracción exitosa de una base de datos está más cerca de comprometer una cuenta en la nube que de una inyección SQL típica de una aplicación web».

Ciberseguridad

Se recomienda a los usuarios que actualicen sus instancias a la última versión. Si esta no es una opción inmediata, los mantenedores recomiendan configurar «disable_error_logs: true» en «general_settings» para eliminar la ruta a través de la cual las entradas que no son de confianza llegan a la consulta vulnerable.

«La vulnerabilidad LiteLLM (GHSA-r75f-5x8p-qvmc) continúa el patrón modal para los avisos de infraestructura de IA: crítico, previo a la autenticación y en software con recuentos de estrellas de cinco cifras en los que los operadores confían para centralizar las credenciales de nivel de nube», agregó Sysdig.

«La ventana de explotación de 36 horas es consistente con el colapso más amplio documentado por el Reloj de Día Cero, y el comportamiento del operador que registramos (nombres de tablas Prisma palabra por palabra, orientación de tres tablas, enumeración deliberada de recuento de columnas) muestra que la explotación ya no espera a una prueba de concepto pública. El aviso y el esquema de código abierto fueron finalmente suficientes».

Las nuevas fallas de «LeakyLooker» en Google Looker Studio podrían permitir consultas SQL entre inquilinos – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han revelado nueve vulnerabilidades entre inquilinos en Google Looker Studio que podrían haber permitido a los atacantes ejecutar consultas SQL arbitrarias en las bases de datos de las víctimas y filtrar datos confidenciales dentro de los entornos de Google Cloud de las organizaciones.

Las deficiencias han sido nombradas colectivamente. Looker con fugas por Tenable. No hay evidencia de que las vulnerabilidades hayan sido explotadas en la naturaleza. Tras la divulgación responsable en junio de 2025, Google solucionó los problemas.

La lista de fallas de seguridad es la siguiente:

Ciberseguridad

«Las vulnerabilidades rompieron supuestos de diseño fundamentales, revelaron una nueva clase de ataque y podrían haber permitido a los atacantes filtrar, insertar y eliminar datos en los servicios de las víctimas y en el entorno de Google Cloud», dijo la investigadora de seguridad Liv Matan. dicho en un informe compartido con The Hacker News.

«Estas vulnerabilidades expusieron datos confidenciales en los entornos de Google Cloud Platform (GCP), afectando potencialmente a cualquier organización que utilice Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage y casi cualquier otro conector de datos de Looker Studio».

La explotación exitosa de las fallas entre inquilinos podría permitir a los actores de amenazas obtener acceso a conjuntos de datos y proyectos completos en diferentes inquilinos de la nube.

Los atacantes podrían buscar informes públicos de Looker Studio u obtener acceso a informes privados que utilicen estos conectores (por ejemplo, BigQuery) y tomar el control de las bases de datos, permitiéndoles ejecutar consultas SQL arbitrarias en todo el proyecto GCP del propietario.

Alternativamente, una víctima crea un informe como público o lo comparte con un destinatario específico y utiliza una fuente de datos conectada a JDBC, como PostgreSQL. En este escenario, el atacante puede aprovechar una falla lógica en la función de copia de informes que permite clonar informes conservando las credenciales del propietario original, lo que le permite eliminar o modificar tablas.

Otra ruta de alto impacto detallada por la compañía de ciberseguridad implicó la exfiltración de datos con un solo clic, donde compartir un informe especialmente diseñado obliga al navegador de la víctima a ejecutar código malicioso que contacta un proyecto controlado por un atacante para reconstruir bases de datos completas a partir de registros.

«Las vulnerabilidades rompieron la promesa fundamental de que un ‘espectador’ nunca debería poder controlar los datos que está viendo», dijo Matan, y agregó que «podrían haber permitido a los atacantes filtrar o modificar datos en los servicios de Google como BigQuery y Google Sheets».