Sâu Shai-Hulud tấn công npm ngày 4/8/2026: Phân tích toàn diện cuộc tấn công đầu độc hơn 1.280 gói phần mềm

Xâm nhập ban đầu: Tin tặc đã xâm nhập như thế nào?

Vào khoảng 09:00 UTC ngày 4/8/2026, một tin tặc đã kiểm soát tài khoản GitHub của Jared Wray (jaredwray) . Sử dụng quyền truy cập đó, chúng đã đẩy mã độc trực tiếp vào nhánh main của kho lưu trữ keyv và ngay lập tức phát hành các phiên bản mới trên toàn bộ họ gói keyv và cacheable .

Các gói khởi đầu bao gồm 11 gói trên cả hai không gian tên: keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache, file-entry-cache và các gói khác . Các nhà nghiên cứu bảo mật từ Aikido Security, StepSecurity (theo dõi sâu với tên gọi "ChainDrop"), Socket và Chainguard đều độc lập xác nhận sự xâm phạm trong vòng vài giờ đầu tiên .

Tải trọng độc hại: setup.mjs và Math_Symbol.js

Mọi gói bị đầu độc đều nhận cùng một mẫu lây nhiễm: hai tệp mới (setup.mjs và Math_Symbol.js) và một tệp package.json đã bị sửa đổi với mục "preinstall": "node setup.mjs" .

Khi bất kỳ nhà phát triển nào hoặc hệ thống CI chạy npm install, tệp setup.mjs dropper sẽ tự động thực thi trước khi quá trình cài đặt hoàn tất. Nhiệm vụ của nó là tải xuống một tệp nhị phân Bun JavaScript runtime hợp pháp từ GitHub Releases, sau đó khởi chạy tải trọng giai đoạn hai đã bị làm rối (Math_Symbol.js, khoảng 710–728 KB) .

Microsoft Threat Intelligence xác nhận rằng tải trọng này là một biến thể của Mini Shai-Hulud . Nó thu thập nhiều loại thông tin đăng nhập và bí mật từ các môi trường bị nhiễm :

• Token xác thực npm
• Token truy cập cá nhân GitHub (PATs)
• Khóa AWS
• Bí mật Kubernetes
• Token HashiCorp Vault
• Khóa Stripe
• Token Slack
• Khóa SSH
• Tệp trạng thái Terraform
• Thông tin xác thực Docker
• Cấu hình VPN

Tự nhân bản: Sâu đã lây lan khắp hệ sinh thái như thế nào?

Điều khiến cuộc tấn công này trở nên đặc biệt nguy hiểm là khả năng tự nhân bản của nó. Sau khi đánh cắp token xuất bản npm và GitHub PAT từ môi trường bị nhiễm, con sâu đã sử dụng quyền truy cập đó để xuất bản thêm các phiên bản độc hại của các gói khác thuộc sở hữu của những người bảo trì khác nhau, không liên quan .

Phạm vi xâm phạm đã mở rộng nhanh chóng:

• Trong vòng khoảng hai giờ, StepSecurity đã theo dõi 435 gói và 1.557 phiên bản bị đầu độc .
• Đến đầu giờ chiều theo giờ CEST, Aikido Security đã đếm được 868 gói bị xâm phạm trên 1.381 phiên bản .
• Vào cuối ngày, tổng số đã vượt quá 1.280+ gói và 1.680+ phiên bản, theo BleepingComputer và các hãng tin khác .

Con sâu đã vượt qua ranh giới không gian tên — nó không chỉ giới hạn trong họ keyv/cacheable nơi nó bắt đầu. Nó đã nhảy sang các gói thuộc sở hữu của các tổ chức bao gồm Deliveroo, Ornikar, OneReach, Picsart, Qlik và ServiceTitan, cùng nhiều tổ chức khác .

Rò rỉ dữ liệu: Dữ liệu bị đánh cắp đã đi về đâu?

Thông tin đăng nhập bị đánh cắp đã được chuyển đến một kho lưu trữ GitHub do tin tặc kiểm soát — con sâu đã tạo một kho lưu trữ mới hoặc sử dụng một kho lưu trữ chuyên dụng cho mục đích này . Nhiều kênh chuyển dữ liệu dự phòng đã được tích hợp vào tải trọng , giúp nó có khả năng chống lại việc vô hiệu hóa bất kỳ kênh đơn lẻ nào.

