Trong 93 phút, việc cài đặt CLI 'chính thức' của Bitwarden đã biến laptop thành Launchpad để chiếm đoạt tài khoản GitHub

Vào ngày 22/4, một phiên bản độc hại của giao diện dòng lệnh Bitwarden xuất hiện trên npm dưới tên gói chính thức @bitwarden/cli@2026.4.0. Trong 93 phút, bất kỳ ai tải CLI qua npm đều nhận được một công cụ thay thế có cài backdoor thay vì công cụ hợp lệ.

Bitwarden phát hiện sự xâm phạm, gỡ bỏ gói và phát đi tuyên bố cho biết không tìm thấy bằng chứng nào cho thấy kẻ tấn công truy cập dữ liệu vault của người dùng cuối hoặc xâm phạm hệ thống sản xuất.

Công ty nghiên cứu bảo mật JFrog phân tích payload độc hại và phát hiện nó không đặc biệt quan tâm đến vault của Bitwarden. Mục tiêu của nó là token GitHub, token npm, khóa SSH, lịch sử shell, thông tin xác thực AWS, thông tin xác thực GCP, thông tin xác thực Azure, bí mật GitHub Actions và các tệp cấu hình công cụ AI.

Đây là những thông tin xác thực chi phối cách các nhóm xây dựng, triển khai và tiếp cận hạ tầng của họ.

Bitwarden phục vụ hơn 50.000 doanh nghiệp và 10 triệu người dùng, và tài liệu của chính họ mô tả CLI là cách "mạnh mẽ, đầy đủ tính năng" để truy cập và quản lý vault, kể cả trong các workflow tự động xác thực bằng biến môi trường.

Bitwarden liệt kê npm là phương pháp cài đặt đơn giản và được ưu tiên nhất cho người dùng đã quen với registry. Sự kết hợp giữa việc sử dụng tự động hóa, cài đặt trên máy nhà phát triển và phân phối npm chính thức đặt CLI đúng vào vị trí mà các bí mật hạ tầng có giá trị cao thường tồn tại.

Phân tích của JFrog cho thấy gói độc hại đã thay đổi cả hook preinstall và entrypoint nhị phân bw thành một loader tải runtime Bun và khởi chạy payload bị làm rối. Sự xâm phạm được kích hoạt cả lúc cài đặt và lúc chạy.

Một tổ chức có thể chạy CLI có backdoor mà không chạm vào bất kỳ mật khẩu nào được lưu trữ trong khi phần mềm độc hại thu thập có hệ thống các thông tin xác thực chi phối pipeline CI, tài khoản đám mây và tự động hóa triển khai của tổ chức đó.

Công ty bảo mật Socket cho biết cuộc tấn công có vẻ đã khai thác một GitHub Action bị xâm phạm trong pipeline CI/CD của Bitwarden, phù hợp với một mô hình mà các nhà nghiên cứu Checkmarx đang theo dõi.

Bitwarden xác nhận rằng sự cố có liên quan đến chiến dịch chuỗi cung ứng rộng lớn hơn của Checkmarx.

Nút thắt cổ chai về sự tin cậy

Npm xây dựng mô hình phát hành đáng tin cậy của mình để giải quyết chính xác loại rủi ro này.

Bằng cách thay thế token npm publish tồn tại lâu dài bằng xác thực CI/CD dựa trên OIDC, hệ thống loại bỏ một trong những con đường phổ biến nhất mà kẻ tấn công sử dụng để chiếm đoạt các bản phát hành registry, và npm khuyến nghị phát hành đáng tin cậy và coi đó là một bước tiến có ý nghĩa.

Bề mặt khó hơn là logic phát hành, chẳng hạn như các workflow và action gọi bước publish. Tài liệu của npm khuyến nghị các biện pháp kiểm soát ngoài OIDC, chẳng hạn như môi trường triển khai với yêu cầu phê duyệt thủ công, quy tắc bảo vệ tag và giới hạn branch.

Cài đặt môi trường của GitHub cho phép các tổ chức yêu cầu sự phê duyệt của người đánh giá trước khi workflow có thể triển khai. Framework SLSA đi xa hơn bằng cách yêu cầu người dùng xác minh rằng nguồn gốc khớp với các tham số kỳ vọng, chẳng hạn như đúng repository, branch, tag, workflow và cấu hình build.

Sự cố Bitwarden cho thấy vấn đề khó hơn nằm ở lớp workflow. Nếu kẻ tấn công có thể khai thác chính workflow phát hành, huy hiệu "chính thức" vẫn đi kèm với gói độc hại.

Phát hành đáng tin cậy chuyển gánh nặng tin cậy lên cao hơn đến tính toàn vẹn của các workflow và action gọi nó, một lớp mà các tổ chức phần lớn bỏ qua.

Một token mở nhiều cánh cửa

Đối với các nhóm nhà phát triển và hạ tầng, một workflow phát hành bị xâm phạm làm lộ pipeline CI, hạ tầng tự động hóa và các thông tin xác thực chi phối chúng.

