⌁AI·CYBER·BRIEF▌
Vulnerabilities11 min read

From SELECT to sysadmin: SQL Server's Copilot enforced "read-only" with a regex

A BlueHat Asia talk shows how Copilot in SQL Server Management Studio could be steered past its "read-only" mode, and how one database owner's notes became an attack on admins.

Microsoft's Copilot inside SQL Server Management Studio (SSMS) told its own model it was "running in a read-only mode", but the only thing enforcing that, according to researcher Johann Rehberger, was a regex-based filter that a low-privileged user could talk the assistant past. Combined with "database instructions" (notes stored inside the database that Copilot reads automatically), the flaw let a database owner plant instructions that later ran with a sysadmin's privileges when that admin used Copilot. Microsoft rated it critical (CVE-2026-65669, CVSS 9.6) and published a fix on September 8, 2026. Rehberger's BlueHat Asia talk and write-up, published September 30, are the first full public account of how it worked.

The short version

SSMS is the desktop tool most people use to administer Microsoft SQL Server. Since version 22, it ships with GitHub Copilot built in: you can ask questions about a database in plain English, and the assistant can run queries for you. Microsoft's documentation is explicit that Copilot "executes queries based on your login permissions". Whatever you can do, it can do.

To keep that safe, the assistant was given a rule: stay read-only. Rehberger found that the rule lived in two places only, the system prompt ("You are running in a read-only mode") and a pattern-matching filter that tried to spot write statements. Neither is a security boundary. By wrapping a forbidden command in a level of indirection, the filter no longer recognised it, and the assistant could create, change and delete data.

The serious part is who can trigger it. Copilot reads more than your question: it also reads table contents, script files and metadata. In particular, it automatically loads two kinds of notes stored in the database as extended properties, CONSTITUTION.md for the whole database and AGENTS.md for individual tables. Anyone allowed to edit those notes can plant instructions. When a more privileged colleague later asks Copilot something about that database, the planted instructions run with the colleague's connection. Rehberger's end-to-end demo turned a database owner into a member of the sysadmin role, the highest level on the server.

Think of it as leaving a sticky note on a shared filing cabinet that says "whoever opens this, also sign this form", and the only person who reads every sticky note and obeys it is the assistant of whoever holds the master key.

Timeline

  • February 10, 2026 — SSMS 22.3.0 introduces "database instructions" for GitHub Copilot, stored as extended properties in the database.
  • June 9, 2026 — SSMS 22.7.0 adds Agent mode (preview), a separate execution context configurable through CONSTITUTION.md, and a group policy to disable Agent mode.
  • July 28, 2026 — SSMS 22.8.2 released. The CVE record (as mirrored by cve.threatint.com) lists versions before 22.8.2 as affected; the 22.8.2 release notes mention only an inline-chat bug fix.
  • September 8, 2026 — Microsoft publishes CVE-2026-65669, "Microsoft SQL Server Elevation of Privilege Vulnerability": Critical, CVSS 3.1 base score 9.6, not publicly disclosed, not exploited, "Exploitation Less Likely".
  • Mid-September 2026 (our inference) — Rehberger presents the research at BlueHat Asia 2026 in Singapore. His post says only that the talk was "two weeks back".
  • September 28, 2026 — SSMS 22.10.2 makes Agent mode generally available and updates the bundled SQL Tools MCP server; Microsoft's note says "Query execution permissions are now determined by the connected SQL account's permissions."
  • September 30, 2026 — Rehberger publishes "From SELECT to SYSADMIN with SQL Copilot (CVE-2026-65669)".

What we know

Microsoft's advisory. MSRC describes the flaw as "improper neutralization of special elements in output used by a downstream component ('injection') in SQL Server" that "allows an unauthorized attacker to elevate privileges over a network". Its FAQ says an attacker could convince a user to submit specially crafted instructions to SQL Copilot in SSMS; a successful attack could bypass the read-only safeguards and access or modify data with the connected user's permissions. The vector is AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, with the temporal metrics marking an official fix as available. MSRC lists the flaw as not publicly disclosed and not exploited; when we rechecked on October 12, the advisory was still at its first revision of September 8.

