TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

273 pointsby varunsharma072 months ago

61 comments

rarkins2 months ago
Hi, Renovate author&#x2F;maintainer here.<p>The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is:<p>1. An attacker had write access to the tj-actions&#x2F;changed-files repo<p>2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate<p>3. Important: this spoofing of commits wasn&#x27;t done to &quot;trick&quot; a maintainer into accepting any PR, instead it was just to obfuscate it a little. It was an orphan commit and not on top of main or any other branch<p>4. As you&#x27;d expect, the commit showed up as Unverified, although if we&#x27;re being realistic, most people don&#x27;t look at that or enforce signed commits only (the real bot signs its commits)<p>5. Kind of unrelated, but the &quot;real&quot; Renovate Bot - just like Dependabot presumably - then started proposing PRs to update the action, like it does any other outdated dependency<p>6. Some people had automerging of such updates enabled, but this is not Renovate&#x27;s default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it&#x27;s run as part of PR builds<p>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it&#x27;s rare for such tags to be changed, they are not immutable by design
评论 #43374697 未加载
评论 #43372940 未加载
评论 #43372529 未加载
评论 #43381744 未加载
评论 #43376990 未加载
评论 #43380645 未加载
mubou2 months ago
In recent years, it&#x27;s started to feel like you can&#x27;t trust third-party dependencies and extensions at all anymore. I no longer install npm packages that have more than a few transitive dependencies, and I&#x27;ve started to refrain from installing vscode or chrome extensions altogether.<p>Time and time again, they either get hijacked and malicious code added, or the dev themselves suddenly decides to betray everyone&#x27;s trust and inject malicious code (see: Moq), or they sell out to some company that changes the license to one where you have to pay hundreds of dollars to keep using it (e.g. the recent FluentAssertions debacle), or one of those happens to any of the packages&#x27; hundreds of dependencies.<p>Just take a look at eslint&#x27;s dependency tree: <a href="https:&#x2F;&#x2F;npmgraph.js.org&#x2F;?q=eslint" rel="nofollow">https:&#x2F;&#x2F;npmgraph.js.org&#x2F;?q=eslint</a><p>Can you really say you trust all of these?
评论 #43369437 未加载
评论 #43369968 未加载
评论 #43369317 未加载
评论 #43369237 未加载
评论 #43369246 未加载
评论 #43369225 未加载
评论 #43369619 未加载
评论 #43371409 未加载
评论 #43369758 未加载
评论 #43374080 未加载
评论 #43369546 未加载
评论 #43371282 未加载
评论 #43369958 未加载
评论 #43371369 未加载
评论 #43386553 未加载
评论 #43369454 未加载
评论 #43370011 未加载
评论 #43369340 未加载
评论 #43370889 未加载
评论 #43371617 未加载
评论 #43369257 未加载
评论 #43372920 未加载
评论 #43370773 未加载
评论 #43370946 未加载
评论 #43369956 未加载
评论 #43369278 未加载
评论 #43373195 未加载
评论 #43369509 未加载
评论 #43369557 未加载
评论 #43372511 未加载
评论 #43369514 未加载
评论 #43369391 未加载
kurmiashish2 months ago
Disclaimer: I am a co-founder of StepSecurity.<p>StepSecurity Harden-Runner detected this security incident by continuously monitoring outbound network calls from GitHub Actions workflows and generating a baseline of expected behaviors. When the compromised tj-actions&#x2F;changed-files Action was executed, Harden-Runner flagged it due to an unexpected endpoint appearing in the network traffic—an anomaly that deviated from the established baseline. You can checkout the project here: <a href="https:&#x2F;&#x2F;github.com&#x2F;step-security&#x2F;harden-runner" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;step-security&#x2F;harden-runner</a>
评论 #43373052 未加载
评论 #43372587 未加载
harrisi2 months ago
It&#x27;s always been shocking to me that the way people run CI&#x2F;CD is just listing a random repository on GitHub. I know they&#x27;re auditable and you pin versions, but it&#x27;s crazy to me that the recommended way to ssh to a server is to just give a random package from a random GitHub user your ssh keys, for example.<p>This is especially problematic with the rise of LLMs, I think. It&#x27;s the kind of common task which is annoying enough, unique enough, and important enough that I&#x27;m sure there are a ton of GitHub actions that are generated from &quot;I need to build and deploy this project from GitHub actions to production&quot;. I know, and do, know to manually run important things in actions related to ssh, keys, etc., but not everyone does.
评论 #43369504 未加载
评论 #43369465 未加载
评论 #43374531 未加载
评论 #43371170 未加载
评论 #43380812 未加载
评论 #43369503 未加载
Sytten2 months ago
I am surprised nobody here mentionned immutable github actions that are coming [1]. Been waiting for them since the issue was open in 2022. This would have significantly reduce impact and hopefully github will get it over the finish line.<p>I always fork my actions or at least use a commit hash.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;features&#x2F;preview&#x2F;immutable-actions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;features&#x2F;preview&#x2F;immutable-actions</a>
评论 #43372509 未加载
评论 #43372840 未加载
ebfe12 months ago
Doing a bit of investigation with github_events in clickhouse, it is quite clear that the accounts used to perform the attack was &quot;2ft2dKo28UazTZ&quot;, &quot;mmvojwip&quot; also seems suspicious:<p><a href="https:&#x2F;&#x2F;play.clickhouse.com&#x2F;play?user=play#c2VsZWN0ICogZnJvbSBnaXRodWJfZXZlbnRzIHdoZXJlIGV2ZW50X3R5cGU9J0ZvcmtFdmVudCcgYW5kIHJlcG9fbmFtZSA9ICd0ai1hY3Rpb25zL2NoYW5nZWQtZmlsZXMnIGFuZCBjcmVhdGVkX2F0ID4gbm93KCkgLSBpbnRlcnZhbCAzMCBkYXkgYW5kIGNyZWF0ZWRfYXQgPCBub3coKSAtIGludGVydmFsIDEgZGF5IDsK" rel="nofollow">https:&#x2F;&#x2F;play.clickhouse.com&#x2F;play?user=play#c2VsZWN0ICogZnJvb...</a><p>Actions taken by the threat actor at the time can be seen here:<p><a href="https:&#x2F;&#x2F;play.clickhouse.com&#x2F;play?user=play#c2VsZWN0ICogZnJvbSBnaXRodWJfZXZlbnRzIHdoZXJlIGFjdG9yX2xvZ2luIGluICgnMmZ0MmRLbzI4VWF6VFonLCAnbW12b2p3aXAnKQ==" rel="nofollow">https:&#x2F;&#x2F;play.clickhouse.com&#x2F;play?user=play#c2VsZWN0ICogZnJvb...</a>
评论 #43373106 未加载
评论 #43371495 未加载
dan_manges2 months ago
GitHub Actions should use a lockfile for dependencies. Without it, compromised Actions propagate instantly. While it&#x27;d still be an issue even with locking, it would slow down the rollout and reduce the impact.<p>Semver notation rather than branches or tags is a great solution to this problem. Specify the version that want, let the package manager resolve it, and then periodically update all of your packages. It would also improve build stability.
评论 #43369599 未加载
评论 #43369433 未加载
评论 #43369404 未加载
评论 #43369310 未加载
评论 #43369247 未加载
评论 #43369339 未加载
themgt2 months ago
This is hilarious, the maven-lockfile project &quot;Lockfiles for Maven. Pin your dependencies. Build with integrity&quot; appears to have auto-merged a PR for the compromised action commit. So the real renovate bot immediately took the exfiltration commit from the fake renovate bot and started auto-merging it into other projects:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;chains-project&#x2F;maven-lockfile&#x2F;pull&#x2F;1111" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;chains-project&#x2F;maven-lockfile&#x2F;pull&#x2F;1111</a>
评论 #43369849 未加载
评论 #43369861 未加载
onnimonni2 months ago
It seems pretty awful that the de-facto way to use GitHub Actions is using git tags which are not immutable. For example to checkout code [1]:<p>- uses: actions&#x2F;checkout@v4<p>Github does advise people to harden their actions by referring to git commit hashes [2] but Github currently only supports SHA-1 as hashing algorithm. Creating collisions with this hashing algo will be more and more affordable and I&#x27;m afraid that we will see attacks using the hash collisions during my lifetime.<p>I wish that they will add support for SHA-256 soon and wrote product feedback regarding it here: <a href="https:&#x2F;&#x2F;github.com&#x2F;orgs&#x2F;community&#x2F;discussions&#x2F;154056" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;orgs&#x2F;community&#x2F;discussions&#x2F;154056</a><p>If this resonates with you please go and give it a thumbs up :)<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;actions&#x2F;checkout?tab=readme-ov-file#usage" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;actions&#x2F;checkout?tab=readme-ov-file#usage</a><p>[2]: <a href="https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;security-for-github-actions&#x2F;security-guides&#x2F;security-hardening-for-github-actions#using-third-party-actions" rel="nofollow">https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;security-for-github-actio...</a>
评论 #43374187 未加载
评论 #43373926 未加载
frenchtoast82 months ago
The repository is back online, with this explanation from the developer:<p>&gt; This attack appears to have been conducted from a PAT token linked to @tj-actions-bot account to which &quot;GitHub is not able to determine how this PAT was compromised.&quot;<p>&gt; Account Security Enhancements<p>&gt; * The password for the tj-actions-bot account has been updated.<p>&gt; * Authentication has been upgraded to use a passkey for enhanced security.<p>&gt; * The tj-actions-bot account role has been updated to ensure it has only the minimum necessary permissions.<p>&gt; * GitHub proactively revoked the compromised Personal Access Token (PAT) and flagged the organization to prevent further exploitation.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;issues&#x2F;2464#issuecomment-2727020537" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;issues&#x2F;2464#issu...</a>
评论 #43376585 未加载
评论 #43376370 未加载
oefrha2 months ago
&gt; <a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;pull&#x2F;2460" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;pull&#x2F;2460</a><p>This kind of auto dependency bump bots are more trouble than their worth. If your app works today, bumping random deps won’t make it work better in any meaningful sense in 95% of cases. With such a small upside, the downside of introducing larger attack surfaces, subtle breakages (despite semver), major breakages, and in the worst cases, compromises (whether it’s a compromised dep, or fake bot commits that people are trained to ignore) just completely outweighs the upside. You’re on the fast lane to compromises by using this kind of crap.<p>People should really learn from Go’s minimum version selection strategy.
评论 #43372852 未加载
simonw2 months ago
I&#x27;ve always felt uncomfortable adding other people&#x27;s actions to my GitHub workflows, and this is exactly the kind of thing I was worried about.<p>I tend to stick to the official GitHub ones (actions&#x2F;setup-python etc) plus the <a href="https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;gh-action-pypi-publish" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;gh-action-pypi-publish</a> one because I trust the maintainers to have good security habits.
评论 #43374072 未加载
jasonthorsness2 months ago
I think this article from earlier today was the discoverer who opened the issue<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43367987">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43367987</a>
londons_explore2 months ago
So this dumps env to stdout using some obfustucated code? And then relies on the fact logs are viewable publicly so the attacker can go scrape your secrets.<p>If so, why did they use obfustucated code? Seems innocuous enough to load env into environment vars, and then later to dump all env vars as part of some debug routine. Eg. &#x27;MYSQL env var not set, mysql integration will be unavailable. Current environment vars: ${dumpenv}&#x27;
评论 #43369660 未加载
评论 #43369621 未加载
评论 #43369692 未加载
cedws2 months ago
I called it:<p><a href="https:&#x2F;&#x2F;cedwards.xyz&#x2F;github-actions-are-an-impending-security-disaster&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cedwards.xyz&#x2F;github-actions-are-an-impending-securit...</a>
random172 months ago
I wish Github required some sort of immutability for actions by default as most package managers do, either by requiring reusable actions to be specified via commit hash or by preventing the code for a published tag to be changed.<p>At the moment the convention is to only specify the tag, which is not only a security issue as we see here, but may also cause workflows to break if an action author updates the action.
评论 #43369410 未加载
评论 #43370690 未加载
mirashii2 months ago
Not the first time this particular action has had a vulnerability, either.<p><a href="https:&#x2F;&#x2F;nvd.nist.gov&#x2F;vuln&#x2F;detail&#x2F;CVE-2023-51664" rel="nofollow">https:&#x2F;&#x2F;nvd.nist.gov&#x2F;vuln&#x2F;detail&#x2F;CVE-2023-51664</a>
评论 #43369772 未加载
hn87262 months ago
I wish Github didn&#x27;t just purge entire repositories&#x2F;accounts in the event like this, although I know why they do this. But there&#x27;s now no way to analyze the repository&#x2F;exploit anymore
captn3m02 months ago
Helpful update: The gist author has deleted the gist, so <a href="https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;nikitastupin&#x2F;30e525b776c409e03c2d6f328f254965&#x2F;raw&#x2F;memdump.py" rel="nofollow">https:&#x2F;&#x2F;gist.githubusercontent.com&#x2F;nikitastupin&#x2F;30e525b776c4...</a> now results in a 404, and stops the action from any further secrets being leaked. This means you&#x27;re impacted only if you used the action, and had a build triggered in the last 6 hours or so.
评论 #43370616 未加载
评论 #43371256 未加载
rahulr06092 months ago
For folks looking for a drop-in replacement for v45 (latest major version), we have a patched mirror here: <a href="https:&#x2F;&#x2F;github.com&#x2F;trmlabs&#x2F;changed-files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;trmlabs&#x2F;changed-files</a><p>1] We took the public mirror from: <a href="https:&#x2F;&#x2F;code.forgejo.org&#x2F;tj-actions&#x2F;changed-files&#x2F;src&#x2F;tag&#x2F;v45.0.7" rel="nofollow">https:&#x2F;&#x2F;code.forgejo.org&#x2F;tj-actions&#x2F;changed-files&#x2F;src&#x2F;tag&#x2F;v4...</a><p>2] Undid the malicious code change: <a href="https:&#x2F;&#x2F;code.forgejo.org&#x2F;tj-actions&#x2F;changed-files&#x2F;commit&#x2F;0e58ed8671d6b60d0890c21b07f8835ace038e67" rel="nofollow">https:&#x2F;&#x2F;code.forgejo.org&#x2F;tj-actions&#x2F;changed-files&#x2F;commit&#x2F;0e5...</a> - You can see the change here: <a href="https:&#x2F;&#x2F;github.com&#x2F;trmlabs&#x2F;changed-files&#x2F;commit&#x2F;8567847ee196216df6a277444531c8f5e18478ed" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;trmlabs&#x2F;changed-files&#x2F;commit&#x2F;8567847ee196...</a><p>3] Published under a v1 tag (since we can&#x27;t vet historical releases and changes and didn&#x27;t want folks to get confused)<p>If you want to contribute or report an issue, file a GH Issue or ping us at security@trmlabs.com
nomilk2 months ago
I&#x27;d used GitHub Actions for at least 6-12 months before even realising &lt;thing&gt;&#x2F;&lt;thing&gt; was not something that got parsed by the action (like a namespace and method&#x2F;function), but was simply a reference to a github user name and repo. That whole object should really have been called a &#x27;repo&#x27;, because that&#x27;s what it is, and that would alert users to use extreme caution whenever using one that wasn&#x27;t created by themselves.
评论 #43371465 未加载
dboreham2 months ago
Good policy to fork all actions not owned by a reputable organization (e.g. github themselves).
评论 #43369432 未加载
sangeeth962 months ago
Don’t want to be alarmist but even if not using this action directly, I wonder what implications might be if this has leaked tokens from prominent public-facing project repos which might be used by several folks? I spotted an issue[1] to fix this in Expo EAS CLI and I’m guessing there are many more. The payload I saw from the report only seems to dump things to stdout but I guess analysis is still in progress and IDK if it’s the same payload for all the tags.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;expo&#x2F;eas-cli&#x2F;pull&#x2F;2948&#x2F;files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;expo&#x2F;eas-cli&#x2F;pull&#x2F;2948&#x2F;files</a>
xyst2 months ago
Pretty good timing on the attacker.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;tags?after=v35.9.3" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;tags?after=v35.9...</a><p>Most folks around the world signed off. B-squad probably left cleaning up remaining tasks or just fucking around with co-workers and pondering the weekend. Most GH actions run on a schedule (ie, backups of db, connecting to blob storage services).<p>Attacker(s) likely to extract plenty of secrets and exfil data before the alarms get triggered (if any) at companies.<p>The next data dumps are going to be wild.
gbraad2 months ago
Am I seeing this correctly, that a (fake&#x2F;impersonation?) Renovate bot actually proposed the fix... and then other repositories trickled that fix in, also suggested by Renovate or Dependabot, as the dependency updated?<p>I usually fork (or create my own) actions, as I do not trust the whole chain on GitHub. The marketplace does no enforcement. It is really based on trust you have in the 3rd-party... and I do not have this; as many actions have side-effects, or only operate on a specific runner OS, etc.
评论 #43373891 未加载
mgiladi2 months ago
We&#x27;ve recently released open-source tools that would have easily prevented this:<p>1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: <a href="https:&#x2F;&#x2F;github.com&#x2F;apiiro&#x2F;PRevent" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;apiiro&#x2F;PRevent</a><p>2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevant CI&#x2F;CD stages: <a href="https:&#x2F;&#x2F;github.com&#x2F;apiiro&#x2F;malicious-code-ruleset" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;apiiro&#x2F;malicious-code-ruleset</a><p>3. For a better understanding of the detection, the malicious code falls precisely into the patterns presented in our research: <a href="https:&#x2F;&#x2F;apiiro.com&#x2F;blog&#x2F;guard-your-codebase-practical-steps-and-tools-to-prevent-malicious-code&#x2F;" rel="nofollow">https:&#x2F;&#x2F;apiiro.com&#x2F;blog&#x2F;guard-your-codebase-practical-steps-...</a>
评论 #43381414 未加载
skwashd2 months ago
The GitHub repo and org disappeared while I was poking around. Both <a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files</a> return 404.
评论 #43371600 未加载
tsujamin2 months ago
How does SBOM and such account for this? If you’re a package maintainer, do you need to include CI pipeline plugins, their dependencies, going down as far as the pipeline host, in your security-relevant dependencies? Hard problems :&#x2F;
评论 #43369926 未加载
varunsharma072 months ago
I’m Varun, CEO &amp; Co-Founder of StepSecurity. StepSecurity detected and reported the tj-actions&#x2F;changed-files compromise and has been actively helping the community recover from this incident.<p>To support you in understanding what happened and recovering swiftly, we’re hosting an Office Hour:<p>Date: March 17, 2025 Time: 10:00 AM Pacific Time (PT) Add to your calendar: <a href="https:&#x2F;&#x2F;www.addevent.com&#x2F;event&#x2F;Tf25207322" rel="nofollow">https:&#x2F;&#x2F;www.addevent.com&#x2F;event&#x2F;Tf25207322</a>
评论 #43381401 未加载
xyst2 months ago
A company I worked at went all in on GH too. The internal gh team probably going to do a fire drill this whole weekend and app teams forced to rotate all secrets and credentials.<p>Fortunately don’t have to deal with that shit anymore
评论 #43369383 未加载
评论 #43374681 未加载
prmph2 months ago
To me the only solution is that we need a security in depth approach:<p>- Create a trusted packages program, and mark trusted packages with a prominent badge. Package authors can apply to join the program, which will involve a review of their package and any subsequent updates. Ensure trusted packages can only depend on other trusted packages.<p>- Implement a capabilities model for package managers. I hear Deno is better in that respect.<p>- Have the package manager back-end use AI to continually review the packages. If anything suspicious is found, flag it and investigate manually.<p>- Require all packages to be name-spaced
评论 #43372725 未加载
varunsharma072 months ago
<a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;issues&#x2F;2463" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files&#x2F;issues&#x2F;2463</a>
kurmiashish2 months ago
Due to the ongoing security incident involving the tj-actions&#x2F;changed-files Action, we at StepSecurity have provided a secure, drop-in replacement: step-security&#x2F;changed-files.<p>We strongly advise replacing all instances of tj-actions&#x2F;changed-files in your workflows with our secure alternative: <a href="https:&#x2F;&#x2F;github.com&#x2F;step-security&#x2F;changed-files" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;step-security&#x2F;changed-files</a>
评论 #43375774 未加载
评论 #43375744 未加载
评论 #43376089 未加载
deathanatos2 months ago
I&#x27;ve said this before, but in my mind the central problem in supply chain issues is this. Choose one:<p>1. You fix what version you&#x27;re using to a fixed, immutable package. You receive no updates, no bug fixes, no security patches.<p>2. You follow a pointer to something like a API-compatible version, &quot;latest&quot; (#yolo) or ^5.0.0. You get bug fixes, security patches, but someone can push malicious updates.<p>Security types, IME, invariably want <i>both</i>: fix that package to a hash, so that we can&#x27;t have a take over attack. But also we need to stay on top of updates, because we don&#x27;t want to find out we have a decades old struct4j CVE buried in our codebase just waiting to be exploited.<p>So to accomplish &quot;both&quot;, then we get into schemes like &quot;fix the hashes … but we&#x27;ll have a bot¹ update our dependency tree automatically&quot;. So like, #2, with more steps. Is anyone actually <i>vetting</i> that that update hash isn&#x27;t going to compromise stuff? Hell no, no company is hiring that level of engineers; I&#x27;m lucky to have decent staffing for our primary concerns, reading the code in the dependency tree is out of the question.<p>And I&#x27;m sure in the coming days, security minded people will stampede in the general direction of #1. Stuff&#x27;ll get fixed to hash, and stuff&#x27;ll stop getting security patches.<p>IDK what the <i>answer</i> is, these seem pretty like fundamentally opposed forces of nature. The staffing problems aren&#x27;t a technical problem, that&#x27;s a capitalism problem, mostly in that there is very little to no penalty for a breach, so why would anyone hire the eng required to ensure the software works. There was hardly regulation in 2024, and any fines I did see regulatory bodies award are pittances, without fail. And, what regulation there was is now being actively dismantled.<p>There is some discussion of signed packages in this thread, and that&#x27;s a helpful idea, I think, though I don&#x27;t think it completely eliminates the problem: if the signing key is compromised, we&#x27;re back to square one. The lay eng struggles with PKI.<p>¹While there is a bot of such nature (the renovate bot) somewhat tied up in this <i>particular</i> instance, I wouldn&#x27;t over-focus on that bot, specifically; renovate, in particular, is not that relevant to the point I&#x27;m trying to make.
评论 #43376463 未加载
jasonthorsness2 months ago
Wow that&#x27;s scary, they updated tons of tags to an offending random commit. With the way repositories are included in automation and the fact that this adjusted the tags of older versions (so not requiring an upgrade) this sort of attack can have a huge impact very quickly :(.<p>Maybe GitHub should have some kind of security setting a repo owner can make that locks-down things like old tags so after a certain time they can&#x27;t be changed.
评论 #43373254 未加载
naikrovek2 months ago
I’ve been saying for a while that there aren’t supply chain problems when the supply chain is the problem.<p>I’m getting to the point where I feel that library use at all should be frowned upon, unless it is your own library, with obvious exceptions for the most widely used things like encryption and authentication. None of these things are particularly difficult, people just don’t want to do them “oh noes my velocity”
评论 #43369825 未加载
m4rtink2 months ago
Another reason why you should be getting software via distro, with searate maintainers taking care of it there rather than directly from the developers that can inject malware via the very next version you mindlessly pull in without checking.<p>Also due to here being usually more than one distro, more people will look at the code &amp; can spot the usptream getting rogue or getting compromised.
评论 #43373166 未加载
varunsharma072 months ago
What Happened? • The compromised Action executes a Python script that dumps CI&#x2F;CD secrets from the Runner Worker process. • Multiple v35 tags were modified four hours ago, indicating a recent supply chain attack. • The malicious behavior can be observed in StepSecurity Harden-Runner insights, showing the Action downloading and executing an unauthorized script.
rajbot2 months ago
This GitHub Action is still compromised, leaving thousands of repositories vulnerable.<p>Is there anyone here from GitHub that can help get this fixed?
samschooler2 months ago
<a href="https:&#x2F;&#x2F;gist.github.com&#x2F;gmatuz&#x2F;7186f583df5f28196cc1f402af3bfa1b" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;gmatuz&#x2F;7186f583df5f28196cc1f402af3bf...</a><p>This gist is pretty much the exact code, from the base64 encoded stuff. Looks like who ever put this in at least neafed the shell script.
mellosouls2 months ago
A list of projects claimed to be using it from the GitHub page:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files?tab=readme-ov-file#open-source-projects-" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;changed-files?tab=readme-ov-fi...</a>
评论 #43369863 未加载
btown2 months ago
Does anyone know if <a href="https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;verify-changed-files&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tj-actions&#x2F;verify-changed-files&#x2F;</a> was compromised as well?
v1sionSec2 months ago
As the repo is was taken down is someone able to tell me when was the malicious commit pushed. Trying to get a timeline to see if any workflows using this action were trigger in that timeframe. Thank you
评论 #43372636 未加载
评论 #43372986 未加载
edoceo2 months ago
Noob question: is it possible to version lock these things? Could one &quot;vendor&quot; these tools into a fork and use that in the pipeline? Maybe it&#x27;s one of those possible but crazy endeavour?
评论 #43369639 未加载
mmsc2 months ago
Paid Github organizations have a policy to block third-party actions. Would be nice if there was a way to allow third-party actions as long as they are referenced by hash, not version.
nextts2 months ago
Well timed for the weekend. Some teams may notice Monday morning.
MotiBanana2 months ago
Does anyone know if the secrets compromised were sent out, or just printed to stdout? We don&#x27;t have any public repos using this action.
评论 #43373009 未加载
alper2 months ago
GitHub’s incident response to this took 17 hours give or take.<p>Actions is a paid service but Microsoft probably replaced all the security teams with AI.
Everdred2dx2 months ago
How does this siphon the secrets away? It looks like it just dumps them out to stdout and stops there.
评论 #43370641 未加载
imglorp2 months ago
Anybody have a snapshot of the good one, or maybe a drop in replacement? The repo is gone now.
评论 #43372867 未加载
londons_explore2 months ago
&gt; await exec.getExecOutput(&#x27;bash&#x27;, [&#x27;-c&#x27;, `echo &quot;aWYgW1sgIiRPU1RZUEUiID09ICJsaW51eC1nbnUiIF1dOyB0aGVuCiAgQjY0X0JMT<p>This malicious code isn&#x27;t hard to recognise... Surely someone can run an LLM over all code in GitHub and just ask it &#x27;does this code looks like it&#x27;s blatantly trying to hide some malicious functionality&#x27;?<p>Then review the output and you&#x27;ll probably discover far more cases of this sort of thing.
评论 #43371869 未加载
eacapeisfutuile2 months ago
What is the current state? Tags reverted or still poisoned?
评论 #43371511 未加载
eacapeisfutuile2 months ago
Was the entire repo just deleted from GitHub?
stephenr2 months ago
I&#x27;m sorry I must be missing something.<p>The examples from the repo itself aren&#x27;t helping to explain.<p>Why would anyone use this whole convoluted nodejs thing when `git diff-tree` exists?<p>I&#x27;m struggling to see a scenario where this isn&#x27;t just part of some deliberately over complicated rube Goldberg setup.
greatgib2 months ago
Honestly now most people doing &quot;modern software engineering&quot; are retards with no concept of real software engineering concepts.<p>Shitload of cardboard cto are pushing for &quot;modern practice&quot; to use whatever new version of whatever random dependency downloaded straight from internet.<p>Some persons asked why I don&#x27;t like Ruff or UV for Python for example? You start a new job, first thing you have to do after installing a serious and safe Linux distribution like debian:<p>Curl whateverwebsite.com&#x2F;ruff&#x2F;download&#x2F;latest | bash --blindly-execute --like-an-idiot<p>-&gt; retrieving-random-dependancy1.tgz<p>-&gt; executing-random-code...<p>And I don&#x27;t speak about the current trend with &quot;pre-commit&quot; where a lot of persons are ok to have automatic downloads and execution on dev machines and ci, at each commit, of hundred of really totally random plugins from random places.<p>But this is a cto enforced decision to have this pre-commit for software quality...
评论 #43373029 未加载
neuroelectron2 months ago
CI was sold as a solution for engineers having too much sovereignty. So that&#x27;s what they got.
joshka2 months ago
Just leaving this here...<p><a href="https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;security-for-github-actions&#x2F;security-guides&#x2F;security-hardening-for-github-actions" rel="nofollow">https:&#x2F;&#x2F;docs.github.com&#x2F;en&#x2F;actions&#x2F;security-for-github-actio...</a>
vimgrinder2 months ago
with all the AI stuff going around, can&#x27;t github just scan repos for such malicious code?
globular-toast2 months ago
Shocked Pikachu anyone?
mdaniel2 months ago
The semgrep URL about this seems to have won the submission lottery: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43368870">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43368870</a>
sathyabhat2 months ago
See also - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43368870">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43368870</a>