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

141–150 of 216 posts

Re: A GitHub Issue Title Compromised 4k Developer Machines

#141

Post by Voklen »

silcoon wrote: post #88

It's not clear to me why running this attack to install OpenClaw? Especially if it's installing the real latest OpenClaw. Is it compromised as well?

It's unclear, but it seems like this was someone testing to see if this exploit would really work. From the article: > The severity was debated - Endor Labs characterised the payload as closer to a proof-of-concept than a weaponised attack - but the mechanism is what matters. The next payload will not be a proof-of-concept.

But it does seem odd not to use an actual payload right away.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#142

Post by dns_snek »

hannob wrote: post #137
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.)

Maybe this is a social experiment and we're the test subjects.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#143

Post by WickyNilliams »

oofbey wrote: post #81
WickyNilliams wrote: post #52

Earlier quoted context omitted.

No such mitigation exists for LLMs because they do not and (as far as anybody knows) cannot distinguish input from data. It's all one big blob

Not true. The system prompt is clearly different and special. They are definitely trained to differentiate it.

Trained != Guaranteed. It's best effort

Re: A GitHub Issue Title Compromised 4k Developer Machines

#144

Post by yunohn »

jonchurch_ wrote: post #4

This article only rehashes primary sources that have already been submitted to HN (including the original researcher’s). The story itself is almost a month old now, and this article reveals nothing new. The researcher who first reported the vuln has their writeup at https://adnanthekhan.com/posts/clinejection/ Previous HN discussions of the orginal source: https://news.ycombinator.com/item?id=47064933 https://news.yc…

> Previous HN discussions

You say this, and yet there are no real comments i.e. discussion in either of them? This must be the HN equivalent of Stack Overflow's infamous "closed as duplicate".

Re: A GitHub Issue Title Compromised 4k Developer Machines

#145

Post by whopdrizzard »

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…

zizmor (https://github.com/zizmorcore/zizmor) and actionlint (runs shellcheck on run: | blocks) provide some bandaid. zizmor detects quite a few typical injection patterns like branch names and shellcheck enforces quoeting rules in the shell snippets

Re: A GitHub Issue Title Compromised 4k Developer Machines

#146

Post by dns_snek »

red_admiral wrote: post #135

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

Full system access = it's not sandboxed, it has access to anything that the user can access, and it seems to use systemd user units which don't require root access.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#147

Post by Ukv »

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…

> 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://github.com/cline/cline/blob/7bdbf0a9a745f6abc09483fe...

To me (someone unfamiliar with Github actions) making the whole workflow read-only like this feels like it'd be the safer approach than limiting tool-calls of a program running within that workflow using its config, and the fact that a read-only workflow can poison GitHub Actions' cache such that other less-restricted workflows execute arbitrary code is an unexpected footgun.

Re: A GitHub Issue Title Compromised 4k Developer Machines

#148

Post by m-hodges »

crote wrote: post #67
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…

No, the real problem is that people keep giving LLMs the ability to take nontrivial actions without explicit human verification - despite bulletproof input sanitization not having been invented yet! Until we do so, every single form of input should be considered hostile. We've already seen LLMs run base64-encoded instructions[0], so even something as trivial as passing a list of commit shorthashes could be dangerous:…

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

Re: A GitHub Issue Title Compromised 4k Developer Machines

#150

Post by Orygin »

hunterpayne wrote: post #73
phendrenad2 wrote: post #72

Earlier quoted context omitted.

I think that helps me understand. What are some examples of things where I'd want initialization or registration? What packages are impossible to install with this, besides cases where npm is used as an alternative to apt/yum to install dev executables?

Create registry entries in a config file for all local printers found in the existing OS configuration. Remember that the installer runs with privileges that the application won't normally have. So anytime you have to use those privileges you don't do it at runtime, you do it at install time. And this requires the hook.

If I install a package and it starts scanning my local printers, it get immediately removed and the author put on a blacklist.

No other ecosystem is that dense, none of them require such stupid and dangerous flows to work.

Post reply on HN