Rotate every credential the developer account could read while the bad version was installed: cloud keys, source host tokens, package registry tokens, SSH keys, and anything stored in config files or environment variables. These tools run as the user, so the exposure is what that user could read, not only what the tool needed.
Why the scope is wide
The VS Code documentation states that extensions run with the same permissions as the editor and can read and write files, make network requests and run processes. The Kubernetes documentation says kubectl plugins are arbitrary programs running on your machine. GitHub's documentation says extensions outside its control are not certified. The pattern repeats across tools: whatever the user can read, the tool can read.
So the first question is not "what did the tool do", which you may not be able to know. It is "what could this user account reach during the exposure window?"
Step 1: define the window
Find the first date the bad version could have reached the machine, and the date it was removed. Use update logs, your extension inventory, package manager history or device management records. Anything the account could access in that window is in scope. If you cannot fix the start date, use the release date of the bad version, or the last point you can prove was clean.
Step 2: build the rotation list
| Where it lives | Examples | Action |
|---|---|---|
| Cloud credential files and profiles | Access keys, session tokens | Revoke and reissue; check access logs |
| Source host | Personal access tokens, app tokens, SSH keys | Revoke; list and review authorized keys |
| Package registries | Publish tokens | Revoke; check for unexpected releases |
| Kubernetes and infrastructure config | kubeconfigs, provider credentials | Rotate cluster credentials; revoke exec tokens |
| Environment variables | API keys loaded in shells | Rotate those present in the profile and in running sessions |
| Config files in repositories | Local env files, secret files | Rotate and remove from the working tree |
| Browser sessions | Tool and console logins | Sign out everywhere, reset where indicated |
| Password manager vault | Only if the manager was unlocked and exposed | Treat as high priority; assess vendor guidance |
GitHub's guidance helps with scoping: fine-grained tokens are limited to one owner and specific permissions, while classic tokens are broader. After rotation, replace broad tokens with narrow ones.
Step 3: check for use of the old credentials
Revocation stops future use. Logs tell you whether the credentials were already used. Review source host audit logs, registry publish events and cloud access logs for the window, looking for unfamiliar addresses, unusual times and actions the developer does not normally do.
Step 4: reduce what you are rotating next time
Move to short lived credentials issued at login. Keep production access off day to day laptops. Use separate profiles or machines for risky exploration. Rotation drills are far easier when there are fewer long lived secrets.
Step 5: rebuild the machine if in doubt
If you cannot say with confidence what the tool did, reimage the machine, then restore from clean sources. Rotating credentials while a persistent foothold remains is wasted effort.
Step 6: tell the right people
Notify the owners of the systems whose credentials were rotated, and tell the rest of the team which version to avoid. Record the incident, the window and the actions. It becomes the template for the next one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory is matched to the packages you actually use.
Where Safeguard fits
Safeguard's zero-day discovery and SBOM and dependency scanning help you learn which projects use an affected package, and agent identity and policies help limit what tools can reach. The free scan is at gold.safeguard.sh/scan.
Quick check
Should I rotate only the credentials the tool used?
No. Rotate what the user account could read, because you often cannot know what the tool actually touched.
Is rotation enough on its own?
Not if a foothold remains. If you cannot rule it out, rebuild the machine, then rotate.
Sources
- Extension runtime security, Visual Studio Code documentation
- Extend kubectl with plugins, Kubernetes documentation
- Using GitHub CLI extensions, GitHub Docs
- Managing your personal access tokens, GitHub Docs
Last reviewed: 19 October 2026.
