Практика Shadowing: BIGGEST npm Hack of 2026 Just Happened?! - Изучайте разговорный английский с YouTube

Axios, which is one of the most popular packages out there to make HTTP requests in JavaScript, has been compromised and it's bad.

⏸ Пауза

Скорость:

92 предложений

Если предложения слишком короткие или длинные, нажмите Edit, чтобы их изменить.

Axios, which is one of the most popular packages out there to make HTTP requests in JavaScript, has been compromised and it's bad.

It's really bad.

Axios is a package which has 100 million weekly downloads.

That's a mind-boggling number and as you can see, it's only increasing as time is going by, right?

For those of you who don't know what Axios is, it's basically a promised-based HTTP client for browser and Node.js.

Fancy way of saying that it allows you to make HTTP requests.

Now back in the day when there was no native fetch available inside node.js or inside browsers it was very cumbersome to write the full syntax of making an HTTP request and that is where we used to use these tools like Axios like jQuery jQuery also has a decent way of making these HTTP requests right if I remember right nowadays it's much more common to just use fetch but a lot of code bases are stuck in the past right a lot of code bases have this as a dependency and this has been hacked On 31st of March, which is basically today, two malicious versions of Axios, the enormously popular JavaScript HTTP client with over 300 million weekly downloads, okay, it shows 100 million here, so I'm not sure which one is the right figure, but anyway, were briefly published to NPM via a compromised maintainer account.

Packages contained a hidden dependency that deployed a cross-platform remote access Trojan to any machine that ran NPM install, or equivalent in other package managers like Bunn.

The malicious versions were 1.14.1, and 0.30.4 were removed from NPM by this time, but they were still live for a couple of hours.

And for a package that is getting 100 million weekly downloads, that's going to be a big enough number, right?

Let's run some math.

So if a package is getting 100 million downloads every week, and we have about 168 hours in one week, so we are doing roughly about 0.59 million or about 600k downloads averaged out every hour, right?

And if it is up for a couple of hours, that's about 1.2 million malicious downloads, right?

And of course, like this is all CI numbers and here and there, but even if we assume like 10% unique computers, that compromises roughly around 120,000 unique computers across the world, right?

And even if you consider just 10% of these computers to be like actual users, not like automated CI systems and a formal compute, even then you are at 12,000 Unique Systems Compromised, which is a massive number.

In just a couple of hours, because the package is so much popular, we have at least like 10,000 to 12,000 people whose real computer is now compromised.

This is not a case of type of squatted package or a rogue dependency slipping into a build.

the attacker had direct publishing access to the official Axios package, likely by compromising a maintainer's account.

So somebody named Jason, his account was hacked and somebody literally published a new version release.

So it was very clean.

There was no hacking as such involved.

Like the package itself was not hacked, its transitive dependencies were not hacked.

There was a legit package publishing that happened.

The attacker did not modify any Axios source files directly.

Instead, they added a pre-staged malicious dependency, which is this plain crypto.js package to package JSON in the new Axios release.

The plain crypto.js package itself was purpose built for this attack.

So all the hacking stuff and, you know, whatever malicious thing was there that was inside this package, not in the core Axios package.

But because this is a dependency of the package, you will automatically pull that.

The double obfuscated and self-erasing malicious payload, right?

So what they're saying is that the setup.js post-installer dropper uses two layers of obfuscation to avoid static analysis.

Reverse base64 encoded with padding character substitution and XOR cipher with key this order underscore 7077 at a constant value of 333.

So it's just lightly obfuscated, right?

So again, like a lot of these security tools and whatever, what they do is that, you know, they'll just look at a piece of code and they'll try to figure out if this is malicious or not, right?

That is what static analysis in this context means that you are analyzing something without actually executing it.

And to bypass that, the attacker just obfuscated the code a little bit.

Once de-obfuscated, the script detects the host operating system and reaches out to the C2 server at sfrclack.com to download a second stage payload appropriate for the platform.

After execution, the malware erases its own tracks, it deletes setup, it removes package.json that contained the post-install hook and replaces it with a clean package.md renamed to package.json.

If you inspect this package, after the fact, you would find no obvious signs of post-install script ever being there.

So once it does all of this, this is what happens, at least on macOS, it downloads an Apple script, generates some unique ID, victim ID, fingerprints the system, beacons to the C2 every 60 seconds.

And then, you know, basically it's a remote code execution on your computer, right?

You can run script, you can run directories, you can kill the process as well, but you have got like a RCE vulnerability on the system.

Similarly on Windows, on Linux, a Python rat is downloaded and launched as an orphan background process and basically you're able to compromise the whole system, the system on which it's working.

See now this is a big big big issue right and the reason this is a big issue is because no matter what you look at, for example if you look at CI systems or if you look at personal computers, both are bad.

In case of CI if you have you know a Trojan or something installed, what happens in a lot of use cases is that companies, especially the ones that are using their own CI environments, a lot of times they reuse the environments, right?

Because technically speaking, CI system is supposed to be a secure execution environment because you are not executing any arbitrary code which you have not written, right?

At least that's the hope.

But if you are a bad developer, if you are somebody who does not pin their dependencies or you do not use lock files the way they are meant to be used, right?

If you are very casual on just removing the lock file, running an empty npm install or bun install or pnpm install again, you are a bad developer.

And that is why that is the reason why lock files existed.

These sort of attacks have minimum impact is one of the strong reasons why lock files existed.

And if you do not honor lock files regularly, this is something that would take you down, right?

