Luyện nói tiếng Anh bằng Shadowing qua video: BIGGEST npm Hack of 2026 Just Happened?!

Khó

Bảng Điều Khiển Shadowing

0% Hoàn thành (0/92 câu)

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

⏸ Tạm dừng

Tốc độ:

Số lần lặp lại:

Chờ (Wait Mode):

Chỉnh Sub:0ms

Tất cả các câu

92 câu

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)

Phương Pháp Shadowing Là Gì?

Shadowing là kỹ thuật học ngôn ngữ có cơ sở khoa học, ban đầu được phát triển cho chương trình đào tạo phiên dịch viên chuyên nghiệp và được phổ biến rộng rãi bởi nhà đa ngôn ngữ học Dr. Alexander Arguelles. Nguyên lý cốt lõi đơn giản nhưng cực kỳ hiệu quả: bạn nghe tiếng Anh của người bản xứ và lặp lại to ngay lập tức — như một "cái bóng" (shadow) đuổi theo người nói với độ trễ chỉ 1–2 giây. Khác với luyện ngữ pháp hay học từ vựng bị động, Shadowing buộc não bộ và cơ miệng phải đồng thời xử lý và tái tạo ngôn ngữ thực tế. Các nghiên cứu khoa học xác nhận phương pháp này cải thiện đáng kể phát âm, ngữ điệu, nhịp điệu, nối âm, kỹ năng nghe và độ lưu loát khi nói — đặc biệt hiệu quả cho người luyện IELTS Speaking và muốn giao tiếp tiếng Anh tự nhiên như người bản ngữ.

Cách Luyện Shadowing Hiệu Quả Trên ShadowingEnglish

Chọn video phù hợp: Tìm video YouTube có tiếng Anh tự nhiên, rõ ràng. TED Talks, bản tin BBC, cảnh phim, podcast, hay video mẫu IELTS Speaking đều rất tốt. Dán URL vào thanh tìm kiếm. Bắt đầu với video ngắn (dưới 5 phút) và chủ đề bạn thực sự yêu thích — vì đam mê sẽ giúp bạn kiên trì hơn.
Nghe trước, hiểu ngữ cảnh: Lượt đầu tiên hãy để tốc độ 1x và chỉ nghe, chưa cần đọc theo. Tập trung hiểu ý nghĩa, chú ý cách người nói nhấn âm, nối âm, ngắt nghỉ và xử lý từ mới. Việc hiểu ngữ cảnh trước sẽ giúp bài luyện Shadowing hiệu quả hơn nhiều.
Cài đặt chế độ luyện Shadowing:
- Wait Mode (Tính năng chờ): Chọn +3s hoặc +5s — sau mỗi câu video sẽ tự động tạm dừng để bạn có thời gian lặp lại to. Chọn Manual nếu muốn kiểm soát hoàn toàn và tự nhấn Next sau mỗi lần lặp.
- Sub Sync (Chỉnh độ lệch phụ đề): Phụ đề YouTube đôi khi lệch so với âm thanh. Dùng ±100ms để căn chỉnh hoàn hảo, giúp bạn đọc theo đúng lúc.
Thực hành Shadowing (phần quan trọng nhất): Đây là nơi phép màu xảy ra. Ngay khi câu vang lên — hoặc trong khoảng ngừng — hãy đọc to, rõ ràng và tự tin. Đừng chỉ đọc từ: hãy bắt chước nhịp điệu, trọng âm, cao độ và cách nối âm của người bản xứ. Mục tiêu là nghe giống như "cái bóng" của họ, không phải đọc chậm từng chữ. Dùng tính năng Repeat để luyện lại cùng câu nhiều lần cho đến khi cảm thấy tự nhiên.
Tăng độ khó và duy trì đều đặn: Khi đã quen với một đoạn, hãy đẩy thách thức cao hơn. Tăng tốc độ lên <code>1.25x</code> hoặc <code>1.5x</code> để rèn phản xạ ngôn ngữ nhanh. Hoặc chỉnh Wait Mode thành <code>Off</code> để luyện Shadowing liên tục — chế độ thách thức nhất và hiệu quả nhất. Kiên trì 15–30 phút mỗi ngày và bạn sẽ thấy sự thay đổi rõ rệt chỉ sau vài tuần.

☕ Mời chúng tôi một ly cà phê

ShadowingEnglish duy trì miễn phí 100% nhờ sự ủng hộ của các bạn. Chi phí máy chủ và AI rất lớn — một ly cà phê của bạn sẽ tiếp thêm động lực cho chúng tôi! 🙏

Techcombank · MAC TRAN TUNG19036284394017

ShadowingEnglish.com – Luyện Nói Tiếng Anh Bằng Shadowing

Nói tiếng Anh lưu loát với phương pháp Shadowing — nghe người bản xứ, đọc theo từng câu, rèn phản xạ ngôn ngữ thật sự. Được hàng ngàn người học IELTS tin dùng.

Luyện nói tiếng Anh bằng Shadowing qua video: BIGGEST npm Hack of 2026 Just Happened?!

Tại sao nên luyện nghe nói qua video này?

Ngữ pháp & Cách diễn đạt trong bối cảnh

Các bẫy phát âm thường gặp

Phương Pháp Shadowing Là Gì?

Cách Luyện Shadowing Hiệu Quả Trên ShadowingEnglish