SQL Copilot vs. MaxKB: dos fallas críticas, el mismo error de diseño (guardrails que no son permisos)

Dos productos distintos, dos proveedores distintos y el mismo error: confiar en que un filtro de texto o un wrapper de sandbox impida que un agente haga lo que no debe. Comparar CVE-2026-65669 y CVE-2026-77521 muestra por qué un guardrail no es un permiso.

Los dos casos en una tabla mental

Caso 1: SQL Copilot y el “solo lectura” que era una regex

En SQL Server Management Studio, la función SQL Copilot imponía el modo de solo lectura con un clasificador basado en expresiones regulares (clase LocalSqlExecutionAccessChecker, según el análisis del investigador) y no con permisos reales de base de datos. Un patrón como DECLARE @p sysname='sp_executesql'; EXEC @p esquivaba la lista de bloqueo y permitía ejecutar T-SQL arbitrario, incluidas operaciones de escritura y borrado.

El análisis describe además dos agravantes: la exfiltración de datos por rutas SMB mediante procedimientos como xp_dirtree, y una ruta de escalada de privilegios en la que un propietario de base de datos con pocos privilegios podía plantar instrucciones en propiedades extendidas (archivos tipo AGENTS.md o CONSTITUTION.md) que Copilot incorpora a su contexto; cuando un usuario con más privilegios usaba Copilot, este ejecutaba las órdenes del atacante con esos privilegios más altos.

Caso 2: MaxKB y el sandbox que solo protegía el primer comando

MaxKB, un asistente de IA empresarial de código abierto, aplicaba un wrapper gosu como sandbox para ejecutar comandos de shell. En las versiones hasta 2.10.4-lts, el wrapper solo se aplicaba al primer comando de la cadena: con whoami; id, el primero quedaba dentro del sandbox y el segundo corría sin restricción, como root dentro del contenedor oficial.

El escenario de ataque descrito por Lasso Security: el atacante publica contenido web con instrucciones; la víctima crea un agente MaxKB con una base de conocimiento que indexa ese contenido; al consultar, el agente recupera el texto, lo trata como instrucciones y ejecuta los comandos. Además, la descripción oficial de la CVE indica que la herramienta de ejecución de shell no estaba excluida de las herramientas del agente ni requería aprobación humana. Con CVSS 10, en despliegues multiinquilino implica acceso a secretos y credenciales entre inquilinos. La corrección es actualizar a 2.10.5-lts o posterior (publicada el 6 de agosto de 2026) y mantener el sandbox activo en producción.

Qué tienen en común

• La restricción vive en el lugar equivocado. En ambos casos la barrera estaba en la capa que interpreta texto (regex, parseo del comando), no en una capa que el agente no puede negociar (permisos de base de datos, usuario sin privilegios, red cerrada).
• La entrada hostil llega por datos, no por el chat. Propiedades de una base de datos y páginas web indexadas: el agente lee contenido que alguien más escribió.
• Sin confirmación humana en acciones peligrosas. Ejecutar SQL de escritura o shell sin aprobación convierte cualquier inyección en impacto inmediato.

Qué significa para una empresa que despliega agentes

¿Quieres una revisión de los permisos y el aislamiento de tus agentes? Escríbenos a info@guatemalia.com.