This may not be popular, but is there a place for required human actions or just timed actions to slow down things like this? For instance, maybe a GH action to deploy requires a final human click and to change that to cli has a 3 day cooling period with mandatory security emails sent out. Similarly, you switch to read only for 6 hrs after an email change. There are holes in these ideas but the basic concept is to tr…
Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated. A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.
Axios compromised on NPM – Malicious versions drop remote access trojan
71–80 of 894 posts
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#72Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#73Earlier quoted context omitted.
Apparently it's possible to create access tokens that bypass 2FA. Might've been this. https://docs.npmjs.com/creating-and-viewing-access-tokens
Correct, for CI/CD systems that want to push releases.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#74PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…
If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.
7 days gives ample time for security scanning, too.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#75How much do you want to bet me that the credential was stolen during the previous LiteLLM incident? At what point are we going to have to stop using these package managers because it's not secure? I've got to admit, it's got me nervous to use Python or Node.js these days, but it's really a universal problem.
> it’s got me nervous to use Python or Node.js these days My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment. I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.
(Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#76Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#77I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only pu…
> Good news for pnpm/bun users who have to manually approve postinstall scripts. Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#78You should probably set your default to not run those scripts. They are mostly unnecessary.
~/.npmrc :
ignore-scripts=true
83M weekly downloads!Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#79I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only pu…
> Good news for pnpm/bun users who have to manually approve postinstall scripts. Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?
It's also a little context dependent, for example if I was using Axios and I see a prompt to run the plain-crypto-js postinstall script, alarm bells would instantly ring, which would at least make me look up the changelog to see why this is happening.
In most cases I don't even let them run unless something breaks/doesn't work as expected.