Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A GitHub Issue Title Compromised 4k Developer Machines

grith.ai

Post reply on HN
Print view View original

171–180 of 216 posts

Re: A GitHub Issue Title Compromised 4k Developer Machines

#171

Post by zbentley »

msdz wrote: post #159
m-hodges wrote: post #148

Earlier quoted context omitted.

> despite bulletproof input sanitization not having been invented yet! I don’t think it can be.¹ ¹ https://matthodges.com/posts/2025-08-26-music-to-break-model...

Interesting article you’ve linked. I’m not sure I agree, but it was a good read and food for thought in any case. Work is still being done on how to bulletproof input “sanitization”. Research like [1] is what I love to discover, because it’s genuinely promising. If you can formally separate out the “decider” from the “parser” unit (in this case, by running two models), together with a small allowlisted set of tool ca…

Sanitization isn’t enough. We need a way to separate code and data (not just to sanitize out instructions from data) that is deterministic. If there’s a “decide whether this input is code or data” model in the mix, you’ve already lost: that model can make a bad call, be influenced or tricked, and then you’re hosed.

At a fundamental level, having two contexts as suggested by some of the research in this area isn’t enough; errors or bad LLM judgement can still leak things back and forth between them. We need something like an SQL driver’s injection prevention: when you use it correctly, code/data confusion cannot occur since the two types of information are processed separately at the protocol level.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#172

Post by lynndotpy »

yread wrote: post #106

> 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…

No, only the people running the "AI agent" programs have lost their minds. The "everyone's doing it" narrative would be a doomsday if it were true.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#173

Post by Ukv »

Cthulhu_ wrote: post #155
Ukv wrote: post #147

Earlier quoted context omitted.

> AI agent with full rights running on untrusted input in your repo? Boundary was meant to be that the workflow only had read-only access to the repository: > # - contents: read -> Claude can read the codebase but CANNOT write/push any code > [...] > # This ensures that even if a malicious user attempts prompt injection via issue content, > # Claude cannot modify repository code, create branches, or open PRs. https:/…

Yeah but this is the thing, that's just text. If I tell someone "you can't post on HN anymore", whether they won't is entirely up to them. Permissions in context or text are weak, these tools - especially the ones that operate on untrusted input - need to have hard constraints, like no merge permissions.

To be clear - the text I pasted is config for the Github actions workflow, not just part of a prompt being given to a model. The authors seemingly understood that the LLM could be prompt-injected run arbitrary code so put it in a workflow with read-only access to the repo.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#175

Post by spacecadet »

nstart wrote: post #125
yread wrote: post #106

> 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 people intend to run open claw instances too. Some folks are trying to add automated bug report creation by pointing agents at a company's social media mentions. I personally think it's crazy. I'm currently assisting in developing AI policies at work. As a proof of concept, I sent an email from a personal mail address whose content was a lot of angry words threatening contract cancellation and legal actio…

There was a great AI CTF 2 years ago that Microsoft hosted. You had to exfil data through an email agent, clearly testing Outlook Copilot and several of Microsofts Azure Guardrails. Our agent took 8th place, successfully completing half of the challenges entirely autonomously.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#176

Post by zbentley »

_slih wrote: post #102

prompt injection is the new sql injection except there's no prepared statement equivalent

Yep! Minor nitpick: prepared statements aren’t the important property here; driver/protocol-level separation of code and data is. Even without using a prepared statement, if you run the parametrized query “select col from table where x = ?” and pass “foo” for the ? parameter, injection isn’t possible. The query is sent (and parsed and executed) separately from the parameter value.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#177

Post by zbentley »

hunterpayne wrote: post #58
phendrenad2 wrote: post #46

This is fine, right? It's a small price to pay to do, well, whatever it is ya'll like to do with post-install hooks. Now me, I don't really get it. Call me dumb, or a scaredy-cat, but the very idea of giving the hundreds of packages that I regularly install, as necessitated by javascript's lack of a standard library, the ability to run arbitrary commands on my machine, gives me the heebie-jeebies. But, I'm sure you g…

Without it, all a package can do is drop files on a filesystem. Its used to do any sort of setup, initialization or registration logic. Its actually impossible to install many packages without something like it. Otherwise, you end up having to follow a bunch of install instructions (which you will mess up sometimes) after each package gets installed.

Many, many other programming languages’ package managers don’t (or can’t) do this, though.

Even big complex desktop apps can, on first run, request initial setup permissions or postinstall actions via the OS’s permissions approval system.

Genuine question as someone who uses it rarely: why is that need so much more common in NPM? Why are packages so routinely mutating systemwide arbitrary state at install time rather than runtime? Why is “fail at runtime and throw a window/prompt at the user telling them to set something up” not the usual workflow in NPM as it is in so many other places?

Re: A GitHub Issue Title Compromised 4k Developer Machines

#178

Post by zbentley »

zahlman wrote: post #113
hunterpayne wrote: post #58

Earlier quoted context omitted.

Without it, all a package can do is drop files on a filesystem. Its used to do any sort of setup, initialization or registration logic. Its actually impossible to install many packages without something like it. Otherwise, you end up having to follow a bunch of install instructions (which you will mess up sometimes) after each package gets installed.

Can't the unpacked code just detect the uninitialized state and complete the install on first run? (You know, after the developer has had a chance to audit the code, pass security scanners over it etc. before it runs?)

Yeah. Another big benefit of this approach is that it can use or trigger OS-level permissions approval prompts (eg UAC or MacOS’s “do you want to let this program access the desktop?” approvals).

Re: A GitHub Issue Title Compromised 4k Developer Machines

#179

Post by blakec »

The cache key collision is the part that keeps bugging me. Most CI/CD pipelines share a single npm cache across workflows. Cline's triage workflow restored a cache keyed on `${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}` — same key the release workflow used. So a poisoned cache from a low-privilege triage run propagated to the signed release build. No permission escalation needed. The cache is the escalation.

The fix is workflow-scoped cache keys:

  # Before: shared key (vulnerable)
  key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

  # After: workflow-scoped key
  key: ${{ runner.os }}-npm-triage-${{ hashFiles('package-lock.json') }}
But that only addresses one vector. The deeper problem is that every GitHub Action processing untrusted input (issue titles, PR bodies, comment text) is a prompt injection surface. The triage workflow fed the issue title into an LLM prompt. The attacker put executable instructions in the title. The LLM followed them. Classic indirect injection, new delivery mechanism.

On the local side, macOS Seatbelt (sandbox-exec) can deny access to credential paths at the kernel level — the process tree physically can't touch ~/.ssh or ~/.aws regardless of what the agent gets tricked into doing. Doesn't help with cache poisoning, but it closes the exfiltration path on your own machine. ~2ms overhead per command, way lighter than spinning up a container every time.

Post reply on HN