Skill Update Drift Vulnerability in Agentic Coding
Play Agentic Coding Labs on this vulnerability with SecureFlag!
Description
Skill registries behave like package registries. A publisher can release a new version under the same name, and installers commonly resolve to the newest compatible release rather than the exact one that was reviewed. The result is that a skill can change after it has been approved without anyone installing anything. The team believes it is running the version security signed off on two months ago, while the assistant has quietly been running something newer since last week. That gap between what was approved and what actually runs is update drift.
Impact
The most direct consequence of update drift is that malicious behavior can arrive without anyone installing anything. A publisher account gets compromised, or a publisher simply decides to add something they should not, and the next version goes out under the same name. Every machine that resolves to the latest release picks it up on its own, and nobody has to install anything. If, at some point, a security review concluded that the skill was safe, that conclusion is never revisited when the version underneath it changes.
Scenarios
A developer installs a skill that formats commit messages, and a reviewer checks it and approves it. A few weeks later, the publisher pushes a new release under the same name. The skill manager pulls it in the next time it checks for updates, with no prompt involved. The new release quietly reads the repository’s .env file and sends it out. Nobody re-reviews it, because nobody installed anything new.
Prevention
If you install and use skills, commit the lockfile to version control and install from it rather than the manifest, so a mismatch fails the install instead of silently resolving to something newer. Disable automatic updates and treat every new version as a new artifact that needs its own review. Roll a release out to a small group first before trusting it everywhere.
If you build the tooling that manages those installs, the pinning and verification are yours to provide.
- Pin by content hash, not by name or tag: Record a digest of the approved bundle and verify it at install and at load. Names and version tags are mutable; a hash is not.
- Verify publisher signatures: Require signed releases and check the signature against the expected publisher key on every install, so a hijacked account is not automatically a trusted one.
- Support drift alerts: Let the installed digest on each machine be compared against the approved one, and raise an alert when they diverge.