Post by @YourNetworkIsHaunted@awful.systems

2026-09-23 23:24 UTC

I need someone with more actual software dev knowledge to back me up on something. It looks like there’s a new zero-interaction remote code execution vulnerability in most major vibe code generators. I’ve seen it called Plugin4Shell because apparently we’re still doing marketing names instead of actually getting CVE numbers for these things. The link there seems like a decent overview. The bug, dubbed Plugin4Shell, breaks SHA pinning, the mechanism developers rely on to lock an installed plugin to a specific, reviewed version of its code. Pinning is supposed to mean that once a plugin passes review, it cannot change without the developer’s knowledge. AIR’s researchers found that every one of the four agents checks out the pinned commit without verifying the checkout landed there, letting an attacker swap in malicious code while the pin still looks intact. So if I’m reading this right, the mechanism to cryptographically ensure that your AI agents are using the code they say they are just was straight-up not being checked? This feels like it should go on the big board of incredibly obvious failures, but I’m not familiar enough with the git side of things to be absolutely confident in that. Like, if a person tried to pass off software that did this it would have significant career implications, right? Or am I misunderstanding something somewhere?

Replies (2)

@rmf@awful.systems 2026-09-24 02:07

My understanding is that the weakest link here is either git or the way the agents rely on git. So, every commit in a git repository has a unique*, immutable, deterministic identifier. A commit with different content would have a different identifier. It is commonplace to use these identifiers to pin a dependency to a specific commit. In addition to these immutable deterministic identifiers, there are also so-called “refs”, which are mutable identifiers. You use these to point to e.g. “the most recent version”. So if the agent needs a “skill” that is pinned to the commit with ID aaaaaaaaa it will run the checkout command with that ID; this should prevent any shenanigans because only* a commit with the specific content that was vetted earlier will have that ID This attack exploits an unexpected git behavior: the command to checkout a particular commit accepts either a commit ID or a ref, but tries refs first. So what the attacker does is add a ref to the repository named aaaaaaaaa that points to the malicious commit. Then the agent runs git checkout aaaaaaaaa and ends up at the malicious commit instead of the one that was pinned. I don’t know if there’s a way to tell git checkout to ignore refs, but this might actually be a vulnerability in other systems that rely on git like this.

Open ##4825027
@sailor_sega_saturn@awful.systems 2026-09-24 07:09

Like, if a person tried to pass off software that did this it would have significant career implications, right? Typically no. The space of incredibly obvious failures is vast, and this kind of plumbing code isn’t always written by someone who’s been around the block enough times to think about what kinds of things can go wrong. I’ve written worse code when I had only a few years of experience. However companies should know this; so ideally the tool would have gone through a launch review which should have kicked off a security review where a security expert should have read about the git checkout in the design document and started asking questions like “what happens if the repository is taken over” or “why are hashes and branches and tags all in the same field”? Of course security experts are expensive and slow down the darling vibe-coding workflows of Silicon Valley so… Aside: even without this particular vulnerability, SHA-1 is considered weak – git-scm.com/docs/hash-function-transition, so that should have been thought about as well. Dear supply-chain attackers: maybe there’s still a hole here! Good luck!

Open ##4827680