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

131–140 of 216 posts

Re: A GitHub Issue Title Compromised 4k Developer Machines

#131

Post by NewEntryHN »

andybak wrote: post #75

> The issue title was interpolated directly into Claude's prompt via ${{ github.event.issue.title }} without sanitisation. How would sanitation have helped here? From my understanding Claude will "generously" attempt to understand requests in the prompt and subvert most effects of sanitisation.

I would not have helped. People are losing their mind over agents "security" when it's always the same story: You have a black box whose behavior you cannot predict (prompt injection _or not_). You need to assume worst-case behavior and guardrail around it.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#132

Post by Kalabasa »

est wrote: post #104
gfody wrote: post #11

Earlier 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 ???

I think it's pointing to a version of the repo, so npm installs the package.json of that version of the repo.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#133

Post by CrossVR »

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…

Security just isn't their vibe, that's for nerds.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#134

Post by neya »

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 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 leftpad (str, len, ch) {
      str = String(str);

      var i = -1;

      ch || (ch = ' ');
      len = len - str.length;


      while (++i
Everyday I wake up and be glad that I chose Elixir. Thanks, NPM.

https://en.wikipedia.org/wiki/Npm_left-pad_incident

Re: A GitHub Issue Title Compromised 4k Developer Machines

#135

Post by red_admiral »

The article seems to suggest the openclaw on compromised developer machines had something like root rights - "full system access", "install itself as a persistent system daemon surviving reboots".

What am I missing here, I thought npm didn't run as root (unlike say apt-get)?

Re: A GitHub Issue Title Compromised 4k Developer Machines

#136

Post by Sharlin »

SegmentTree wrote: post #130

Isn't the main vulnerability the cache poisoning in GitHub Actions? Yes, the agent installed a malicious package in its workflow. But if GitHub Actions had been properly isolated, the attack would not have been possible. It's basically impossible to protect against malicious injections when consuming unknown inputs. So the safeguard is to prevent agents from doing harm when consuming such inputs. In this case, it see…

> It's basically impossible to protect against malicious injections when consuming unknown inputs.

Oh, it's fully possible. Just don't have a fucking LLM in the loop.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#137

Post by hannob »

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…

> Has everyone lost their minds?

Clearly yes. (Ok, not everyone, but large parts of the IT and software development community.)

Re: A GitHub Issue Title Compromised 4k Developer Machines

#138

Post by Sharlin »

oofbey wrote: post #80
andybak wrote: post #75

> The issue title was interpolated directly into Claude's prompt via ${{ github.event.issue.title }} without sanitisation. How would sanitation have helped here? From my understanding Claude will "generously" attempt to understand requests in the prompt and subvert most effects of sanitisation.

What was the injected title? Why was Claude acting on these messages anyway? This seems to be the key part of the attack and isn’t discussed in the first article.

> Why was Claude acting on these messages anyway?

Because that's how LLMs work. The prompt template for the triage bot contained the issue title. If your issue title looks like an instruction for the bot, it cheerfully obeys that instruction because it's not possible to sanitize LLM input.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#139

Post by silverstream »

woodruffw wrote: post #36
pzmarzly wrote: post #24

The article should have also emphasized that GitHub's issues trigger is just as dangerous as the infamous pull_request_target . The latter is well known as a possible footgun, with general rule being that once user input enters the workflow, all bets are off and you should treat it as potentially compromised code. Meanwhile issues looks innocent at first glance, while having the exact same flaw. EDIT: And if you thin…

Yep, this is essentially it: GitHub could provide a secure on-issue trigger here, but their defaults are extremely insecure (and may not be possible for them to fix, without a significant backwards compatibility break). There's basically no reason for GitHub workflows to ever have any credentials by default; credentials should always be explicitly provisioned, and limited only to events that can be provenanced back t…

This also compounds with npm's postinstall defaults. In this attack chain, the prompt injection triggers npm install on a fork, and postinstall scripts run with the user's full permissions without any audit prompt.

  So you end up with GHA's over-privileged credentials handing off to npm's over-privileged install hooks.

  I've started running --ignore-scripts by default and only whitelisting packages that genuinely need postinstall. It's a bit annoying, but the alternative is trusting   
  every transitive dependency not to do something during install.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#140

Post by Sharlin »

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…

If nothing else, this whole AI craze will provide fascinating material for sociology and psychology research for years to come.
Post reply on HN