SQL Copilot vs. MaxKB: Two Critical Flaws, the Same Design Mistake (Guardrails That Aren’t Permissions)

Two different products, two different vendors, and the same mistake: trusting that a text filter or a sandbox wrapper will stop an agent from doing what it shouldn’t. Comparing CVE-2026-65669 and CVE-2026-77521 shows why a guardrail is not a permission.

The Two Cases at a Glance

Case 1: SQL Copilot and the “Read-Only” That Was a Regex

In SQL Server Management Studio, the SQL Copilot feature enforced read-only mode with a regular-expression-based classifier (the LocalSqlExecutionAccessChecker class, according to the researcher’s analysis) rather than with real database permissions. A pattern like DECLARE @p sysname='sp_executesql'; EXEC @p slipped past the blocklist and allowed arbitrary T-SQL to run, including write and delete operations.

The analysis also describes two aggravating factors: data exfiltration over SMB paths using procedures such as xp_dirtree, and a privilege escalation path in which a low-privilege database owner could plant instructions in extended properties (AGENTS.md- or CONSTITUTION.md-style files) that Copilot pulls into its context; when a higher-privileged user then used Copilot, it executed the attacker’s orders with those higher privileges.

Case 2: MaxKB and the Sandbox That Only Protected the First Command

MaxKB, an open-source enterprise AI assistant, applied a gosu wrapper as a sandbox for running shell commands. In versions up to 2.10.4-lts, the wrapper was only applied to the first command in the chain: with whoami; id, the first stayed inside the sandbox and the second ran unrestricted, as root inside the official container.

The attack scenario described by Lasso Security: the attacker publishes web content containing instructions; the victim creates a MaxKB agent with a knowledge base that indexes that content; when queried, the agent retrieves the text, treats it as instructions, and runs the commands. In addition, the CVE’s official description indicates that the shell execution tool was not excluded from the agent’s tools and did not require human approval. With a CVSS of 10, in multi-tenant deployments this means access to secrets and credentials across tenants. The fix is to upgrade to 2.10.5-lts or later (released August 6, 2026) and keep the sandbox enabled in production.

What They Have in Common

• The restriction lives in the wrong place. In both cases the barrier sat in the layer that interprets text (regex, command parsing), not in a layer the agent can’t negotiate with (database permissions, an unprivileged user, a closed network).
• The hostile input arrives through data, not through chat. Database properties and indexed web pages: the agent reads content someone else wrote.
• No human confirmation on dangerous actions. Running write SQL or shell commands without approval turns any injection into immediate impact.

What This Means for a Company Deploying Agents

Want a review of your agents’ permissions and isolation? Write to us at info@guatemalia.com.