The researcher's account. Rehberger, who has spent years documenting prompt-injection flaws in AI assistants, makes these points in his write-up:

  • Copilot "executes with the privileges of the connected user". The assistant showed only a handful of tools until a query window was connected to a database, after which database-specific tools appeared.
  • Its system prompt described it as an assistant "connected to a specific SQL Server database" and stated "You are running in a read-only mode."
  • By reverse-engineering the client, he found the enforcement was "a regex-based classifier in the LocalSqlExecutionAccessChecker class", which he calls "fragile security controls" with "many ways a given capability can be bypassed".
  • Through the ReadFromDatabase tool, an indirect call to a stored procedure that executes dynamic SQL removed the write restrictions entirely, allowing statements such as CREATE, INSERT, UPDATE and DROP.
  • He showed two ways to move data out: embedding queried values in a network path passed to xp_dirtree (so the server reaches out over SMB), and abusing a backup-verification tool, RestoreVerifyBackupFile, that could also run arbitrary T-SQL.
  • Indirect prompt injection worked through comments in T-SQL files, database content and metadata.
  • CONSTITUTION.md "applies database-wide" and AGENTS.md "can apply to individual objects, such as tables or columns"; Copilot "automatically discovers them and incorporates them into its prompt context".
  • The final chain: "A database owner plants a malicious database constitution… The lower-privileged user controls the instructions that the higher-privileged user executes via Copilot." The result was sysadmin role membership.

Microsoft's documentation. Microsoft's own pages support several of the premises. The database-instructions page says CONSTITUTION.md is the "single highest-precedence instruction for the entire database" and "applies to all GitHub Copilot conversations for every user". It does not say who may create these instructions and carries no prompt-injection warning. The execution-context page (updated June 11, 2026) says Copilot "has no separate permissions", recommends "a dedicated, low-privilege account" rather than sa or dbo, and states that Agent mode's approval step "isn't a security boundary". The admin-controls page lists group policies to disable Copilot entirely, disable Copilot Free, and (from 22.7) disable Agent mode.

Technical analysis

Root cause: a policy written in the wrong layer. SQL Server has had a mature permission model for decades. A read-only assistant is trivially expressed in it: run the assistant's queries under a principal that has only SELECT. The design Rehberger describes instead ran Copilot on the user's own connection, with the user's full rights, and tried to subtract write capability at the application layer, first by asking the model nicely and then by pattern-matching the SQL it produced. T-SQL is a full programming language with dynamic execution, so a regex over its text is a denylist against an unbounded grammar. Once a statement is built at runtime, nothing that inspects the text can know what it will do. This is the same lesson web developers learned with SQL injection filters fifteen years ago, applied to a new author of SQL: the model.

Why it becomes privilege escalation. On its own, the read-only bypass mostly means a user can make Copilot do what that user could already do by typing. The AI angle turns it into a cross-user attack. Copilot mixes three kinds of input into one context: the question from the person at the keyboard, data and metadata from the database, and persistent instructions stored by whoever has rights to set extended properties. A large language model cannot reliably tell these apart. So the effective authority of any Copilot action becomes "the privileges of the person who asked, steered by anyone who could write into what Copilot reads". In a real estate, those are often different people: application teams own databases, DBAs and sysadmins own servers. CONSTITUTION.md, built as a convenience for coding conventions, quietly became a channel from the first group to the second.

The scoring contradiction. MSRC's vector says no privileges are required (PR:N), while Rehberger's headline chain starts from a database owner. Both can be true: injected text can also arrive through data or a shared script file, which a far less privileged party might control. Our assessment: defenders should plan for the worse case, because any table an outsider can write to — a support ticket, a product review, a log row — is text Copilot may later read.