Khắc phục: Các nhà nghiên cứu bảo mật đã khuyến nghị gì?

Các nhà nghiên cứu bảo mật từ nhiều công ty đã thúc giục các nhóm coi bất kỳ hệ thống nào đã chạm vào gói bị ảnh hưởng là đã bị xâm phạm hoàn toàn. Các bước khắc phục sau đây đã được khuyến nghị một cách nhất quán :

1. Khóa hoặc Quay lại Phiên bản của Các gói Bị Ảnh hưởng Ngay lập tức

Sử dụng npm/yarn/pnpm overrides (ví dụ: "overrides" trong package.json) để ngăn chặn việc cài đặt lại vô tình các phiên bản bị đầu độc . Kiểm tra tệp lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) để tìm bất kỳ phiên bản gói nào bị ảnh hưởng, bao gồm cả các phụ thuộc gián tiếp .

2. Coi Các Máy chủ Bị Ảnh hưởng là Đã Bị Xâm phạm Hoàn toàn

Đừng chỉ đơn giản xóa các tệp độc hại khỏi máy đã chạy npm install trên một phiên bản bị ảnh hưởng . Giả định rằng tất cả các bí mật có trên máy chủ đó đã bị xâm phạm.

3. Thay mới Tất cả Thông tin Đăng nhập

Thu hồi và tạo lại tất cả thông tin đăng nhập có khả năng bị lộ :

• Token npm (cổ điển và chi tiết)
• Token truy cập cá nhân GitHub (PATs) và token chi tiết
• Khóa AWS IAM và khóa truy cập
• Token tài khoản dịch vụ Kubernetes
• Token HashiCorp Vault
• Khóa Stripe
• Token Slack
• Khóa SSH
• Thông tin xác thực Docker
• Token VPN

4. Xóa Trình theo dõi Thu hồi Token Trước Khi Thay mới

Một chi tiết quan trọng: phần mềm độc hại đôi khi thiết lập các trình theo dõi quy trình làm việc GitHub có thể làm lộ token mới ngay khi nó được tạo . Các nhà nghiên cứu khuyên nên vô hiệu hóa hoặc xóa mọi dịch vụ giám sát trước khi thay mới thông tin đăng nhập .

5. Xóa Bộ nhớ đệm và Xây dựng lại từ Đầu

Xóa bộ nhớ đệm npm/pnpm/yarn và bộ nhớ đệm Docker build trên cả máy của nhà phát triển và trình chạy CI/CD . Xây dựng lại tất cả các tạo tác từ đầu để ngăn chặn các phụ thuộc bị nhiễm độc tồn tại trong bộ nhớ đệm hoặc các lớp Docker .

6. Kiểm tra Môi trường GitHub và CI/CD

Tìm kiếm các kho lưu trữ mới được tạo hoặc các quy trình làm việc trái phép . Tìm kiếm các tạo tác tồn tại như .claude/settings.json hoặc .vscode/tasks.json mà con sâu có thể đã tạo .

Kết luận chính

Cuộc tấn công sâu Shai-Hulud ngày 4/8/2026 là một bước ngoặt đối với bảo mật hệ sinh thái JavaScript. Nó đã chứng minh rằng một tài khoản người bảo trì bị xâm phạm duy nhất — thậm chí không có quyền truy cập trực tiếp vào hầu hết các gói bị ảnh hưởng — có thể dẫn đến một con sâu đầu độc hơn một nghìn gói trong vòng vài giờ. Việc sử dụng tệp nhị phân Bun runtime hợp pháp để thực thi tải trọng, khả năng tự nhân bản thông qua token bị đánh cắp và các kênh chuyển dữ liệu dự phòng đã khiến nó trở nên tinh vi hơn các cuộc tấn công chuỗi cung ứng trước đây .

Đối với các nhóm kỹ thuật và bảo mật, sự cố này nhấn mạnh tầm quan trọng của việc khóa các phụ thuộc, vô hiệu hóa các tập lệnh pre/post-install nếu có thể, giám sát hoạt động GitHub bất thường và duy trì các sổ tay hướng dẫn ứng phó sự cố cho các vụ xâm phạm chuỗi cung ứng.