跟读练习: BIGGEST npm Hack of 2026 Just Happened?! - 通过YouTube学习英语口语

困难

跟读控制

0% 已完成 (0/92 句)

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

⏸ 已暂停

速度:

重复次数:

等待模式:

字幕同步:0ms

所有句子

92 句

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

0:00.04 – 0:07.14 (7.1s)

It's really bad.

0:07.14 – 0:07.92 (0.8s)

Axios is a package which has 100 million weekly downloads.

0:07.92 – 0:12.34 (4.4s)

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

0:12.34 – 0:17.28 (4.9s)

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

0:17.28 – 0:23.40 (6.1s)

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

0:23.40 – 0:26.70 (3.3s)

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.

0:26.96 – 1:13.56 (46.6s)

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.

1:13.56 – 1:22.70 (9.1s)

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.

1:22.70 – 1:31.90 (9.2s)

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

1:32.14 – 1:37.96 (5.8s)

Let's run some math.

1:37.96 – 1:39.10 (1.1s)

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?

1:39.10 – 1:53.78 (14.7s)

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

1:53.78 – 1:58.62 (4.8s)

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?

1:58.62 – 2:10.74 (12.1s)

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.

2:10.74 – 2:24.16 (13.4s)

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.

2:24.22 – 2:32.78 (8.6s)

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

2:33.20 – 2:37.58 (4.4s)

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

2:37.52 – 2:43.70 (6.2s)

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

2:43.70 – 2:49.26 (5.6s)

So it was very clean.

2:48.68 – 2:50.42 (1.7s)

There was no hacking as such involved.

2:50.42 – 2:52.98 (2.6s)

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

2:52.98 – 2:57.02 (4.0s)

There was a legit package publishing that happened.

2:57.02 – 2:59.52 (2.5s)

The attacker did not modify any Axios source files directly.

2:59.52 – 3:02.84 (3.3s)

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

3:02.84 – 3:09.74 (6.9s)

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

3:09.74 – 3:13.68 (3.9s)

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

3:13.68 – 3:19.96 (6.3s)

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

3:19.96 – 3:23.48 (3.5s)

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

3:23.48 – 3:27.10 (3.6s)

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

3:27.10 – 3:34.60 (7.5s)

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

3:34.94 – 3:43.80 (8.9s)

So it's just lightly obfuscated, right?

3:44.00 – 3:46.54 (2.5s)

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?

3:46.36 – 3:54.98 (8.6s)

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

3:54.46 – 4:00.76 (6.3s)

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

4:00.66 – 4:04.80 (4.1s)

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.

4:05.08 – 4:14.66 (9.6s)

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.

4:14.80 – 4:24.38 (9.6s)

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

4:24.44 – 4:29.84 (5.4s)

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.

4:29.82 – 4:40.50 (10.7s)

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

4:40.80 – 4:44.78 (4.0s)

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.

4:44.30 – 4:51.64 (7.3s)

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.

4:51.84 – 5:01.40 (9.6s)

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.

5:01.40 – 5:12.46 (11.1s)

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?

5:12.46 – 5:25.92 (13.5s)

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?

5:25.92 – 5:34.70 (8.8s)

At least that's the hope.

5:34.70 – 5:35.96 (1.3s)

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?

5:35.96 – 5:44.88 (8.9s)

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.

5:44.88 – 5:52.20 (7.3s)

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

5:52.20 – 5:55.16 (3.0s)

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

5:55.16 – 6:00.06 (4.9s)

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

6:00.06 – 6:04.40 (4.3s)

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

6:04.40 – 6:10.54 (6.1s)

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?

6:10.54 – 6:25.18 (14.6s)

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

6:25.18 – 6:30.22 (5.0s)

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.

6:30.22 – 6:38.14 (7.9s)

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

6:38.14 – 6:41.32 (3.2s)

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

6:41.32 – 6:47.94 (6.6s)

It's just super bad, right?

6:47.94 – 6:49.14 (1.2s)

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

6:49.14 – 6:53.38 (4.2s)

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?

6:53.38 – 7:01.94 (8.6s)

This is like a big one.

7:01.94 – 7:02.90 (1.0s)

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?

7:02.90 – 7:33.18 (30.3s)

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

7:33.18 – 7:38.48 (5.3s)

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.

7:38.48 – 7:49.04 (10.6s)

Second of all is that lock files.

7:49.04 – 7:51.74 (2.7s)

Please, please learn about them.

7:51.74 – 7:53.32 (1.6s)

This is so important.

7:53.32 – 7:54.44 (1.1s)

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

