que paso
Cloud Security Alliance publicó una nota de investigación el 6 de agosto de 2026 que describe CoreBreak, un conjunto de cuatro CVE en los marcos de agentes de AWS, Google y Vercel en los que la capa de envío de herramientas ejecutó una llamada de herramienta sin verificar que un modelo de lenguaje realmente la hubiera producido. Los cuatro tienen correcciones de proveedores.
La Iniciativa de Seguridad de IA de Cloud Security Alliance publicó una nota de investigación el 6 de agosto de 2026 que describe un patrón de vulnerabilidad multiplataforma que los investigadores denominaron CoreBreak. Según la nota, los investigadores de seguridad Hedi Ingber y Aviyam Ivgi, cofundadores de la firma de seguridad Stealth, presentaron hallazgos en Black Hat USA 2026 que muestran que las capas de ejecución de herramientas de Amazon Bedrock AgentCore, el kit de desarrollo de agentes (ADK) de Google para Python y los paquetes de arnés distribuidos con el SDK de IA de Vercel podrían ser inducidos a ejecutar una herramienta sin que se produzca un giro de modelo legítimo. Debido a que el modelo de lenguaje nunca fue invocado, argumenta la nota, las barreras construidas alrededor del modelo no tuvieron decisión sobre la cual intervenir.
Los marcos de agentes de este tipo comparten una estructura común. Una capa de orquestación agrupa la solicitud del usuario, el mensaje del sistema, el historial de conversaciones y un catálogo de herramientas disponibles, lo envía a un modelo de lenguaje y espera a que el modelo devuelva una instrucción estructurada que nombra una herramienta y sus argumentos. Luego, el SDK envía la función, script o llamada API correspondiente y devuelve el resultado a la conversación. CoreBreak apunta al último paso: según la nota, la lógica de despacho en cada uno de los tres productos trató datos que simplemente se parecían a una llamada de herramienta generada por un modelo como autorizados, sin verificar de dónde vinieron.
La nota enumera cuatro identificadores CVE con distintas rutas de explotación, citando boletines de proveedores y entradas de la base de datos nacional de vulnerabilidades. AWS asignó CVE-2026-18830 (CVSS v4.0 8.6, alto) a la falla del arnés Bedrock AgentCore, donde una persona que llama remotamente autenticada podría colocar un bloque de contenido de uso de herramientas directamente en el mensaje final de una solicitud de API InvokeHarness. Google asignó CVE-2026-18236 (9.3, Crítico) a una falla de ADK en la que un atacante capaz de inyectar eventos en el historial de sesiones podría falsificar una confirmación de aprobación humana, porque el procesador de confirmación no verificó que la herramienta de destino perteneciera al agente ejecutor, que realmente requiriera confirmación o que su nombre y argumentos coincidieran con la llamada grabada original. @ai-sdk/harness-codex y @ai-sdk/harness-opencode de Vercel recibieron CVE-2026-64650 y CVE-2026-64651 (6.3, Medio cada uno), donde el código malicioso que ya se ejecuta dentro de una zona de pruebas de Linux podría satisfacer una verificación de ruta de proceso que confiaba en cualquier proceso cuya línea de comando contuviera la ruta de un script auxiliar aprobado.
Hay correcciones disponibles, pero la carga difiere según el modelo de implementación. La nota dice que la solución de AWS para la API Bedrock AgentCore InvokeHarness totalmente administrada se implementó automáticamente antes del 31 de julio de 2026 y no requirió ninguna acción por parte del cliente, aunque aún recomienda confirmar la cobertura para una región y configuración determinadas. La solución de Google se envió en ADK para Python versión 2.5.0 el 16 de julio de 2026, y las correcciones de Vercel se enviaron en Harness-codex 1.0.29 y Harness-opencode 1.0.28 el 10 de julio de 2026: actualizaciones de paquetes que los operadores autohospedados deben aplicar ellos mismos. La nota encuadra a CoreBreak como algo distinto de la inyección rápida: la inyección rápida intenta manipular el juicio del modelo, mientras que CoreBreak pasa por alto la cuestión de si el modelo ejerció algún juicio.
Lea la fuente principal: labs.cloudsecurityalliance.org ↗
Por qué es importante
Los filtros de contenido, las indicaciones del sistema, la capacitación sobre rechazos y las puertas de aprobación humana asumen que el modelo es la parte que decide si una herramienta se ejecuta. Si la capa de despacho acepta cualquier cosa con forma de llamada a la herramienta de un modelo, esos controles se omiten en lugar de derrotarse, y los registros que los equipos de monitoreo normalmente inspeccionan nunca se crean.
La mayoría de los controles empresariales para la IA agente se encuentran en el modelo o alrededor de él. Las indicaciones del sistema restringen las acciones sensibles, los filtros de contenido califican las entradas y salidas, el entrenamiento de rechazo está integrado en los pesos del modelo y los pasos de confirmación humana bloquean las herramientas de alto riesgo. Cada uno de esos controles supone que el modelo es la parte que decide si una herramienta se ejecuta. Si una capa de despacho ejecuta cualquier carga útil que tenga la forma correcta, esas inversiones brindan poca protección preventiva, no porque estuvieran mal diseñadas, sino porque el ataque se dirige alrededor del lugar donde operan. Se trata de un tipo de problema diferente al de una barrera de seguridad que se puede argumentar más allá.
Las capacidades específicas detrás de estas capas de despacho son las que dan peso al hallazgo. La nota dice que las fallas de Vercel podrían afectar a herramientas expuestas al host, incluidas búsquedas secretas, operaciones de implementación y llamadas API en la nube. La falla Google es aún más puntiaguda: permitió que confirmaciones falsificadas llegaran a herramientas colocadas deliberadamente detrás de la aprobación humana, que es el control que las organizaciones reservan para acciones consideradas demasiado importantes para automatizarlas. Un bypass que neutralice específicamente el paso del ser humano en el circuito socava la mitigación que muchos equipos citan al justificar una autonomía más amplia de los agentes.
La historia del parche también ilustra una asimetría que se repetirá a medida que se extiendan las herramientas de los agentes. Los clientes del servicio AWS totalmente administrado fueron remediados sin hacer nada. Los equipos que ejecutan el ADK de Google o los paquetes de arnés de Vercel en sus propios entornos tienen que notar el aviso, actualizar la dependencia y volver a implementarla, y las actualizaciones de dependencia en las pilas de producción habitualmente demoran semanas o meses. Por lo tanto, la misma brecha de diseño subyacente tiene una ventana de exposición práctica muy diferente dependiendo de si una organización consume infraestructura de agentes como servicio o la vende en su propia base de código.
También existe una brecha de detección. La nota observa que el monitoreo de seguridad para sistemas agentes generalmente se ha centrado en las entradas y salidas del modelo: registrar indicaciones, señalar terminaciones sospechosas y revisar qué herramientas eligió el modelo. Cuando una herramienta se ejecuta sin que el modelo se esté ejecutando, ninguno de esos artefactos existe para registrarse. Se desconocen varias cosas importantes: la nota no informa evidencia de explotación en la naturaleza, no da una estimación de cuántas implementaciones se vieron afectadas y no describe el código de prueba de concepto. CSA es sincero en cuanto a que dos divulgaciones de cuatro proveedores no prueban un patrón en toda la industria y que el gradiente de gravedad observado es un punto de datos en lugar de una regla de puntuación.
Qué ver a continuación
Si los operadores autohospedados realmente aplican las actualizaciones de los paquetes Google y Vercel, si surgen brechas de procedencia similares en otros marcos de agentes, si se reporta alguna explotación en estado salvaje y si los proveedores pasan a tokens de autorización firmados y vinculados a sesiones para la ejecución de herramientas.
La cuestión más concreta a corto plazo es la adopción del parche. La solución administrada de AWS se describe como ya implementada, pero ADK 2.5.0 y las dos versiones de arnés de Vercel solo ayudan a los operadores que las instalan. Esté atento a las señales posteriores: tasas de adopción de registros de paquetes, bifurcaciones proporcionadas por proveedores que nunca realizan la actualización e imágenes internas de la plataforma que fijan versiones anteriores. La nota también recomienda una verificación retrospectiva: revisar los registros de invocaciones de herramientas que no pueden vincularse a una finalización de modelo correspondiente y bien formada en el registro de sesión. Aún no se ha resuelto si las organizaciones tienen la telemetría de la capa de despacho para ejecutar esa verificación.
La segunda cuestión es el alcance. CoreBreak cubre tres productos, pero el patrón descrito (confiar en la forma de una carga útil o en la línea de comando de un proceso como prueba de autorización del modelo) no es específico de ellos. Cualquier marco con la misma estructura de SDK a modelo a herramienta podría tener una brecha comparable. Esté atento a más avisos de otros mantenedores del marco de agentes y si los investigadores publican detalles técnicos más completos después de la presentación de Black Hat. Casos confirmados adicionales reforzarían el argumento de CSA de que se trata de un patrón estructural y no de tres errores coincidentes.
En tercer lugar, observe la respuesta arquitectónica. La recomendación de CSA es exigir pruebas criptográficas de que una llamada a una herramienta se originó a partir de la finalización de un modelo real (un token único, firmado y vinculado a una sesión) en lugar de inferir la autorización a partir de la estructura del mensaje o la identidad del proceso. Si los principales proveedores adoptan ese modelo y si se convierte en algo que los compradores puedan solicitar y verificar durante la adquisición, determinará si esta divulgación cambia los diseños o solo produce parches. La lógica de procesamiento de confirmación que valida la propiedad de la herramienta, el requisito de confirmación y la integridad de los argumentos frente a la llamada grabada original es la versión más limitada de la misma solución.
Finalmente, observe las pistas de gobernanza e inteligencia sobre amenazas. CSA señala su marco de modelado de amenazas MAESTRO y AI Controls Matrix v1.1 como lugares donde las evaluaciones de control de ejecución y gestión de privilegios ahora deberían cubrir explícitamente el envío de herramientas, y conecta CoreBreak con su investigación anterior GuardFall sobre omisiones de barandillas a nivel de shell. También vale la pena monitorear: si se revisan las entradas NVD o las puntuaciones CVSS, si los proveedores publican detalles posteriores al incidente más allá de los boletines iniciales y si surge alguna explotación confirmada. Ninguno de los cuatro CVE incluye actualmente un informe público de abuso en el medio natural en el material que cita CSA, y la ausencia de dichos informes no es lo mismo que la ausencia de actividad.
