Mini Shai‑Hulud: Khi hơn 600 gói npm độc hại được tung ra trong vài phút

Theo các báo cáo nghiên cứu bảo mật, trong giai đoạn từ 10–12/05/2026, chiến dịch này đã:

• Xâm phạm hơn 170 package trên npm và PyPI thuộc 19 namespace khác nhau
• Phát hành hơn 400 phiên bản độc hại
• Nhắm vào các thư viện có lượng tải xuống rất lớn

Những dự án bị ảnh hưởng bao gồm các package liên quan đến TanStack, Mistral AI, UiPath, OpenSearch và Guardrails AI—đây đều là các thành phần phần mềm có hàng triệu lượt tải và được sử dụng làm dependency trong nhiều dự án khác.

Tổng cộng, các package bị xâm phạm có hơn 518 triệu lượt tải trong lịch sử, nghĩa là chỉ cần một bản cập nhật độc hại cũng có thể lan rộng trong hệ sinh thái phần mềm.

Một đợt tấn công sau đó tập trung vào hệ sinh thái AntV, bộ thư viện trực quan hóa dữ liệu cho JavaScript có khoảng 16 triệu lượt tải mỗi tuần.

Vì sao hacker có thể phát hành hơn 600 phiên bản trong vài phút?

Tốc độ phát tán cực nhanh của đợt tấn công ngày 19/05 đến từ việc lợi dụng hệ thống tự động hóa và quyền maintainer.

Theo các báo cáo, kẻ tấn công đã chiếm quyền tài khoản maintainer của package atool. Từ đó, chúng có thể phát hành phiên bản mới cho hàng loạt package trong cùng hệ sinh thái.

Trong npm, maintainer thường sử dụng script hoặc pipeline CI để phát hành package tự động. Khi tài khoản này bị chiếm quyền, kẻ tấn công có thể:

• Phát hành phiên bản mới cho hàng trăm package
• Tăng số version liên tục
• Chạy nhiều quá trình publish song song

Nhờ vậy, chỉ trong vài phút, hệ thống npm đã nhận hàng trăm bản phát hành độc hại thay vì phải tấn công từng package riêng lẻ.

Lợi dụng GitHub Actions và OIDC để phát hành "hợp lệ"

Một điểm đáng chú ý của Mini Shai‑Hulud là cách nó phá vỡ các cơ chế bảo mật hiện đại trong quy trình phát hành phần mềm.

Nhiều dự án hiện sử dụng GitHub Actions Trusted Publishing, trong đó pipeline CI lấy token danh tính tạm thời thông qua OpenID Connect (OIDC) để phát hành package mà không cần lưu trữ mật khẩu lâu dài.

Trong một số dự án bị xâm phạm, kẻ tấn công đã:

• Can thiệp vào workflow của GitHub Actions
• Trích xuất OIDC token tạm thời từ môi trường runner
• Dùng token đó để xác thực quá trình publish

Do việc phát hành được thực hiện bởi chính pipeline của dự án, npm coi các package này là bản phát hành hợp pháp từ hệ thống build chính thức.

Malware có chữ ký số hợp lệ

Các hệ thống hiện đại thường tạo chứng thực nguồn gốc build (SLSA provenance) và ký package bằng chứng chỉ Sigstore để người dùng xác minh phần mềm được build từ pipeline tin cậy.

Điều đáng lo trong vụ Mini Shai‑Hulud là:

• Kẻ tấn công dùng danh tính CI bị chiếm quyền
• Lấy được chứng chỉ ký hợp lệ
• Phát hành package độc hại nhưng vẫn có SLSA Build Level 3 provenance hợp lệ

Về mặt kỹ thuật, các package này trông hoàn toàn hợp lệ khi kiểm tra chữ ký và nguồn gốc build.

Vấn đề không nằm ở hệ thống ký, mà ở chỗ pipeline đáng tin cậy đã bị xâm nhập từ trước.

Malware tìm cách đánh cắp những gì?

Các package độc hại chứa mã nhằm thu thập nhiều loại thông tin nhạy cảm trong môi trường phát triển và CI/CD.

Theo các báo cáo, malware tìm cách lấy:

• Token và credential của hệ thống CI/CD
• Khóa truy cập dịch vụ cloud
• Token truy cập GitHub hoặc npm
• SSH key và các secret của developer

Một số phân tích cho thấy malware có thể thu thập hơn 80 loại credential khác nhau, sau đó gửi dữ liệu ra ngoài thông qua các kênh được ngụy trang như telemetry.

Khi có được các secret này, kẻ tấn công có thể tiếp tục xâm nhập repository hoặc pipeline khác, khiến malware tự lan truyền qua nhiều dự án nguồn mở.

Vì sao đây là mối đe dọa lớn với hệ sinh thái JavaScript

Chiến dịch Mini Shai‑Hulud cho thấy nhiều điểm yếu đáng lo ngại của chuỗi cung ứng phần mềm hiện đại.

Thứ nhất: hạ tầng tin cậy có thể bị lợi dụng.
Ngay cả những cơ chế bảo mật mới như OIDC trusted publishing, Sigstore hay SLSA cũng không ngăn được phát hành độc hại nếu pipeline build đã bị chiếm quyền.

Thứ hai: một tài khoản maintainer có thể ảnh hưởng hàng trăm package.
Sự cố AntV cho thấy chỉ một tài khoản bị xâm phạm cũng đủ để phát hành hàng trăm phiên bản độc hại trong vài phút.

Thứ ba: dependency làm tăng phạm vi ảnh hưởng.
Nhiều thư viện bị tấn công là dependency của các package khác, nên bản cập nhật độc hại có thể lan sang hàng nghìn dự án thông qua dependency chain.

Thứ tư: chiến dịch có dấu hiệu tiếp diễn.
Các nhà nghiên cứu liên kết Mini Shai‑Hulud với chiến dịch lớn hơn của TeamPCP, bao gồm việc xâm phạm plugin Jenkins của Checkmarx và tấn công nhiều hệ sinh thái mã nguồn mở khác.

Bài học cho cộng đồng phát triển

Mini Shai‑Hulud cho thấy một thực tế quan trọng: chữ ký số và xác minh nguồn gốc không đủ để đảm bảo an toàn nếu pipeline build bị kiểm soát bởi kẻ tấn công.

Vì vậy, ngày càng nhiều tổ chức tập trung vào việc:

• cô lập runner CI
• hạn chế quyền của workflow
• giám sát các hoạt động publish bất thường
• kiểm tra dependency liên tục

Khi quy trình phát hành phần mềm ngày càng tự động hóa, bảo mật danh tính developer và hạ tầng CI/CD đang trở thành tuyến phòng thủ quan trọng không kém bản thân mã nguồn.

Mini Shai‑Hulud là minh chứng cho việc chỉ một lỗ hổng trong chuỗi tin cậy cũng có thể lan rộng ra toàn bộ hệ sinh thái phần mềm nguồn mở.