When an MCP server you use gets a CVE, first find every place it runs, then check whether the vulnerable code path is reachable, then update or disable it, rotate any credentials it held and confirm the fix. The steps are the same as for any dependency, but agents and credentials make the clock tighter.
Step 1: find every copy
You cannot patch what you cannot list. Search developer machines, CI, shared servers and agent platforms for the package name and its configuration files. Local servers launched through a package runner may not appear in any inventory, so also search MCP client config files.
Step 2: read the advisory carefully
Note the affected versions, the fixed version, the attack conditions and whether it needs network access, a malicious tool description, a crafted URL or local access. Some MCP issues need an attacker to control a server you connect to, others need your server reachable on a network.
Step 3: decide how urgent it is
| Question | If yes |
|---|---|
| Is the server reachable from a network you do not control | Treat as urgent |
| Does it hold production credentials | Treat as urgent |
| Is the vulnerable feature in use | Raise priority |
| Is a fix available | Plan the update now |
| Is it only local with no sensitive access | Schedule, but do not skip |
Exploit status matters too. Check whether the advisory or a trusted feed reports exploitation.
Step 4: contain, then fix
- Disable the server in clients that do not need it today.
- Update to the fixed version and pin it.
- If no fix exists, restrict network access, remove risky tools and add a policy that blocks the affected action.
- Re-run your dependency scan to confirm the old version is gone, including transitive copies.
Step 5: assume credentials were exposed if exploitation is plausible
Rotate keys and revoke tokens held by the server. Review logs for unusual tool calls since the vulnerable version was installed. Short lived tokens make this step cheaper.
Step 6: close the loop
Record what you found, the fix date and what would have made it faster. Add the server to a watch list so you hear about the next advisory. Most teams discover the real gap is the inventory, not the patch.
Safeguard includes reachability analysis and zero-day discovery, SBOM and dependency scanning, and autonomous remediation with fix pull requests that stay off until you turn them on. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Open the vulnerability view and sort by severity and fix availability, then practise the triage questions from step 3 on a finding.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to patch if the server is only local?
Still plan to. Local servers run with your privileges, and some attacks reach them through a browser or a malicious connected server.
How do I know if I am exposed?
Combine an inventory of where the package runs with a check of whether the vulnerable code path is reachable in your use.
Sources
Last reviewed: 19 October 2026.
