Re-approve MCP server entries whenever their configuration changes
You will set up your editor so any edit to an MCP server entry forces a fresh approval before it runs. This closes the gap where a harmless server approved once gets its command swapped silently.
Approved once, edited later
- Server approved by name
- Config changed in shared repo
- No prompt, malicious command runs
Re-approved on every change
- Any mcpServer edit triggers approval
- Reviewer reads the full command
- Unrecognized changes are rejected
Why it matters
A harmless MCP server approved once can later be turned into a code execution path. In the Cursor case, an attacker with write access to a shared repository could change the already trusted configuration and swap in a malicious command with no warning or re-prompt (CVE-2025-54136 (opens external site)). The fix Cursor shipped requires approval every time an mcpServer entry is modified (GHSA-24mc-g4xr-4395 (opens external site)).
Steps
- Update your editor first. For Cursor, move to version 1.3 or later, since that is the patched release (GHSA-24mc-g4xr-4395 (opens external site)).
- Open your MCP configuration and list every server entry you currently trust. Write down the exact command and arguments for each one.
- Compare that list against the config file committed in your shared repositories. Any entry you do not recognize should be removed or reviewed before you continue.
- Treat changes to MCP config files like changes to build scripts. Require a code review for any diff that touches an mcpServer entry, including command, args, and URL fields.
- After a teammate pulls changes, confirm that the editor prompts you again for any modified server. If it does not prompt, do not approve the server until you have read the new command.
- Re-approve the entry only after you have checked the full command line it will run, not just the server name.
- If you suspect a configuration was swapped, rotate any credentials that server could reach and review recent command history on the machine.
Common mistakes
- Approving a server by name and assuming the name still points to the same command.
- Skipping review on config changes that arrive through a branch merge or a pull.
- Leaving an old editor version in place, which lacks the re-prompt behavior.
- Assuming a server approved once stays approved safely across every future edit.
Checklist
0 of 7 done