# Cursor Ignore-Policy File Write by Agent

- **Severity:** High
- **Signature ID:** `3f8c1d42-9b6e-4a17-8c05-7d21e9b4af60`
- **CVEs:** CVE-2025-64110
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM02 (Sensitive Information Disclosure), LLM06 (Excessive Agency)

## Summary

A bug in the Cursor AI coding assistant lets a new .cursorignore file override every existing ignore-policy file in the project. An attacker who can influence the agent's instructions (via prompt injection) can get it to write one small ignore file and unlock access to previously protected files like .env or key material.

## How the attack works

An AI agent operating inside Cursor is manipulated, usually through content the agent reads and treats as instructions, into creating, overwriting, moving, or deleting a .cursorignore or .cursorindexingignore file anywhere in the project. In vulnerable Cursor versions (<=1.7.23, CVE-2025-64110), creating a new ignore file invalidates the protection rules of all pre-existing ignore files in the workspace. Once that happens, files that were supposed to be off-limits to the model - secrets, credentials, internal source - become readable. The rule flags the moment the agent writes the ignore file itself, since that is the one action that must happen before the bypass can take effect, and it is the only part of this chain that can be reliably observed.

## Why it matters

An attacker who can inject instructions into an agent's context can turn off Cursor's file-access protections and read secrets, credentials, or internal source code that were meant to stay hidden from the model.

## What you can do

- Upgrade Cursor past the version affected by CVE-2025-64110 so new ignore files no longer invalidate existing ones.
- Treat any agent-initiated write to .cursorignore or .cursorindexingignore as worth reviewing, especially when the agent was not explicitly asked to touch ignore files.
- Keep secrets and key material out of the workspace tree entirely, or store them in a location the agent's runtime cannot reach, rather than relying solely on ignore-file protection.
- Audit existing .cursorignore files periodically to confirm they still match what you expect, since a bypass leaves no trace beyond the new file itself.

## Known benign look-alikes

- Developer explicitly asks the agent to create or update .cursorignore to exclude build output, node_modules, large binaries or secrets - the intended, supported workflow.
- Project scaffolding or repo-init templates that generate .cursorignore alongside .gitignore / .dockerignore in one pass.
- Repository restructuring where an ignore file is moved or copied between directories (cp / mv branch), or removed as part of a tooling migration off Cursor.
- Editors or agents performing atomic writes via a .cursorignore.tmp / .cursorignore~ sidecar before rename.
- Dotfile-sync and workspace-bootstrap scripts that reinstall a standard ignore file on every new checkout.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-64110
- https://attack.mitre.org/techniques/T1562/001/

---
Source: https://www.netzilo.com/threats/cursorignore-protection-bypass