Duy Linh✔
Writer
Một lỗ hổng trong cơ chế Trusted Publishing (Xuất bản tin cậy) của npm có thể cho phép kẻ tấn công phát hành các phiên bản độc hại dưới tên những gói phần mềm hợp pháp mà không cần chiếm quyền tài khoản npm, tài khoản GitHub hay mã thông báo xuất bản của nhà phát triển. Được Bloom Security đặt tên là SlugFest, lỗ hổng này làm dấy lên lo ngại về an toàn chuỗi cung ứng phần mềm, đặc biệt khi các công cụ lập trình sử dụng trí tuệ nhân tạo (AI) ngày càng tự động lựa chọn, cài đặt và thực thi các thư viện phụ thuộc.
Các nhà nghiên cứu xác định hơn 1.500 gói phần mềm có khả năng bị ảnh hưởng, với tổng cộng hơn 10 triệu lượt tải xuống. Nếu bị khai thác, điểm yếu này có thể tạo điều kiện để mã độc xâm nhập vào dự án thông qua những gói phần mềm vốn đã có uy tín, từ đó tiếp tục lan rộng sang các hệ thống và ứng dụng phụ thuộc vào chúng.
Mối nguy hiểm càng đáng quan tâm khi quá trình phát tán mã độc không nhất thiết phải dựa vào việc lừa nhà phát triển tự tay chạy lệnh cài đặt. Kẻ tấn công chỉ cần đưa phiên bản độc hại vào một gói được tác nhân AI lựa chọn trong quá trình lập trình, xây dựng phần mềm hoặc thực hiện các tác vụ tích hợp và triển khai liên tục (CI/CD).
Cách tiếp cận này giúp giảm nguy cơ thông tin bí mật bị rò rỉ qua nhật ký xây dựng, kho lưu trữ mã nguồn và hệ thống tự động hóa. Tuy nhiên, vấn đề nằm ở cách npm xác định mối quan hệ tin cậy giữa gói phần mềm và kho lưu trữ GitHub được phép phát hành nó.
Ban đầu, npm dựa vào đường dẫn kho lưu trữ GitHub, gồm tên chủ sở hữu và tên kho lưu trữ, để xác định nguồn xuất bản. Đây là những tên dễ đọc đối với con người nhưng có thể thay đổi khi kho lưu trữ được đổi tên, chuyển giao, xóa hoặc khi chủ sở hữu thay đổi tên tài khoản hay biến mất.
Trong khi đó, mã thông báo OIDC của GitHub chứa các định danh bất biến như <span>repository_id</span> và <span>repository_owner_id</span>. Những định danh này vẫn tồn tại ngay cả khi tên kho lưu trữ hoặc chủ sở hữu thay đổi. Tuy nhiên, cơ chế ban đầu của npm chưa liên kết Trusted Publishing với các định danh bất biến này. Thay vào đó, cấu hình tin cậy có thể tiếp tục gắn với tên kho lưu trữ có khả năng được người khác sử dụng lại cho đến khi lần xuất bản tin cậy đầu tiên thành công.
Điểm yếu này mở ra khả năng chiếm đoạt gói phần mềm. Kẻ tấn công có thể chiếm lấy đường dẫn GitHub đã bị bỏ lại, tạo một kho lưu trữ mới với tên phù hợp và thiết lập quy trình làm việc có tên tệp được mong đợi. Sau đó, chúng sử dụng GitHub Actions để lấy mã thông báo OIDC và đổi mã này lấy thông tin xác thực xuất bản npm hợp lệ.
Toàn bộ quá trình có thể diễn ra mà không cần truy cập thông tin đăng nhập, tài khoản hoặc kho lưu trữ của nhà bảo trì ban đầu.
Bloom Security đã chứng minh khả năng khai thác trong môi trường được kiểm soát, sử dụng các kho lưu trữ và phạm vi tên gói npm do chính nhóm nghiên cứu sở hữu. Các nhà nghiên cứu phát hiện rằng một kho lưu trữ mới được tạo bằng tên người dùng đã được khôi phục có thể phát hành dữ liệu vào một gói phần mềm vẫn tin tưởng vị trí kho lưu trữ cũ.
Nếu cuộc tấn công thành công, kẻ tấn công có thể phát hành phiên bản mới dưới tên hợp pháp của gói bị ảnh hưởng. Phiên bản độc hại khi đó có thể kế thừa danh tiếng, lượng tải xuống và vị trí sẵn có của gói trong đồ thị phụ thuộc phần mềm.
Đặc biệt, bản phát hành độc hại có thể chứa tập lệnh vòng đời <span>postinstall</span>, cho phép mã được thực thi khi nhà phát triển, hệ thống CI hoặc công cụ tự động chạy lệnh <span>npm </span><span>install</span>. Điều này khiến nguy cơ không chỉ dừng lại ở người dùng trực tiếp của gói phần mềm.
Một gói bị chiếm đoạt còn có thể ảnh hưởng đến các dự án khác thông qua những phụ thuộc bắc cầu, tức các thư viện mà dự án sử dụng gián tiếp thông qua những gói phụ thuộc khác. Vì vậy, một lỗi trong cơ chế xác thực danh tính kho lưu trữ có thể trở thành sự cố trên diện rộng đối với chuỗi cung ứng phần mềm.
Các nhà nghiên cứu cũng cảnh báo rằng việc kiểm tra nguồn gốc phần mềm không phải lúc nào cũng đủ để ngăn chặn kiểu tấn công này. Chứng thực Sigstore vẫn có thể trông hợp lệ nếu công cụ kiểm tra chỉ xác nhận rằng gói đã được ký, thay vì xác minh nguồn gốc có thực sự trỏ đến kho lưu trữ do nhà bảo trì kiểm soát như dự kiến hay không.
Vụ tấn công (Nguồn: Bloom).
Theo số liệu Bloom Security thu thập tại hàng chục tổ chức, các tác nhân AI cài đặt trực tiếp khoảng 70 gói phần mềm trên mỗi thiết bị đầu cuối mỗi tháng. Con số này tăng lên khoảng 350 gói mỗi tháng trên các máy tính của nhà phát triển. Những số liệu trên chưa bao gồm các phụ thuộc bắc cầu, do đó tổng số gói phần mềm thực tế mà các hệ thống tiếp xúc có thể lớn hơn đáng kể.
Điều này không có nghĩa các tác nhân AI là nguyên nhân tạo ra lỗ hổng. Thay vào đó, chúng có thể khuếch đại hậu quả bằng cách tự động đưa các gói độc hại vào môi trường phát triển với tốc độ cao. Một phiên bản bị cài cắm mã độc có thể được đưa vào hệ thống trước khi nhà phát triển kịp nhận ra sự thay đổi trong lựa chọn thư viện hoặc kiểm tra lịch sử phát hành.
Bloom Security đã báo cáo vấn đề thông qua chương trình HackerOne của GitHub vào ngày 6/6/2026 và cho biết báo cáo được xác nhận ngày 9/6. GitHub triển khai biện pháp khắc phục vào ngày 2/10/2026, tức hơn 120 ngày sau khi vấn đề được báo cáo.
Theo thông tin về biện pháp khắc phục, npm hiện tự động hết hạn các cấu hình Trusted Publishing chưa được xác thực sau 48 giờ kể từ khi tạo. Cấu hình chỉ được xác thực sau lần xuất bản thành công đầu tiên. Nếu không được sử dụng trong vòng hai ngày, cấu hình sẽ không còn đủ điều kiện để cho phép phát hành gói phần mềm.
GitHub cho biết thay đổi này giúp giảm nguy cơ tên kho lưu trữ hoặc dự án bị thay đổi quyền sở hữu trước khi danh tính của bên phát hành được xác thực.
npm cũng từ chối các mã thông báo Trusted Publishing được kích hoạt thông qua sự kiện <span>issue_comment</span> của GitHub Actions, bổ sung cho hạn chế đã có đối với sự kiện <span>pull_request_target</span>. Những nhà bảo trì sử dụng quy trình làm việc bị ảnh hưởng cần chuyển hoạt động xuất bản sang các sự kiện được cho phép, chẳng hạn <span>push</span>, <span>release</span> hoặc <span>workflow_dispatch</span>.
Bên cạnh các biện pháp khắc phục từ nền tảng, nhà bảo trì cần rà soát từng cấu hình Trusted Publishing để xác minh rằng kho lưu trữ GitHub được liên kết vẫn nằm dưới quyền kiểm soát của mình. Những liên kết hiện có cần được xóa và tạo lại sau khi kho lưu trữ được đổi tên, chuyển giao hoặc thay đổi quyền sở hữu.
Trước khi xóa kho lưu trữ GitHub liên kết với một gói npm, nhà bảo trì nên xóa hoặc thay thế cấu hình Nhà xuất bản đáng tin cậy tương ứng. Lệnh <span>npm </span><span>trust </span><span>list</span> có thể được sử dụng để kiểm tra các mối quan hệ xuất bản đã cấu hình.
Đối với đội ngũ bảo mật doanh nghiệp, sự cố SlugFest cũng củng cố yêu cầu xem các tác nhân AI như những người dùng phần mềm có khả năng hoạt động tự chủ. Các tổ chức cần xác định rõ những gói mà tác nhân được phép cài đặt, kiểm tra các tập lệnh vòng đời như <span>postinstall</span>, ghim phiên bản hoặc rà soát các bản cập nhật phụ thuộc, đồng thời liên tục giám sát những bản phát hành bất thường trong các chuỗi phụ thuộc quan trọng.
Các nhà nghiên cứu xác định hơn 1.500 gói phần mềm có khả năng bị ảnh hưởng, với tổng cộng hơn 10 triệu lượt tải xuống. Nếu bị khai thác, điểm yếu này có thể tạo điều kiện để mã độc xâm nhập vào dự án thông qua những gói phần mềm vốn đã có uy tín, từ đó tiếp tục lan rộng sang các hệ thống và ứng dụng phụ thuộc vào chúng.
Mối nguy hiểm càng đáng quan tâm khi quá trình phát tán mã độc không nhất thiết phải dựa vào việc lừa nhà phát triển tự tay chạy lệnh cài đặt. Kẻ tấn công chỉ cần đưa phiên bản độc hại vào một gói được tác nhân AI lựa chọn trong quá trình lập trình, xây dựng phần mềm hoặc thực hiện các tác vụ tích hợp và triển khai liên tục (CI/CD).
Cách SlugFest khai thác cơ chế xuất bản tin cậy của npm
npm Trusted Publishing được thiết kế nhằm loại bỏ nhu cầu sử dụng các mã thông báo đăng ký có thời hạn dài trong những quy trình CI/CD. Thay vì lưu trữ thông tin xác thực lâu dài, quy trình GitHub Actions có thể lấy mã thông báo OpenID Connect (OIDC) với thời hạn ngắn, sau đó sử dụng mã này để nhận thông tin xác thực xuất bản npm có thời hạn.Cách tiếp cận này giúp giảm nguy cơ thông tin bí mật bị rò rỉ qua nhật ký xây dựng, kho lưu trữ mã nguồn và hệ thống tự động hóa. Tuy nhiên, vấn đề nằm ở cách npm xác định mối quan hệ tin cậy giữa gói phần mềm và kho lưu trữ GitHub được phép phát hành nó.
Ban đầu, npm dựa vào đường dẫn kho lưu trữ GitHub, gồm tên chủ sở hữu và tên kho lưu trữ, để xác định nguồn xuất bản. Đây là những tên dễ đọc đối với con người nhưng có thể thay đổi khi kho lưu trữ được đổi tên, chuyển giao, xóa hoặc khi chủ sở hữu thay đổi tên tài khoản hay biến mất.
Trong khi đó, mã thông báo OIDC của GitHub chứa các định danh bất biến như <span>repository_id</span> và <span>repository_owner_id</span>. Những định danh này vẫn tồn tại ngay cả khi tên kho lưu trữ hoặc chủ sở hữu thay đổi. Tuy nhiên, cơ chế ban đầu của npm chưa liên kết Trusted Publishing với các định danh bất biến này. Thay vào đó, cấu hình tin cậy có thể tiếp tục gắn với tên kho lưu trữ có khả năng được người khác sử dụng lại cho đến khi lần xuất bản tin cậy đầu tiên thành công.
Điểm yếu này mở ra khả năng chiếm đoạt gói phần mềm. Kẻ tấn công có thể chiếm lấy đường dẫn GitHub đã bị bỏ lại, tạo một kho lưu trữ mới với tên phù hợp và thiết lập quy trình làm việc có tên tệp được mong đợi. Sau đó, chúng sử dụng GitHub Actions để lấy mã thông báo OIDC và đổi mã này lấy thông tin xác thực xuất bản npm hợp lệ.
Toàn bộ quá trình có thể diễn ra mà không cần truy cập thông tin đăng nhập, tài khoản hoặc kho lưu trữ của nhà bảo trì ban đầu.
Bloom Security đã chứng minh khả năng khai thác trong môi trường được kiểm soát, sử dụng các kho lưu trữ và phạm vi tên gói npm do chính nhóm nghiên cứu sở hữu. Các nhà nghiên cứu phát hiện rằng một kho lưu trữ mới được tạo bằng tên người dùng đã được khôi phục có thể phát hành dữ liệu vào một gói phần mềm vẫn tin tưởng vị trí kho lưu trữ cũ.
Nếu cuộc tấn công thành công, kẻ tấn công có thể phát hành phiên bản mới dưới tên hợp pháp của gói bị ảnh hưởng. Phiên bản độc hại khi đó có thể kế thừa danh tiếng, lượng tải xuống và vị trí sẵn có của gói trong đồ thị phụ thuộc phần mềm.
Đặc biệt, bản phát hành độc hại có thể chứa tập lệnh vòng đời <span>postinstall</span>, cho phép mã được thực thi khi nhà phát triển, hệ thống CI hoặc công cụ tự động chạy lệnh <span>npm </span><span>install</span>. Điều này khiến nguy cơ không chỉ dừng lại ở người dùng trực tiếp của gói phần mềm.
Một gói bị chiếm đoạt còn có thể ảnh hưởng đến các dự án khác thông qua những phụ thuộc bắc cầu, tức các thư viện mà dự án sử dụng gián tiếp thông qua những gói phụ thuộc khác. Vì vậy, một lỗi trong cơ chế xác thực danh tính kho lưu trữ có thể trở thành sự cố trên diện rộng đối với chuỗi cung ứng phần mềm.
Các nhà nghiên cứu cũng cảnh báo rằng việc kiểm tra nguồn gốc phần mềm không phải lúc nào cũng đủ để ngăn chặn kiểu tấn công này. Chứng thực Sigstore vẫn có thể trông hợp lệ nếu công cụ kiểm tra chỉ xác nhận rằng gói đã được ký, thay vì xác minh nguồn gốc có thực sự trỏ đến kho lưu trữ do nhà bảo trì kiểm soát như dự kiến hay không.
AI có thể khuếch đại rủi ro, npm đã triển khai biện pháp khắc phục
SlugFest cho thấy mức độ phơi nhiễm của chuỗi cung ứng phần mềm đang thay đổi khi các công cụ lập trình AI ngày càng có khả năng tự lựa chọn thư viện phụ thuộc, cài đặt chúng và thực thi tập lệnh vòng đời với sự giám sát hạn chế của con người. Những công cụ được đề cập trong nghiên cứu bao gồm Claude Code, Codex, Gemini và Cursor.Vụ tấn công (Nguồn: Bloom).
Theo số liệu Bloom Security thu thập tại hàng chục tổ chức, các tác nhân AI cài đặt trực tiếp khoảng 70 gói phần mềm trên mỗi thiết bị đầu cuối mỗi tháng. Con số này tăng lên khoảng 350 gói mỗi tháng trên các máy tính của nhà phát triển. Những số liệu trên chưa bao gồm các phụ thuộc bắc cầu, do đó tổng số gói phần mềm thực tế mà các hệ thống tiếp xúc có thể lớn hơn đáng kể.
Điều này không có nghĩa các tác nhân AI là nguyên nhân tạo ra lỗ hổng. Thay vào đó, chúng có thể khuếch đại hậu quả bằng cách tự động đưa các gói độc hại vào môi trường phát triển với tốc độ cao. Một phiên bản bị cài cắm mã độc có thể được đưa vào hệ thống trước khi nhà phát triển kịp nhận ra sự thay đổi trong lựa chọn thư viện hoặc kiểm tra lịch sử phát hành.
Bloom Security đã báo cáo vấn đề thông qua chương trình HackerOne của GitHub vào ngày 6/6/2026 và cho biết báo cáo được xác nhận ngày 9/6. GitHub triển khai biện pháp khắc phục vào ngày 2/10/2026, tức hơn 120 ngày sau khi vấn đề được báo cáo.
Theo thông tin về biện pháp khắc phục, npm hiện tự động hết hạn các cấu hình Trusted Publishing chưa được xác thực sau 48 giờ kể từ khi tạo. Cấu hình chỉ được xác thực sau lần xuất bản thành công đầu tiên. Nếu không được sử dụng trong vòng hai ngày, cấu hình sẽ không còn đủ điều kiện để cho phép phát hành gói phần mềm.
GitHub cho biết thay đổi này giúp giảm nguy cơ tên kho lưu trữ hoặc dự án bị thay đổi quyền sở hữu trước khi danh tính của bên phát hành được xác thực.
npm cũng từ chối các mã thông báo Trusted Publishing được kích hoạt thông qua sự kiện <span>issue_comment</span> của GitHub Actions, bổ sung cho hạn chế đã có đối với sự kiện <span>pull_request_target</span>. Những nhà bảo trì sử dụng quy trình làm việc bị ảnh hưởng cần chuyển hoạt động xuất bản sang các sự kiện được cho phép, chẳng hạn <span>push</span>, <span>release</span> hoặc <span>workflow_dispatch</span>.
Bên cạnh các biện pháp khắc phục từ nền tảng, nhà bảo trì cần rà soát từng cấu hình Trusted Publishing để xác minh rằng kho lưu trữ GitHub được liên kết vẫn nằm dưới quyền kiểm soát của mình. Những liên kết hiện có cần được xóa và tạo lại sau khi kho lưu trữ được đổi tên, chuyển giao hoặc thay đổi quyền sở hữu.
Trước khi xóa kho lưu trữ GitHub liên kết với một gói npm, nhà bảo trì nên xóa hoặc thay thế cấu hình Nhà xuất bản đáng tin cậy tương ứng. Lệnh <span>npm </span><span>trust </span><span>list</span> có thể được sử dụng để kiểm tra các mối quan hệ xuất bản đã cấu hình.
Đối với đội ngũ bảo mật doanh nghiệp, sự cố SlugFest cũng củng cố yêu cầu xem các tác nhân AI như những người dùng phần mềm có khả năng hoạt động tự chủ. Các tổ chức cần xác định rõ những gói mà tác nhân được phép cài đặt, kiểm tra các tập lệnh vòng đời như <span>postinstall</span>, ghim phiên bản hoặc rà soát các bản cập nhật phụ thuộc, đồng thời liên tục giám sát những bản phát hành bất thường trong các chuỗi phụ thuộc quan trọng.