7:54.44 – 7:57.54 (3.1s)

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

7:57.54 – 8:00.70 (3.2s)

On August 5th.

8:00.70 – 8:01.60 (0.9s)

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

8:01.60 – 8:06.40 (4.8s)

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

8:06.40 – 8:11.56 (5.2s)

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.

8:11.56 – 8:17.48 (5.9s)

And you know, the kind of responses I got.

8:17.48 – 8:19.40 (1.9s)

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

8:19.40 – 8:23.52 (4.1s)

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

8:23.52 – 8:25.96 (2.4s)

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

8:26.02 – 8:30.94 (4.9s)

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.

8:30.94 – 8:40.36 (9.4s)

They don't know about what version locking is.

8:40.36 – 8:42.76 (2.4s)

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.

8:42.76 – 9:17.68 (34.9s)

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

9:17.68 – 9:22.60 (4.9s)

It has just one dependency.

9:22.48 – 9:23.82 (1.3s)

It's small enough.

9:23.82 – 9:24.86 (1.0s)

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

9:24.86 – 9:27.82 (3.0s)

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

9:27.82 – 9:34.32 (6.5s)

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

9:34.32 – 9:37.72 (3.4s)

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.

9:37.72 – 10:14.28 (36.6s)

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

10:14.30 – 10:15.82 (1.5s)

Hopefully you liked it.

10:15.82 – 10:16.70 (0.9s)

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.

10:16.70 – 10:22.00 (5.3s)

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

10:22.08 – 10:24.18 (2.1s)

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.

10:24.18 – 10:29.76 (5.6s)

什么是跟读法？

跟读法 (Shadowing) 是一种有科学依据的语言学习技巧，最初开发用于专业口译员的培训，并由多语言者Alexander Arguelles博士普及。这个方法简单而强大：您在听英语母语原声的同时立即大声重复——就像是一个延迟1-2秒紧跟说话者的影子。与被动听力或语法练习不同，跟读法强迫您的大脑和口腔肌肉同时处理并模仿真实的讲话模式。研究表明它能显着提高发音准确性，语调，节奏，连读，听力理解和口语流利度——使其成为雅思口语备考和真实英语交流最有效的方法之一。

如何在ShadowingEnglish上有效练习

选择您的视频： 挑选一段语音清晰、自然的YouTube视频。TED演讲，BBC新闻，电影片段，播客或雅思口语范例都很好。将URL粘贴到搜索栏中。从较短的视频（短于5分钟）以及您真正感兴趣的内容开始——兴趣是最重要的导师。
先听，理解上下文： 第一次听的时候，将速度保持在1倍速并仅仅倾听。还不要尝试重复。专注于理解其含义，收集新词汇，并注意讲话人如何强调单词，连读声音及使用停顿。
设置跟读模式：
- 等待模式：选择 +3s 或 +5s ——在每句话播放完毕后，视频会自动暂停以便您有时间大声重复它。如果您想完全控制并在每次重复后由您自己点击下一步，请选择 手动。
- 字幕同步：YouTube字幕有时会在音频前或后略微出现。使用 ±100ms 使它们完美对齐以助您准确跟读。
大声跟读（核心练习）： 这是真正发生改变的一步。当一个句子播放出来立刻——或在暂停期间——大声、清晰且自信地重复出来。千万不要只是张张嘴：要模仿说话者的准确节奏、重音、音高和连读。力求听上去就像说话者的影子，而不仅是逐字背诵。使用重复功能多次练习同一个句子，直到感觉自然为止。
提高难度： 当练习段落变得相对舒适后，就去挑战自我。将速度增加至 <code>1.25x</code> 或甚至 <code>1.5x</code> 以训练高速语言反射。或者将等待模式调整为 <code>关闭</code> 以进行连续跟读——这是最进阶同样收益最大的模式。持续的每日15–30分钟的练习将可以在几周内产生可见的效果。

☕ 请我们喝杯咖啡

由于您的支持，ShadowingEnglish 保持完全免费。服务器和 AI 费用高昂——您的咖啡将帮助我们继续前行！🙏

通过 PayPal 捐赠

ShadowingEnglish.com – 英语跟读练习

使用跟读技巧流利地说英语。听正宗的YouTube视频，逐句跟读，建立真实的发音和流利度——全球雅思学习者都在使用。

跟读练习: BIGGEST npm Hack of 2026 Just Happened?! - 通过YouTube学习英语口语

本课概述

关键词汇与短语

练习建议

什么是跟读法？

如何在ShadowingEnglish上有效练习