What is novel. Prompt injection into coding agents through repository files is well documented. This case moves the pattern into the database itself, where "configuration for the AI" lives in the same store as business data and is governed by object-level permissions that were never designed with an AI reader in mind. It also shows a recurring vendor pattern we have seen across agents this year: a safety property ("read-only", "asks before acting") presented in the interface while the real control is a prompt or a classifier.

Did Microsoft fix the design or the filter? Microsoft does not say. The September 28 release note that query permissions "are now determined by the connected SQL account's permissions" reads like a move from classifier to permission model. Our assessment: that is consistent with the right fix, but Microsoft has not tied the note to this CVE, and "the connected account's permissions" still means a sysadmin's Copilot can do sysadmin things if it is steered. Only a separate, lower-privileged execution principal removes that.

What remains unclear

  • Which version is fixed. The CVE record, as mirrored by cve.threatint.com, lists versions before 22.8.2 as affected, but 22.8.2's release notes mention no security change, and the MSRC advisory lists no affected product range. Administrators should simply run the current SSMS (22.10.2 when we checked the release notes on October 7).
  • What the fix changed. Neither MSRC nor the release notes describe it. We do not know whether the regex classifier was hardened, replaced by permissions, or both, or whether database instructions are now treated differently.
  • Which Copilot surface. Rehberger calls it "SQL Copilot" and quotes a read-only system prompt; Microsoft's current docs describe Ask and Agent modes, with Agent mode allowed to modify schema "with your approval". Which mode carried the read-only promise, and whether Agent mode was affected the same way, is not stated.
  • Disclosure timeline. The post gives no report date, MSRC response, or bounty. The talk date is given only as "two weeks back" from September 30.
  • Model choice. One of Rehberger's conclusions is that letting users choose the underlying model "can weaken overall safety when some models are less robust against adversarial instructions", but the post does not say which models were tested or how they differed.
  • Who may write database instructions. Rehberger says users with ALTER on an object can change its extended properties without sysadmin rights. Microsoft's instructions page does not state a permission requirement.
  • Exploitation. MSRC lists the flaw as not exploited. We found no report of in-the-wild use.

Lessons and what to do

For DBAs and SQL Server owners

  • Update SSMS on every workstation that has it. It is a client tool, so it is often missed by server patching.
  • Never use Copilot on a sysadmin or sa connection. Rehberger: "If Copilot is connected as sysadmin, a failure in the agent's controls can have system-wide impact."
  • Set a dedicated execution principal for Copilot in each database's CONSTITUTION.md (agentExecuteAsUser, available from SSMS 22.7), created without a login and granted only SELECT on the schemas it needs.
  • Audit extended properties named CONSTITUTION.md and AGENTS.md, and treat the right to create or change them as the right to instruct every Copilot user of that database. Alert on changes.
  • If you do not use Copilot in SSMS, disable it, or at least Agent mode, through the SSMS group policies.
  • Watch for outbound SMB from database servers; xp_dirtree to an external host is a classic exfiltration and hash-capture signal regardless of AI.

For teams building AI features on databases or other systems

  • Make safety properties invariants, not instructions. Rehberger: "Read-only enforcement for an AI agent must be a security invariant (like a permission), not a model instruction or a fragile SQL classifier."
  • Run the agent under its own identity, never the user's ambient privileges. An approval click is not a boundary; Microsoft's own docs say so.
  • Treat any persistent "instructions for the AI" stored alongside data as code: owned, reviewed, permissioned and logged.
  • Assume every string the agent reads is attacker-controlled when deciding what the agent may execute.

For leadership

  • Inventory where AI assistants have been added to administrative tools: database clients, cloud consoles, IDEs. They inherit the operator's privileges by default, and the operator is often your most privileged person.
  • Ask vendors one question about every "read-only" or "safe" AI mode: is it enforced by the system's permission model, or by the model's prompt?

Sources

Primary:

Coverage:

Get the daily brief

AI + security signal by email: headlines, a two-line summary, a link. No noise, no spam.

How often