Hacking Cursor Rules for Fun and Profit

MCP Defender supports multiple AI apps out of the box, including Cursor, Claude, Visual Studio Code and Windsurf. However, MCP Defender integrates deeper into Cursor by writing an MCP Defender specific rule into Cursor's set of global rules.

Cursor recently launched a 1.0 update that changed the way rules are stored from a sqlite database to entirely in memory. To get around this, we identified these two URLs that Cursor uses to load and update Cursor rules:

Add Rule: https://api2.cursor.sh/aiserver.v1.AiService/KnowledgeBaseAdd

Read Rules: https://api2.cursor.sh/aiserver.v1.AiService/KnowledgeBaseList

Here's the entire structure of the requests and responses to the rules API which are built on protobuf:

structure of requests that cursor performs to read and update rules

To properly authenticate these requests, we use the authentication token that Cursor stores here on Mac OS: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb

sqlite db of Cursor where it stores authentication token

The rule that MCP Defender injects into Cursor asks Cursor to include two new arguments into every MCP tool call that are processed by MCP Defender and removed before proxying the traffic to the actual MCP server. The first argument contains both the user's initial request along with the LLM's reasoning to why it needs to make the tool call. This is used to provide the scanning LLM the context around the tool call and improve scan accuracy. The second argument includes all details of the tool including description and arguments so that they can be included in the scan to detect tool poisoning attacks.

Learn more about how MCP Defender secures Cursor