sistema: OPERATIVO
← volver a todos los hacks
AGENTS CRITICAL

Semantic Kernel: cuando un prompt se convierte en shell (CVE-2026-25592, CVE-2026-26030)

Microsoft divulgó el 7 de mayo de 2026 dos vulnerabilidades críticas en Semantic Kernel que convierten un único prompt inyectado en ejecución de código a nivel de host. La causa raíz es arquitectónica: el registro de herramientas y eval() se trataron como comodidades, no como fronteras de seguridad.

2026-05-26 // 8 min affects: semantic-kernel <1.39.4 (Python), semantic-kernel <1.71.0 (.NET)

¿De qué se trata?

El 7 de mayo de 2026, el Microsoft Security Response Center publicó los advisories de dos vulnerabilidades críticas en Semantic Kernel, el framework de agentes insignia de la compañía. CVE-2026-25592 (CVSS 10.0) afecta al SDK de .NET anterior a 1.71.0; CVE-2026-26030 (CVSS 9.8) afecta al SDK de Python anterior a 1.39.4. Ambas convierten un único prompt inyectado en ejecución remota de código a nivel del host.

El artículo de investigación que las acompaña, “When prompts become shells”, muestra cómo lanzar calc.exe en el host del agente sin necesidad de exploits de navegador, adjuntos maliciosos ni errores de corrupción de memoria: basta con una cadena en lenguaje natural cuidadosamente construida.

Cómo funciona

CVE-2026-26030 (Python, InMemoryVectorStore). Cuando una aplicación de Semantic Kernel utiliza el vector store en memoria por defecto con el Search Plugin, la expresión de filtro proporcionada por el usuario se compila como un lambda de Python y se ejecuta mediante eval(). Cualquier cadena que el modelo pueda colocar en ese filtro —directamente o a través del contenido de un documento recuperado— se convierte por tanto en código Python ejecutado en el host:

# Patrón vulnerable simplificado (NO ejecutar)
filter_expr = user_or_model_supplied_string
fn = eval(f"lambda item: {filter_expr}")  # [REDACTED-eval]
results = [it for it in store if fn(it)]

CVE-2026-25592 (.NET, SessionsPythonPlugin). El plugin que ejecuta el código generado por el modelo en sesiones dinámicas de Azure Container Apps también exponía un helper interno, DownloadFileAsync, decorado con [KernelFunction]. Ese atributo hace visible al LLM un método .NET como una herramienta invocable. Sin validación de rutas, el modelo podía crear un payload dentro del sandbox y luego pedir al propio framework que escribiera ese payload en una ubicación arbitraria del host que ejecuta el agente, saltándose por completo la frontera del sandbox.

Ambos errores comparten una misma equivocación arquitectónica: haber tratado el registro de herramientas ([KernelFunction]) y el lenguaje de filtros (eval) como comodidades ergonómicas, en lugar de como superficies críticas para la seguridad.

Por qué importa

Durante mucho tiempo se describió la inyección de prompts como un problema de «seguridad de contenido». Estas CVE desbaratan ese marco. Una vez que un LLM se conecta a herramientas y recibe texto no fiable —un documento recuperado, una página web, un mensaje de usuario— cada función expuesta forma parte de la superficie de ataque, y cada intérprete de cadenas se convierte en un camino de ejecución.

El patrón no es exclusivo de Semantic Kernel. Las investigaciones de Microsoft y los advisories paralelos de terceros documentan en 2026 la misma clase de errores en otros frameworks de agentes (CrewAI, LangFlow, LiteLLM, GPT Researcher), a menudo vía inyección de comandos MCP STDIO o llamadas a eval/exec dentro de los sistemas de plugins. Cualquier equipo que construya agentes con herramientas, RAG o ejecución de código debería asumir que esta clase los afecta hasta que se demuestre lo contrario.

Defensas

  • Aplicar el parche de inmediato. Actualice a semantic-kernel >= 1.39.4 (Python) y >= 1.71.0 (.NET). Fije la versión en el lockfile y verifíquelo en CI.
  • Auditar el registro de herramientas. Liste cada método expuesto al modelo ([KernelFunction], @kernel_function, decoradores equivalentes en otros frameworks). Elimine todo lo que cruce una frontera de confianza —E/S de archivos en el host, salida de red, acceso a secretos— salvo que esa exposición sea deliberada y haya sido revisada.
  • Prohibir eval/exec sobre cualquier entrada influida por el modelo. Sustituya los filtros basados en lambdas por un AST parseado o por un lenguaje de dominio con una lista explícita de operadores permitidos. Una expresión de filtro es entrada de usuario, no código.
  • Sandboxear el host de la herramienta, no solo el intérprete. Azure Container Apps sandboxeaba la sesión de Python; no sandboxeaba el host .NET propietario del helper de archivos. La frontera de confianza debe envolver al llamante de la herramienta, no solo al payload.
  • Aplicar el marco de la «lethal trifecta». Como lo formula Simon Willison, un agente que combina (1) acceso a datos privados, (2) exposición a contenido no fiable y (3) capacidad de actuar hacia el exterior es explotable por defecto. Cuando sea posible, retire al menos una de esas tres patas por entorno.
  • Registrar las llamadas a herramientas con sus argumentos. Detecte parámetros anómalos (rutas fuera de los directorios esperados, código sospechoso en cadenas de filtro) antes de su ejecución.

Estado

ComponenteVersiones vulnerablesParcheado enCVSS
semantic-kernel (Python, InMemoryVectorStore)< 1.39.41.39.49.8
semantic-kernel (.NET, SessionsPythonPlugin)< 1.71.01.71.010.0

Fechas clave: divulgación y parches publicados por Microsoft el 7 de mayo de 2026. Las entradas CVE se crearon esa misma semana; el GitHub Security Advisory GHSA-xjw9-4gw8-4rqx y el registro NVD de CVE-2026-26030 sirven como referencias primarias.

Sources