Phân tích của JFrog cho thấy một khi phần mềm độc hại có được token GitHub, nó có thể xác thực token, liệt kê các repository có thể ghi, liệt kê bí mật GitHub Actions, tạo một branch, commit một workflow, chờ nó thực thi, tải xuống các artifact kết quả và sau đó dọn dẹp.

Việc có được token tạo ra một chuỗi tự động biến một thông tin xác thực bị đánh cắp duy nhất thành quyền truy cập liên tục trên toàn bộ hạ tầng tự động hóa của một tổ chức.

Laptop của một nhà phát triển cài đặt gói chính thức bị đầu độc trở thành cầu nối từ kho thông tin xác thực cục bộ của máy chủ đến quyền truy cập GitHub và bất cứ điều gì token GitHub đó có thể tiếp cận.

Sự cố Bybit là một sự tương đồng cấu trúc gần gũi. Một máy trạm nhà phát triển bị xâm phạm cho phép kẻ tấn công đầu độc một giao diện upstream đáng tin cậy, sau đó tiếp cận quy trình vận hành của nạn nhân.

Sự khác biệt là Bybit liên quan đến giao diện web Safe bị giả mạo, trong khi Bitwarden liên quan đến gói npm chính thức bị giả mạo.

Trong môi trường crypto, fintech hoặc lưu ký, con đường đó có thể chạy từ kho thông tin xác thực đến người ký phát hành, quyền truy cập đám mây và hệ thống triển khai mà không bao giờ chạm vào một mục vault.

Trong vòng 60 ngày, Checkmarx tiết lộ các workflow GitHub Actions và plugin OpenVSX bị xâm phạm, trong khi Cloud Security Alliance cảnh báo rằng chiến dịch TeamPCP đang tích cực xâm phạm các dự án mã nguồn mở và các thành phần tự động hóa CI/CD.

JFrog ghi lại cách một GitHub Action Trivy bị xâm phạm đã lấy cắp token publish của LiteLLM và cho phép các bản phát hành PyPI độc hại, và Axios tiết lộ rằng hai phiên bản npm độc hại đã lưu hành trong khoảng ba giờ thông qua một tài khoản người duy trì bị xâm phạm.

Sonatype đếm được hơn 454.600 gói độc hại mới chỉ riêng trong năm 2025, đưa tổng cộng lũy kế lên hơn 1,2 triệu. Bitwarden tham gia vào một chuỗi sự cố xác nhận workflow phát hành và registry gói là bề mặt tấn công chính.

Nguyên nhân gốc rễ chính xác chưa được công khai, vì Bitwarden đã xác nhận kết nối với chiến dịch Checkmarx nhưng chưa công bố phân tích chi tiết về cách kẻ tấn công có được quyền truy cập vào pipeline phát hành.

Kết quả của cuộc tấn công

Kết quả mạnh mẽ nhất cho các nhà phòng thủ là sự cố này đẩy nhanh việc định nghĩa lại ý nghĩa của "chính thức".

Ngày nay, phát hành đáng tin cậy đính kèm dữ liệu nguồn gốc vào mỗi gói được phát hành, từ đó xác nhận danh tính của nhà phát hành trong registry. SLSA ghi lại rõ ràng một tiêu chuẩn cao hơn để các bên xác minh kiểm tra xem nguồn gốc có khớp với repository, branch, workflow và tham số build kỳ vọng hay không.

Nếu tiêu chuẩn đó trở thành hành vi mặc định của người dùng, "chính thức" bắt đầu có nghĩa là "được xây dựng bởi workflow đúng trong các ràng buộc đúng", và một kẻ tấn công xâm phạm một action nhưng không thể thỏa mãn mọi ràng buộc nguồn gốc sẽ tạo ra một gói mà người dùng tự động từ chối trước khi nó được triển khai.

Con đường khả thi hơn trong ngắn hạn lại chạy theo hướng ngược lại. Kẻ tấn công đã chứng minh qua ít nhất 4 sự cố trong 60 ngày rằng workflow phát hành, phụ thuộc action và thông tin xác thực liền kề với người duy trì mang lại kết quả có giá trị cao với ma sát tương đối thấp.

Mỗi sự cố tiếp theo bổ sung thêm một kỹ thuật được ghi lại vào một playbook công khai về xâm phạm action, đánh cắp token từ đầu ra CI, chiếm đoạt tài khoản người duy trì và lạm dụng đường dẫn phát hành đáng tin cậy.

Trừ khi xác minh nguồn gốc trở thành hành vi mặc định của người dùng thay vì một lớp chính sách tùy chọn, tên gói chính thức sẽ nhận được nhiều sự tin cậy hơn mà các quy trình phát hành của chúng có thể biện hộ.

Bài đăng Trong 93 phút, việc cài đặt CLI "chính thức" của Bitwarden đã biến laptop thành bàn đạp để chiếm đoạt tài khoản GitHub xuất hiện đầu tiên trên CryptoSlate.