Una fuga del sandbox en Skyvern, el agente autohospedado que controla un navegador web a partir de pasos generados por LLM, recibió CVE-2026-82447 y se publicó en la GitHub Advisory Database el 29 de agosto de 2026 a las 15:30:19 UTC. La corrección de código que describe llegó al repositorio el 6 de julio a las 21:44:03 UTC, 53 días antes.
Qué era realmente el fallo
TextPromptBlock de Skyvern renderizaba cada prompt dos veces. La primera pasada se hacía a través de SandboxedEnvironment de Jinja, como estaba previsto. La segunda pasaba la misma cadena influida por un atacante por un renderer sin sandbox, lo bastante para ejecutar código como proceso del servidor. La corrección, el commit d723de6, es una eliminación: tres líneas añadidas y once eliminadas en block.py, descartando el segundo renderizado y el argumento parameter_values que lo alimentaba. El resto del commit son pruebas.
Dónde falla el encuadre
Hay dos cosas que se suelen decir de avisos como este y que aquí no son ciertas. La primera es que se trató de un parche silencioso. No fue así: las notas de la versión v1.0.45, publicadas el 7 de julio a las 22:19:18 UTC, sí contienen la palabra "SSTI". Pero es un único punto en un cuerpo de la versión de unas 190 líneas, sin aviso de seguridad del proveedor, sin CVE en ese momento y sin nada que lo distinga del tráfico rutinario de un changelog. La segunda es la implicación de que el año de un CVE te dice cuándo estuviste expuesto. No lo hace: el CVE fue asignado por VulnCheck como autoridad de numeración de terceros, no por el proyecto.
La parte que rompe las herramientas
El registro del aviso incluye una puntuación CVSS 3.1 de 8.8 y una puntuación CVSS 4.0 de 8.7, y está clasificado como CWE-1336. Pero su matriz estructurada vulnerabilities está vacía. El rango afectado — de 0.2.1 hasta antes de 1.0.45 — existe solo como prosa en la página de VulnCheck. Cualquier escáner que lea los datos estructurados del aviso de GitHub y compare una dependencia skyvern fijada contra ellos no informará absolutamente nada.
Por qué esta forma se repite
La ruta de explotación no es exótica. Un parámetro de flujo de trabajo, o la salida de un bloque upstream, es texto que el propio agente produjo o ingirió; llega a un renderer de plantillas; se convierte en código en el host del agente. Ese es el puente de la inyección de prompts a la ejecución en su forma más simple, y es estructural en las herramientas que permiten que la salida de un modelo dirija una capa de plantillas.
