CVE-2026-26030 en Semantic Kernel: cuando un prompt se convierte en shell remoto
Microsoft publicó dos vulnerabilidades críticas en Semantic Kernel: un prompt malicioso ejecuta código en el host. Análisis técnico.
Javier Núñez
Especialista en ciberseguridad, compliance y seguridad IA
El 7 de mayo de 2026 Microsoft Security publicó un análisis sobre dos vulnerabilidades críticas en Semantic Kernel, su framework para construir agentes IA. Las dos —CVE-2026-26030 en el SDK de Python y CVE-2026-25592 en el SDK de .NET— permitían convertir una simple inyección de prompt en ejecución de código en el host. Es el primer caso documentado por Microsoft de RCE disparado únicamente con texto natural enviado al agente.
La importancia del disclosure va más allá del parche. Cualquier ingeniero que haya construido un agente con tool-use en los últimos doce meses debería leer el writeup como espejo: el patrón que falló en Semantic Kernel es estructuralmente idéntico al que aparece en LangChain, AutoGen, CrewAI y en buena parte de los stacks propios que se montaron rápido durante 2024 y 2025. La diferencia es que Microsoft tiene equipo de seguridad para encontrarlo; muchos no.
Qué es exactamente lo que pasó
Las dos CVE comparten una raíz común: el framework expuso al modelo capacidades del runtime que no debió exponer. En el caso del SDK de Python, una función de filtro por defecto en InMemoryVectorStore aceptaba expresiones de usuario y las evaluaba con eval(). Había un blocklist para palabras como import u os, pero un atacante podía esquivarlo navegando la jerarquía de clases de Python desde un objeto inocente hasta alcanzar os.system sin escribir literalmente esos nombres.
En el SDK de .NET el patrón fue distinto pero igual de educativo. Una utilidad llamada DownloadFileAsync, pensada como helper interno, quedó marcada por descuido con el atributo [KernelFunction]. Ese atributo significa "esto es una herramienta que el modelo puede invocar". La función aceptaba rutas absolutas sin validar. Un prompt malicioso podía pedirle al modelo que descargara un archivo a una ruta arbitraria del filesystem, incluyendo el Startup folder de Windows — donde cualquier ejecutable se lanza al siguiente login. El sandbox de Azure Container Apps no falló por bug propio: falló porque le dimos al modelo la llave para cruzarlo.
Comparativa de las dos CVE
| Aspecto | CVE-2026-26030 (Python) | CVE-2026-25592 (.NET) |
|---|---|---|
| Tipo | Ejecución de código vía eval() | Sandbox escape vía DownloadFileAsync |
| Versión vulnerable | Previas a 1.39.4 | Previas a 1.71.0 |
| Vector | Filtro de InMemoryVectorStore | KernelFunction expuesta sin validación |
| Impacto | RCE en el host del agente | File write fuera del sandbox de Azure Container Apps |
| Fix | Allowlist de nodos AST + bloqueo de atributos | Quitar la función del registro accesible al modelo |
La lección estructural: el tool registry es la superficie de ataque
El blog de Microsoft fue inusualmente directo en su conclusión. El problema no es solo "validar inputs": es que en un framework de agentes, cualquier función registrada como herramienta es una nueva primitiva de ataque accesible al modelo. Si tu agente tiene 40 herramientas, el LLM puede componerlas en órdenes que ninguna persona razonó.
En el caso de .NET, DownloadFileAsync era una utilidad interna que alguien marcó con el atributo [KernelFunction] sin pensar en que iba a quedar disponible para que el modelo la invocara con una ruta de destino arbitraria. El sandbox de Azure Container Apps se rompió no por un bug del propio sandbox, sino porque le habíamos dado al modelo, sin querer, la herramienta perfecta para escribir en el Startup folder de Windows.
Cronología del disclosure
- 1Mar 2026Reporte privado a Microsoft
Investigadores externos identifican el patrón en el SDK de Python.
- 2Abr 2026Parches preparados
Microsoft publica 1.39.4 (Python) y 1.71.0 (.NET) con mitigaciones layered.
- 3May 7 2026Disclosure público
Microsoft Security Blog publica el writeup completo el mismo día de Patch Tuesday.
- 4May 7 2026CVE asignados
CVE-2026-26030 y CVE-2026-25592 entran al catálogo oficial.
Qué tienes que hacer si construyes con Semantic Kernel
- 1Actualizar al menos a Semantic Kernel 1.39.4 (Python) o 1.71.0 (.NET). Es el mínimo no negociable, antes de mirar otra cosa.
- 2Hacer un inventario manual de cada KernelFunction registrada en tu agente y eliminar las que no sean estrictamente necesarias para el caso de uso. Cada herramienta es una superficie.
- 3Para flujos que aceptan input externo (RAG, correo, tickets), añadir una capa de detección de prompt injection antes de que el texto llegue al planificador del agente.
- 4Aprobación humana obligatoria para herramientas con efectos secundarios sensibles: escritura en disco, ejecución de código, acceso a Salesforce/Drive.
Qué significa esto para tu modelo de amenazas
Hasta hace pocos meses la conversación sobre prompt injection era casi académica para muchos equipos: "el modelo dice algo raro, lo filtramos en post-proceso". Las CVE de mayo demuestran que esa conversación se quedó obsoleta. El nuevo modelo de amenaza tiene tres niveles. Nivel 1: el modelo responde mal y propaga la respuesta a otro sistema. Nivel 2: el modelo invoca una herramienta con argumentos manipulados. Nivel 3: el atacante encadena herramientas hasta obtener ejecución de código fuera del sandbox. Los tres niveles ya están documentados en producción.
La defensa también cambia de capa. No se trata solo de sanitizar el input que entra al modelo — eso es necesario pero insuficiente. Se trata de asumir que cualquier prompt entrante puede llegar a invocar las herramientas que el agente tiene registradas, y que el registro de herramientas es ahora el activo más sensible del sistema. Reducirlo, validarlo y monitorizarlo es la nueva higiene básica.
Dos CVE críticas, mismo patrón: una función del framework no debió exponerse al modelo. Es el patrón que se va a repetir.
La inyección de prompt ya no es solo "el modelo dice algo raro". Es ejecución arbitraria si el agente tiene herramientas mal acotadas.
Auditoría del tool registry > validación de input. La defensa nueva empieza por reducir lo que el modelo puede invocar.
