Pratique du Shadowing: BIGGEST npm Hack of 2026 Just Happened?! - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Chaque mode ouvre une salle d'entraînement en plein écran.

92 phrases

Si les phrases sont trop courtes ou trop longues, cliquez sur Edit pour les ajuster.

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.

Télécharger l'application

Tout pour parler couramment

Prononciation IAChaque phrase notée

Phonétique (IPA)Maîtrisez chaque son

VocabulaireEnrichissez votre lexique

Jeu de vocabulaireApprenez en jouant

Scanner le QR

Download on theApp Store Get it onGoogle Play

Même chaîne

JUST $1 For Billions of Tokens?! (DeepSeek v4 Pro)

Daily ConversationUniversity StudentsWorking Adults

FOR YOU

Vidéo recommandée

47 phrases

Vocabulaire et conseils d’expression pour cette leçon

Cette leçon d’expression orale de niveau C2 s’appuie sur la vidéo « BIGGEST npm Hack of 2026 Just Happened?! ». Les mots qui reviennent le plus souvent : package, axios, file, code, download. Cette vidéo contient 92 phrases et 2194 mots à répéter en shadowing. La partie parlée dure 10:30. Le locuteur parle vite, environ 209 mots par minute : attendez-vous à des liaisons et à des sons réduits. Seuls 81 % des mots font partie des 3 000 mots les plus courants en anglais, le vocabulaire est donc exigeant. 19 de ses 92 phrases sont des questions : un bon entraînement pour l’intonation interrogative et les réponses courtes.

Vocabulaire clé de cette vidéo

Les 15 mots les plus avancés de la vidéo, avec leur prononciation et leur sens :

Mot	Prononciation	Sens
malicious adjectif	/məˈlɪʃəs/	malveillant, mauvais
obfuscate verbe	/ˈɑbfəskeɪt/	obscurcir
transitive adjectif	/ˈtɹænzɪtɪv/	transitif
credential nom	/kɹɪˈdɛnʃəl/	accréditation
malware nom	/ˈmæl.wɛəɹ/	maliciel, logiciel malveillant
payload nom	/ˈpeɪloʊd/	fret, charge utile
reuse nom	/ɹiːˈjuːs/	réemploi, réusage
fetch verbe	/fɛt͡ʃ/	ramener, rapporter
erase verbe	/ɪˈɹeɪs/	effacer
arbitrary adjectif	/ˈɑː.bɪ.tɹə.ɹi/	arbitraire
execute verbe	/ˈɛksɪˌkjuːt/	exécuter, mettre à mort
evaluate verbe	/ɪˈvaljʊeɪt/	évaluer
static adjectif	/ˈstæt.ɪk/	statique
automate verbe	/ˈɔ.təˌmeɪt/	automatiser
boggle verbe	/ˈbɒɡ.əl/	être époustouflé, être confus

Les verbes à particule que vous entendrez

Mot	Sens
figure out verbe	cerner
take out verbe	supprimer, sortir

La grammaire de cette vidéo

Les structures que le locuteur utilise le plus, avec les mots exacts de la vidéo :

Structure	Dans la vidéo
Voix passive be + participe passé — l’accent est mis sur ce qui arrive, pas sur qui le fait	has been compromised · were removed · is now compromised
Present perfect have/has + participe passé — une action passée qui compte encore maintenant	has been compromised · has been hacked · have not written
Propositions relatives who / which + proposition — une précision sur une personne ou une chose	Axios, which is · package which has · March, which is

Prononciation à surveiller

Le locuteur utilise 23 contractions et formes réduites, comme don't, you're, gonna. Prononcez-les sous leur forme courte, telles que vous les entendez.

Les sons « sh » et « zh »: malicious /məˈlɪʃəs/, credential /kɹɪˈdɛnʃəl/, obfuscation /ˌɑb.fəˈskeɪ.ʃən/, substitution /ˌsʌb.stɪˈtʃuː.ʃən/
Mots longs — placez bien l’accent: dependency /dɪˈpɛndənsi/, arbitrary /ˈɑː.bɪ.tɹə.ɹi/, obfuscation /ˌɑb.fəˈskeɪ.ʃən/, substitution /ˌsʌb.stɪˈtʃuː.ʃən/, vulnerability /ˌvʌln(ə)ɹəˈbɪlɪti/

Les sons difficiles pour les francophones :

/tʃ/ et /dʒ/ — à ne pas adoucir en « ch » et « j »: fetch /fɛt͡ʃ/, substitution /ˌsʌb.stɪˈtʃuː.ʃən/, legit /lɪˈd͡ʒɪt/
/r/ anglais — langue recourbée, sans frotter la gorge: transitive /ˈtɹænzɪtɪv/, credential /kɹɪˈdɛnʃəl/, malware /ˈmæl.wɛəɹ/, reuse /ɹiːˈjuːs/, crypto /ˈkɹɪptoʊ/

Comment s’entraîner avec cette vidéo

Écoutez la vidéo en entier une fois sans parler et notez les mots que vous ne connaissez pas.
Commencez à la vitesse 0,75×, répétez phrase par phrase, puis revenez à la vitesse normale quand cela devient facile.
Enregistrez-vous et comparez avec l’original, en faisant attention à des mots comme malicious, obfuscate, transitive.

Qu'est-ce que la technique du Shadowing ?

Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.

Technique du shadowing : lire le guide complet étape par étape →

Pratique du Shadowing: BIGGEST npm Hack of 2026 Just Happened?! - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Télécharger l'application

JUST $1 For Billions of Tokens?! (DeepSeek v4 Pro)

The most interesting "hack" in history...

2.2k

Angular in 100 Seconds

If I Started a SaaS in 2026, I’d Do This (0 to 1,000+ Users)

Github are you joking?

JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue

MCP Just Got a Whole Lot Better

How Does a URL Shortener Work?

mattpocock/skills: A complete AI Coding workflow, end-to-end

STOP Running Code On Your Computer

Build a Real-Time Leaderboard on AWS with DynamoDB

"Well, it's Flight 13 Launch Week... Again" | SpaceX Starbase