Tin tặc biến GitHub Actions thành botnet để tấn công cPanel: Chiến dịch quy mô chưa từng thấy

583 file workflow độc hại

Cốt lõi của cuộc tấn công không nằm trong mã PHP; các thư viện PHP vẫn lành tính, không có hook cài đặt hay hoạt động mạng độc hại nào . Thay vào đó, kẻ tấn công đã nhồi 583 file workflow GitHub Actions độc hại (.github/workflows/*.yml) vào các kho mã nguồn của nhà phát triển. Mỗi phiên bản gói bị ảnh hưởng chứa từ 55 đến 62 file workflow này . Workflow GitHub Actions là các file YAML xác định các tác vụ tự động, như chạy kiểm thử hoặc triển khai mã. Kẻ tấn công đã tái sử dụng cơ sở hạ tầng tự động hóa hợp pháp này.

Cơ chế độc hại

Khi một bản sao (fork) hoặc bản sao chép của kho mã bị xâm phạm kích hoạt một workflow (ví dụ: qua sự kiện push), file .yml độc hại sẽ hướng dẫn runner Ubuntu do GitHub lưu trữ thực hiện các bước sau :

1. Phát hiện kiến trúc CPU của runner.
2. Tải xuống một payload quét và khai thác từ máy chủ điều khiển (C2) tại địa chỉ IP 43[.]228[.]157[.]68.
3. Quét internet để tìm các hệ thống đang chạy dịch vụ cPanel và WHM.
4. Tự động khai thác các hệ thống đã xác định bằng lỗ hổng được mô tả chi tiết bên dưới.
5. Gửi dữ liệu đánh cắp về máy chủ C2.

Điều này đã biến mọi workflow bị kích hoạt thành một nút quét và khai thác, sử dụng cơ sở hạ tầng miễn phí của GitHub như một nền tảng phân tán cho cuộc tấn công .

Lỗ hổng: CVE-2026-41940

Mục tiêu của chiến dịch là CVE-2026-41940, một lỗ hổng nghiêm trọng trong cPanel và WebHost Manager (WHM) .

• Loại: Vượt qua xác thực trước khi xác thực (pre-authentication authentication bypass) .
• Mức độ nghiêm trọng: CVSS 9.8 (Nghiêm trọng) .
• Nguyên nhân gốc rễ: Lỗ hổng chèn CRLF (Carriage Return Line Feed) trong trình xử lý xác thực cơ bản cpsrvd . Kẻ tấn công chưa xác thực có thể gửi một header Authorization được chế tạo có chứa các ký tự xuống dòng thô. Điều này cho phép chúng chèn các thuộc tính tùy ý vào file phiên, chẳng hạn như user=root và hasroot=1, cấp cho chúng quyền truy cập quản trị cấp độ root vào giao diện WHM mà không cần mật khẩu hợp lệ .
• Ngày vá lỗi: cPanel đã phát hành bản cập nhật bảo mật vào ngày 28 tháng 4 năm 2026 . Điều này có nghĩa là kẻ tấn công đã có vài tháng để phân tích bản vá trước khi chiến dịch này bắt đầu.

Dữ liệu bị đánh cắp

Sau khi khai thác thành công một máy chủ cPanel/WHM bị xâm phạm, payload hậu khai thác được thiết kế để thu thập nhiều loại thông tin xác thực và bí mật. Các mục tiêu chính bao gồm :

• Thông tin xác thực đám mây: Khóa Amazon Web Services (AWS).
• Token quản lý mã nguồn: Token GitHub, token GitLab.
• Khóa API: OpenAI, Google API.
• Xử lý thanh toán: Khóa Stripe.
• Thông tin xác thực dịch vụ email: (ví dụ: Mailgun, SendGrid).
• Cơ sở hạ tầng: Khóa SSH riêng tư, thông tin xác thực cơ sở dữ liệu.
• Dữ liệu cấu hình: Cấu hình Git remote.

Việc đánh cắp nhiều loại thông tin xác thực như vậy cho thấy một hành vi thu thập dữ liệu bất kỳ, cơ hội, nhằm vào bất kỳ token truy cập có giá trị nào hiện diện trên máy chủ bị xâm phạm .

Quy mô chiến dịch: Hàng nghìn kho mã khác bị xâm phạm

583 file workflow trong 10 gói Packagist chỉ là khám phá ban đầu. Bằng cách xoay trục từ các chỉ số của kẻ tấn công như tên miền callback DNSHook dùng chung và các mẫu tái sử dụng mã, các nhà nghiên cứu đã phát hiện ra một chiến dịch lớn hơn nhiều :

• Khoảng 6.100 file workflow được liên kết trực tiếp với cùng cơ sở hạ tầng của kẻ tấn công .
• Khoảng 15.000 đến 16.000 file workflow trên GitHub được tìm thấy khớp với các mẫu liên quan từ chiến dịch .

Sự chênh lệch lớn này cho thấy kẻ tấn công có thể đã xâm phạm nhiều tài khoản nhà phát triển và kho mã hơn nữa ngoài tài khoản dinushchathurya . Chiến dịch này không phải là một thất bại đơn lẻ mà là một hoạt động phối hợp, đa tài khoản. The Hacker News đã đưa tin về một cuộc tấn công chuỗi cung ứng Packagist riêng biệt, trước đó vào tháng 5/2026, đã xâm phạm 8 gói với các yếu tố độc hại có liên quan , càng làm nổi bật tính dễ bị tổn thương của hệ sinh thái.

Rủi ro đang diễn ra: Tại sao chiến dịch có thể vẫn còn hoạt động

Chiến dịch này đặt ra một mối đe dọa dai dẳng vì cơ sở hạ tầng của kẻ tấn công chưa bị vô hiệu hóa hoàn toàn. Chiến dịch có thể tiếp tục thông qua :

• Các bản sao chép (Fork) và gương (Mirror): Các file workflow độc hại có thể tồn tại trong các bản sao chép hoặc gương của các kho mã bị xâm phạm.
• Bản snapshot được lưu trong bộ nhớ đệm (Cache): Bộ nhớ đệm của chính GitHub có thể chứa các phiên bản workflow độc hại.
• Thông tin xác thực bị đánh cắp: Các thông tin xác thực đã bị gửi đi vẫn nằm trong tay kẻ tấn công và có thể được sử dụng cho các cuộc tấn công tiếp theo.
• Cơ sở hạ tầng C2 còn sống sót: Máy chủ C2 (43[.]228[.]157[.]68) có thể vẫn còn hoạt động và đang tích cực nhận dữ liệu .

Mặc dù tài khoản Packagist của nhà phát triển ban đầu đã bị đình chỉ, nhưng quy mô của các file workflow khớp (lên tới ~16.000) có nghĩa là hoạt động này có một phạm vi rộng khó có thể xóa bỏ hoàn toàn .

Các hành động phòng thủ cần thiết

Dựa trên phân tích đã được công bố, các tổ chức và nhà phát triển nên thực hiện các hành động sau ngay lập tức :

1. Vá lỗi cPanel/WHM ngay lập tức: CVE-2026-41940 đã được vá vào ngày 28 tháng 4 năm 2026. Bất kỳ bản cài đặt cPanel hoặc WHM nào (các phiên bản sau 11.40) chưa được cập nhật đều có thể bị khai thác dễ dàng bởi kẻ tấn công từ xa chưa xác thực. Đây là bước quan trọng nhất.
2. Kiểm tra tất cả Workflow GitHub Actions: Xem xét mọi file workflow YAML trong kho mã của bạn, đặc biệt là những file:
   • Tải xuống và thực thi các tệp nhị phân bên ngoài.
   • Thực hiện các kết nối mạng ra ngoài.
   • Chạy trên các trình kích hoạt push hoặc workflow_dispatch mà không cần xem xét thủ công.
   • Có trong các nhánh phát triển hoặc tính năng có thể được đồng bộ hóa tự động bởi trình quản lý gói.
3. Xoay vòng tất cả thông tin xác thực bị lộ: Giả định rằng bất kỳ thông tin xác thực nào hiện diện trên máy chủ cPanel/WHM bị xâm phạm đã bị đánh cắp. Điều này bao gồm, nhưng không giới hạn ở:
   • Khóa nhà cung cấp đám mây (AWS, GCP, Azure).
   • Token API (OpenAI, Google, Stripe).
   • Khóa SSH và mật khẩu cơ sở dữ liệu.
   • Token quản lý mã nguồn (GitHub, GitLab).
4. Kiểm tra các Chỉ số Xâm phạm (IOC) đã biết: Tìm kiếm trong nhật ký của bạn các kết nối mạng đến địa chỉ IP C2 của kẻ tấn công (43[.]228[.]157[.]68) và tên miền callback DNSHook đã biết .
5. Tăng cường bảo mật Kho mã và Quản lý Gói:
   • Kích hoạt các quy tắc bảo vệ nhánh (branch protection rules) trên tất cả các nhánh phát triển.
   • Yêu cầu các commit đã ký (signed commits).
   • Tránh tự động đồng bộ hóa các kho lưu trữ gói (như Packagist) trực tiếp từ các nhánh kho mã mà không có bước xem xét .
6. Xem xét các Phiên bản Phát triển của Packagist: Khi kiểm tra các phụ thuộc, hãy kiểm tra cụ thể các phiên bản phát triển (dev-master, dev-main) để tìm các file .github/workflows/ bất ngờ, vì mã PHP có thể sạch sẽ trong khi cuộc tấn công hoàn toàn nằm trong cấu hình CI/CD .