[dead]
A GitHub Issue Title Compromised 4k Developer Machines
181–190 of 216 posts
Re: A GitHub Issue Title Compromised 4k Developer Machines
#182FWIW, the best way to get your website on Hacker News is to write a content-marketing blog post about someone else's work.
Don't get me wrong. This post is an interesting read. But the company publishing it appears to have nothing to do with the exploit or the people who discovered or patched it.
I tip my hat at their successfully marketing :)
Re: A GitHub Issue Title Compromised 4k Developer Machines
#183FWIW, the best way to get your website on Hacker News is to write a content-marketing blog post about someone else's work. Don't get me wrong. This post is an interesting read. But the company publishing it appears to have nothing to do with the exploit or the people who discovered or patched it. I tip my hat at their successfully marketing :)
You mean.. like a newspaper?
Re: A GitHub Issue Title Compromised 4k Developer Machines
#184> Step 2: The AI bot executes arbitrary code. Claude interpreted the injected instruction as legitimate and ran npm install pointing to the attacker's fork - a typosquatted repository (glthub-actions/cline, note the missing 'i' in 'github'). The fork's package.json contained a preinstall script that fetched and executed a remote shell script. Even leaving aside the security nightmare of giving an LLM unrestricted acc…
According to another comment, the title exploits GitHub's forking feature to point at a commit which appeared to be in `github-actions/cline` but which instead invisibly pointed to the typo-squatted repository.
Re: A GitHub Issue Title Compromised 4k Developer Machines
#185Both pnpm and yarn implemented
npmMinimalAgeGate: 1440
enableScripts: false
These mostly solve the issue of adding postinstall scripts and packages being compromised.
Re: A GitHub Issue Title Compromised 4k Developer Machines
#186[dead]
Re: A GitHub Issue Title Compromised 4k Developer Machines
#187Earlier quoted context omitted.
Yes, this has been an issue for so long and GitHub just doesn't care enough to fix it. There's another way it can be exploited. It's very common to pin Actions in workflows these days by their commit hash like this: - uses: actions/checkout@378343a27a77b2cfc354f4e84b1b4b29b34f08c2 But this commit doesn't even have to belong to the preceding repository. You can reference a commit on a fork. Great way to sneak in an xz…
yikes.. there should be the cli equivalent of that warning banner at the very least. combine this with something like gitc0ffee and it's downright dangerous
A YAML linter for it, too. I was appreciating the cron input overlay in the current GitHub Actions VS Code extension. In ghost text beside a cron: 'something' input it gives you a human-readable description. Seems like it could also do a similar thing for actions commit refs, show a simple verification if it corresponds to a tag or not in that repo.
Re: A GitHub Issue Title Compromised 4k Developer Machines
#188What happened to isolating the build box from the Internet? Do people really just let their build systems make outbound connections willy-nilly? That's fucking insanity. People who behave like this are definitely not reviewing their deps.
Re: A GitHub Issue Title Compromised 4k Developer Machines
#189Earlier quoted context omitted.
I guess it's somewhat known that you can trivially fake a repo w/a fork like this but it still feels like a bigger security risk than the "this commit comes from another repository" banner gives it credit for: https://github.com/cline/cline/commit/b181e0
I don't understand, how exactly does `npm install github:cline/cline#b181e0` work? b181e0 is literally a commit, a few deleted lines. npm could parse that as a legit script ???
In git a commit is a full tree snapshot, even though most commit views only show the diff with the previous commit. npm is using the commit hash as a "version number" and grabbing the full git tree snapshot for that point in time. (Just like in git you can always `git checkout b181e0` to end up in a "detached HEAD" state at that commit's tree. So many developers were doing that unintentionally which is why `git switch` requires the `--detach` flag to checkout the tree at a commit, but the same thing is possible `git switch --detach b181e0`.)
Re: A GitHub Issue Title Compromised 4k Developer Machines
#190> Cline’s (now removed) issue triage workflow ran on the issues event and configured the claude-code action with allowed_non_write_users: "*", meaning anyone with a GitHub account can trigger it simply by opening an issue. Combined with --allowedTools "Bash,Read,Write,Edit,Glob,Grep,WebFetch,WebSearch", this gave Claude arbitrary code execution within default-branch workflow. Has everyone lost their minds? AI agent w…
This is how the NPM ecosystem works. Run first, care about consequences later..because, you know, time to market matters more. Who cares about security? This is not new to the NPM ecosystem. At this point, every year there's a couple of funny instances like these. Most memorable one is from a decade ago, someone removed a package and it broke half the internet. From Wikipedia: module.exports = leftpad; function leftp…
This is imo much worse than NPM, and full disclosure NPM is a part of our stack and I do not vet every package - I’d be out of a job if I took the time…
That said, packages can be audited, and people can validate that version X does what it says on the tin.
AI is a black box, however. Doesn’t matter what version, or what instructions you give it, whether it does what you want or even what it purports is completely up to chance, and that to me is a lot more risk to swallow. Leftpad was bad, sure, and it was also trivial to fix. LLMs are a different class of pain all together, and I’m not sure what lasting and effective protection looks like.