So CI systems, if they're reusing the environment, it's possible that the Trojan or the malware, whatever it is, it's there.

And in the next build, even if your current build is not as sensitive, if the next build happens, and if you're not doing the cleanup properly, possible that that Trojan can take out your secrets or whatever is there, which you have given to your CI, which most of the companies actually do, right?

When you're running a CI on production, that's like a very, very secure deployment or something that's happening.

A lot of times your environment variables, you know, a bunch of production credentials are also part of CI, which is gonna be extremely risky if this happens.

Similarly, on personal computers, I don't think I have to explain this one.

Obviously, your personal data, you know, any sort of photos that you have, any sort of credentials that you have stored, could be anything.

It's just super bad, right?

Somebody has remote code execution on your system, they can run arbitrary code, it's gonna be bad.

So the way, the only way that you can not be part of these hacks is, first of all, just do not randomly update your packages, right?

This is like a big one.

I don't know, like for some reason a lot of people just like to be at the latest thing you don't need that until and unless there is not a security issue or there is not some feature that you don't want feature that you want or a bug that you don't want there is no real reason to update the code right it's fine you will get some performance benefits and all of that but you can wait you don't have to stay on the bleeding edge right at least wait for seven to ten days for the community to catch up because again like you know this attack on axios this was caught within like couple of hours three hours maximum, right?

So you can give like seven days, 10 days of time to the community to figure out whatever is there.

This obviously does not guarantee there could be like a smart backdoor or a vector that is there for seven days, eight days, 10 days more, but it gives you at least the ability to, you know, be protected from these things.

Second of all is that lock files.

Please, please learn about them.

This is so important.

This is something, you know, it's super controversial for some reason.

So this has made me remember this tweet that I did last year, right?

On August 5th.

I have done 30, 40 JavaScript interview calls in the past few weeks and I start with basic questions.

And this is when you use a package manager like npm, it creates a file package log.json.

If I open my package.json and remove all the caret symbols, you know, whatever, like the question was, but it was around package.json and log files.

And you know, the kind of responses I got.

Asking questions about whatever he has written is a terrible way to evaluate a candidate.

Curious to know what you were trying to evaluate with this question.

I have almost two decades of JS experience and would totally not want to work for you if this is the question.

These are the people in your company that will get your product hacked because they will have a very nice solution that if npm install is broken, let's just remove lock file, install it, call it a day.

They don't know about what version locking is.

They would have no knowledge about you know what the carrot symbol is what tilde symbol is over here or you know what exact version means and these are the people that you work with every single day right that is why it's super important for you to be upskilled be security aware even if you are a front-end or a back-end developer not just like a full stack or devops or you know security guy you still should know about these security things that i talk about so yeah it's pretty bad it's all safe right now you know and again like axios there are some better packages from compared to axios the one that I personally use is this Xior, which is like a built-in replacement for Axios.

It does not have a lot of impressive, like it does not have 100 million downloads, but this is good enough, right?

It has just one dependency.

It's small enough.

It's 10 times smaller than Axios and it does most of the things that you want.

So if you're using Axios, you can basically replace Axios with Xior and all of your code would still work fine.

Unless and until and unless you're doing some magic work with, you know, Axios.

Axios, on the other hand, has 25 dependencies, you know, total, which again is not really cool because again like if something bad happens to one of those transitive dependencies then you are also screwed and the same thing applies in Axios case also right so even if you are not using Axios it's possible that there is some transitive dependency that is using Axios and that would screw you even if you are not the one doing that right and that is where lock files really really become important because if you are locking the version of not only just your packages but actually all the way transitively down to every single package it's impossible for you to get hacked in this situation until and unless obviously you're not updating it on your own.

So yeah, that's pretty much it for this video.

Hopefully you liked it.

If you did, make sure you leave a like and subscribe to the channel and I'm going to see you in the next video very soon.

If you're still watching, make sure you leave a comment.

I watched till the end below to tell me that you were still here and let me know what do you think about the video.

TRENDING

Что такое техника Shadowing?

Shadowing — это научно обоснованная техника изучения языка, изначально разработанная для подготовки профессиональных переводчиков и популяризированная полиглотом доктором Александром Аргуэльесом. Метод прост, но эффективен: вы слушаете аудио на английском от носителей языка и немедленно повторяете вслух — как тень, следующая за говорящим с задержкой в 1–2 секунды. В отличие от пассивного прослушивания или грамматических упражнений, Shadowing заставляет мозг и мышцы рта одновременно обрабатывать и воспроизводить реальные речевые паттерны. Исследования показывают, что это значительно улучшает точность произношения, интонацию, ритм, связную речь, понимание на слух и беглость речи — что делает его одним из самых эффективных методов для подготовки к IELTS Speaking и реального общения на английском.

☕ Угостите нас кофе

ShadowingEnglish остаётся 100% бесплатным благодаря вашей поддержке. Стоимость серверов и ИИ высока — ваш кофе поддерживает нас! 🙏

Пожертвовать через PayPal

ShadowingEnglish.com – Практика Shadowing английского

Практика Shadowing: BIGGEST npm Hack of 2026 Just Happened?! - Изучайте разговорный английский с YouTube

Популярные

Об этом уроке

Ключевая лексика и фразы

Советы по практике

Что такое техника Shadowing?

Практика Shadowing: BIGGEST npm Hack of 2026 Just Happened?! - Изучайте разговорный английский с YouTube

Скачать приложение

Об этом уроке

Ключевая лексика и фразы

Советы по практике

Что такое техника Shadowing?