Hi! Not sure if you're aware of but there's a heavy supply chain attack going on since a couple of days affecting popular NPM and PyPi packages. Credentials and CI tokens from package maintainers have been harvested beforehand and now they're poisoning what they can with info stealers.
Hi! Not sure if you're aware of but there's a heavy supply chain attack going on since a couple of days affecting popular NPM and PyPi packages. Credentials and CI tokens from package maintainers have been harvested beforehand and now they're poisoning what they can with info stealers.
See for reference:
- https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
- https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
- https://www.bleepingcomputer.com/news/security/trivy-vulnerability-scanner-breach-pushed-infostealer-via-github-actions/
So to evade this, versions of all package dependencies have to be pinned exactly.
But still, this may not help with transient packages I'm afraid.
And I'm no expert on nodejs but to me it looks like pinning with ^ does open the door for poisoned patch versions, e.g. "^1.2.3" may result in v1.2.4 being pulled: https://github.com/jkingsman/Remote-Terminal-for-MeshCore/blob/main/frontend/package.json
<!-- github-sync-id:4176805814 -->
The compromised Axios versions were pulled by the time I learned about this last night, but more pertinently, we don't depend on Axios whatsoever (directly or transitively).
I'm not going to freeze all dependency versions at this time since our npm ci usage gives us reproducible builds with locked trees as defense against similar attacks going forward.
Exact pinning in package.json doesn’t really eliminate transitive risk; it just shifts the risk into bigger, less frequent bangs rather than reducing overall exposure.
Happy to revisit if new information comes out, but at this point the risk from this incident is mitigated (and never really existed) for this project.
Eyy good looking out.
The compromised Axios versions were pulled by the time I learned about this last night, but more pertinently, we don't depend on Axios whatsoever (directly or transitively).
I'm not going to freeze all dependency versions at this time since our `npm ci` usage gives us reproducible builds with locked trees as defense against similar attacks going forward.
Exact pinning in package.json doesn’t really eliminate transitive risk; it just shifts the risk into bigger, less frequent bangs rather than reducing overall exposure.
Happy to revisit if new information comes out, but at this point the risk from this incident is mitigated (and never really existed) for this project.
<!-- github-comment-id:4163508371 -->
I know that it doesn't depend on Axios... my concern was more about all other dependencies and their transitive dependencies which may get infected sooner or later as well. Nobody knows yet how many credentials / CI token got harvested by these actors.
So to some degree people (like me) who keep building the projects on an almost daily basis are at higher risk now.
But as you confirmed: if transitive dependencies get poisoned, strict pinning won't help.
I primarily wanted to raise awareness here.
Edit: the root incident I'm referring to is not Aixos but Trivy - a security scanner being used in many CI pipelines - which got compromised with an infostealer that harvested maintainer credentials and tokens of a bunch of open source libraries.
I know that it doesn't depend on Axios... my concern was more about all other dependencies and their transitive dependencies which may get infected sooner or later as well. Nobody knows yet how many credentials / CI token got harvested by these actors.
So to some degree people (like me) who keep building the projects on an almost daily basis are at higher risk now.
But as you confirmed: if transitive dependencies get poisoned, strict pinning won't help.
I primarily wanted to raise awareness here.
Edit: the root incident I'm referring to is not Aixos but Trivy - a security scanner being used in many CI pipelines - which got compromised with an infostealer that harvested maintainer credentials and tokens of a bunch of open source libraries.
<!-- github-comment-id:4165025798 -->
Yup, super reasonable to raise awareness. We're not doing meaningful package install in our very-thin CI/CD pipeline, so the risk there is pretty minimal. For people fetching and building, yes, there is risk with transitive deps, but the committed lockfile is our strongest mitigation we've got short of private mirrors etc.. I'm keeping an eye out for any IoCs impacting our used packages in the mean time.
Yup, super reasonable to raise awareness. We're not doing meaningful package install in our very-thin CI/CD pipeline, so the risk there is pretty minimal. For people fetching and building, yes, there is risk with transitive deps, but the committed lockfile is our strongest mitigation we've got short of private mirrors etc.. I'm keeping an eye out for any IoCs impacting our used packages in the mean time.
<!-- github-comment-id:4165193337 -->
I'm gonna close this now; I don't know that it's meaningfully useful for folks to keep it open. Feel free to reopen if you have specific points or concerns to raise :)
I'm gonna close this now; I don't know that it's meaningfully useful for folks to keep it open. Feel free to reopen if you have specific points or concerns to raise :)
<!-- github-comment-id:4185299493 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi! Not sure if you're aware of but there's a heavy supply chain attack going on since a couple of days affecting popular NPM and PyPi packages. Credentials and CI tokens from package maintainers have been harvested beforehand and now they're poisoning what they can with info stealers.
See for reference:
So to evade this, versions of all package dependencies have to be pinned exactly.
But still, this may not help with transient packages I'm afraid.
And I'm no expert on nodejs but to me it looks like pinning with ^ does open the door for poisoned patch versions, e.g. "^1.2.3" may result in v1.2.4 being pulled: https://github.com/jkingsman/Remote-Terminal-for-MeshCore/blob/main/frontend/package.json
Eyy good looking out.
The compromised Axios versions were pulled by the time I learned about this last night, but more pertinently, we don't depend on Axios whatsoever (directly or transitively).
I'm not going to freeze all dependency versions at this time since our
npm ciusage gives us reproducible builds with locked trees as defense against similar attacks going forward.Exact pinning in package.json doesn’t really eliminate transitive risk; it just shifts the risk into bigger, less frequent bangs rather than reducing overall exposure.
Happy to revisit if new information comes out, but at this point the risk from this incident is mitigated (and never really existed) for this project.
I know that it doesn't depend on Axios... my concern was more about all other dependencies and their transitive dependencies which may get infected sooner or later as well. Nobody knows yet how many credentials / CI token got harvested by these actors.
So to some degree people (like me) who keep building the projects on an almost daily basis are at higher risk now.
But as you confirmed: if transitive dependencies get poisoned, strict pinning won't help.
I primarily wanted to raise awareness here.
Edit: the root incident I'm referring to is not Aixos but Trivy - a security scanner being used in many CI pipelines - which got compromised with an infostealer that harvested maintainer credentials and tokens of a bunch of open source libraries.
Yup, super reasonable to raise awareness. We're not doing meaningful package install in our very-thin CI/CD pipeline, so the risk there is pretty minimal. For people fetching and building, yes, there is risk with transitive deps, but the committed lockfile is our strongest mitigation we've got short of private mirrors etc.. I'm keeping an eye out for any IoCs impacting our used packages in the mean time.
I'm gonna close this now; I don't know that it's meaningfully useful for folks to keep it open. Feel free to reopen if you have specific points or concerns to raise :)
Yeah, no problem - and meanwhile I learned about "npm audit" which gives me a little bit of relieve 🙃