Tóm tắt nhanh
- Chiến dịch wfx-loot dùng 4.837 tài khoản GitHub bị chiếm quyền để mở pull request thăm dò 61.764 kho mã.
- Ít nhất 1.835 kho đã chạy payload và bị lấy thông tin xác thực; con số này không đồng nghĩa toàn bộ kho bị thăm dò đều nhiễm mã độc.
- Mã độc tìm cả secrets của GitHub Actions, khóa đám mây, công cụ phát triển và API AI; sau đó kẻ tấn công có thể mở rộng quyền truy cập.
- Chủ kho nên kiểm tra dấu hiệu wfx-docs và pull request có tiêu đề docs: dependency audit notes, rồi thu hồi và cấp lại các bí mật có nguy cơ lộ.
Hơn 61.000 kho GitHub bị đưa vào danh sách thăm dò của chiến dịch wfx-loot, nhưng mục tiêu cuối không phải lấy mã nguồn: mã độc tìm cách rút secrets từ quy trình CI/CD, tài khoản đám mây và công cụ phát triển. Aikido Security cho biết 4.837 tài khoản bị chiếm đã mở pull request trên 61.764 kho; ít nhất 1.835 kho thực sự chạy payload và bị trích xuất thông tin xác thực.
Đây không phải bằng chứng máy chủ GitHub bị xâm nhập. Kẻ tấn công sử dụng token GitHub bị đánh cắp từ trước để tạo thay đổi trong những kho mà các tài khoản đó có quyền ghi, rồi lợi dụng GitHub Actions — hệ thống tự động chạy tác vụ khi có sự kiện như cập nhật mã.
Pull request thăm dò mở đường cho mã độc vào quy trình build
Chiến dịch bắt đầu khoảng 12:45 UTC ngày 10/11/2026. Trước tiên, tài khoản bị chiếm mở pull request mang tiêu đề docs: dependency audit notes từ nhánh wfx-docs. Đây là phép thử quyền ghi: kẻ tấn công tìm các kho mà token có thể thay đổi nội dung, bao gồm cả kho của tổ chức hoặc nhóm cộng đồng chứ không chỉ kho do chủ tài khoản sở hữu.
Nếu tìm được đường vào, payload được đưa vào theo một trong ba cách: chèn khoảng 1.500 dòng vào workflow hiện có, thêm shell script kèm hook postinstall trong dự án npm, hoặc tạo workflow mới trên một nhánh ngắn hạn. Vì vậy, pull request thăm dò tự nó chưa chứng minh mã độc đã chạy; dấu hiệu đáng lo hơn là các commit hay nhánh xuất hiện sau đó và việc workflow được thực thi.
Aikido ghi nhận 10.431 pull request nhắm vào kho mà tài khoản bị chiếm không sở hữu trực tiếp nhưng có thể truy cập. Theo báo cáo này, 92% pull request thăm dò vẫn mở tại thời điểm thống kê. Một yêu cầu trông như ghi chú kiểm tra dependency có thể bị bỏ qua, trong khi quyền ghi của tài khoản đã biến nó thành cửa ngõ để thay đổi cấu hình build.
Runner CI có thể chứa khóa đám mây và API AI
GitHub Actions runner thường nhận các biến và secrets để triển khai ứng dụng, ký bản phát hành hoặc kết nối dịch vụ bên ngoài. Khi workflow độc hại chạy với quyền phù hợp, nó có thể đọc những bí mật đó cùng token của workflow, thông tin trong môi trường chạy và các tệp thông tin xác thực mà runner truy cập được.
Danh sách Aikido mô tả bao gồm khóa AWS, Azure và Google Cloud; thông tin Git, SSH, Docker, Kubernetes, npm, PyPI, Vault và Terraform; cùng token cho OpenAI, Anthropic, Gemini, Cursor và các công cụ lập trình khác. Phạm vi thực tế phụ thuộc quyền của workflow, cấu hình runner và bí mật được cấp cho nó — không phải mọi kho đều có cùng mức rủi ro.
Điểm cần lưu ý là việc mất một token CI không dừng ở một lần build lỗi. Nếu token cho phép truy cập cloud hoặc phát hành package, kẻ tấn công có thể dùng nó để tiếp tục xâm nhập tài nguyên khác. Báo cáo của Aikido cũng mô tả khả năng lạm dụng quyền cloud và tạo cơ chế truy cập tồn tại sau khi một số thông tin xác thực được thay mới; do đó chỉ xóa commit độc hại không đủ để khẳng định sự cố đã được xử lý.
Dấu vết có thể biến mất trước khi người quản trị kịp kiểm tra
Sau khi chạy payload, kẻ tấn công có thể hoàn nguyên thay đổi và xóa lần chạy workflow cùng nhật ký trong tối đa một phút. Aikido cho biết một số kho bị ảnh hưởng không còn log; số thứ tự lần chạy bị khuyết trong lịch sử workflow có thể là dấu vết còn lại. Việc không thấy artifact hay log độc hại vì thế không chứng minh rằng bí mật chưa bị lấy.
Chủ kho và đội vận hành nên rà soát các pull request có tiêu đề docs: dependency audit notes, nhánh wfx-docs, nhánh ngắn dạng chore/ và các commit liên quan đến ci: refresh build cache, chore: add ci helper hoặc chore: add dependency audit workflow. Cần xem cả lịch sử workflow và các thay đổi đã bị revert, thay vì chỉ kiểm tra trạng thái hiện tại của nhánh mặc định.
Nếu workflow có dấu hiệu đã chạy payload, hãy coi mọi bí mật mà runner đó đọc được là đã lộ: thu hồi và cấp lại token, khóa cloud, khóa API; kiểm tra quyền và nhật ký truy cập của AWS, Azure hoặc Google Cloud; đồng thời rà soát role, ứng dụng và danh tính liên kết có thể đã bị thay đổi. Với runner tự quản lý, cần kiểm tra thêm máy chủ và thông tin xác thực lưu trên máy, bởi phạm vi truy cập của runner có thể rộng hơn các secrets khai báo trực tiếp trong GitHub.
Nhóm duy trì package cũng nên kiểm tra phiên bản bị nêu trong báo cáo: Packagist digitalelvis/neuronai-studio phiên bản 3.14.3, và Go module github.com/onuragtas/docker-env phiên bản v1.0.278 cùng v1.0.280. Aikido nói payload của hai phiên bản Go nằm trong workflow GitHub, không phải mã nguồn Go hay binary phát hành; người cài package vẫn nên xác minh nguồn và trạng thái dự án trước khi tiếp tục sử dụng.
Với lập trình viên và doanh nghiệp tại Việt Nam dùng GitHub Actions để triển khai lên cloud, việc rà soát nên bắt đầu từ quyền ghi của tài khoản và quyền của runner: token tối thiểu cần thiết, secrets chỉ cấp cho workflow tin cậy, cùng kiểm soát thay đổi workflow. Sau sự cố, việc thay khóa phải đi kèm xác minh log và quyền truy cập cloud; nếu không, thông tin xác thực mới có thể tiếp tục bị lộ qua cùng đường chạy.
Nguồn tham khảo: Aikido Security; BleepingComputer.
