Lỗ hổng RCE nghiêm trọng trên GitHub: CVE-2026-3854 cho phép chiếm quyền kiểm soát chỉ bằng một lệnh git push

Lỗ hổng RCE nghiêm trọng trên GitHub: CVE-2026-3854 cho phép chiếm quyền kiểm soát chỉ bằng một lệnh git push

Wiz Research vừa công bố một phát hiện bảo mật gây chấn động: một lỗ hổng thực thi mã từ xa (RCE) nghiêm trọng, được đánh giá là CVE-2026-3854, nằm sâu trong cơ sở hạ tầng nội bộ của GitHub. Điều đáng sợ là kẻ tấn công có thể khai thác lỗ hổng này chỉ bằng một lệnh git push thông thường, không cần công cụ phức tạp nào khác.

Lỗ hổng này ảnh hưởng đến cả GitHub.com và GitHub Enterprise Server (GHES). Trên GitHub.com, nó có thể dẫn đến việc truy cập vào các nút lưu trữ dùng chung, nơi chứa hàng triệu kho chứa công khai và riêng tư. Đối với GHES, lỗi này cho phép kẻ tấn công chiếm hoàn toàn quyền kiểm soát máy chủ.

Chi tiết kỹ thuật: Lỗi tiêm trong header X-Stat

Vấn đề nằm ở cách GitHub xử lý các tùy chọn push (push options) thông qua giao thức nội bộ của mình. Khi người dùng chạy lệnh git push -o "tùy_chọn", dữ liệu này đi qua một chuỗi các dịch vụ nội bộ:

1. babeld: Một proxy git đóng vai trò điểm nhập. Nó nhận kết nối SSH và chuyển tiếp xác thực.
2. gitauth: Dịch vụ xác thực nội bộ kiểm tra quyền của người dùng.
3. gitrpcd: Máy chủ RPC nội bộ nhận yêu cầu từ babeld.

Điểm mấu chốt nằm ở header X-Stat, chứa các cặp key=value được phân tách bằng dấu chấm phẩy (;). Wiz phát hiện rằng babeld sao chép giá trị của push option vào header này mà không thực hiện làm sạch (sanitize) dấu chấm phẩy.

Do cơ chế "last-write-wins" (giá trị sau ghi đè giá trị trước) của header này, kẻ tấn công có thể chèn các trường mới để ghi đè các cấu hình bảo mật quan trọng. Ví dụ, bằng cách gửi một push option chứa ;large_blob_rejection_enabled=bool:false;, kẻ tấn công có thể vô hiệu hóa giới hạn kích thước tệp.

Chuỗi khai thác dẫn đến RCE

Tuy nhiên, việc vô hiệu hóa giới hạn chưa phải là nguy hiểm nhất. Bằng cách kết hợp việc tiêm ba trường cụ thể, các nhà nghiên cứu đã đạt được thực thi mã từ xa:

• Bước 1 - Bypass Sandbox: Tiêm trường rails_env với một giá trị khác "production". Điều này chuyển quá trình thực thi hook từ môi trường sandbox an toàn sang môi trường không sandbox.
• Bước 2 - Chuyển hướng thư mục: Tiêm trường custom_hooks_dir để chỉ định thư mục cơ sở mà hệ thống sẽ tìm kiếm các script hook.
• Bước 3 - Tiêm định nghĩa hook: Tiêm trường repo_pre_receive_hooks với một đường dẫn dẫn đến tệp thực thi tùy ý trên hệ thống tệp (sử dụng kỹ thuật path traversal).

Kết quả là kẻ tấn công có thể thực thi bất kỳ lệnh nào với quyền của người dùng dịch vụ git.

Tác động và Vai trò của AI

Đáng chú ý, đây là một trong những lỗ hổng nghiêm trọng đầu tiên được phát hiện trong các tệp nhị phân closed-source nhờ sự hỗ trợ của AI. Wiz đã sử dụng công cụ IDA MCP để tự động hóa quá trình kỹ thuật ngược (reverse engineering), cho phép phân tích nhanh chóng các tệp nhị phân đã biên dịch của GitHub và tái tạo lại giao thức nội bộ.

Trên GitHub.com, lỗi này đã được khắc phục trong vòng 6 giờ sau khi báo cáo. Tuy nhiên, tình hình với GitHub Enterprise Server vẫn đáng báo động. Theo dữ liệu của Wiz, khoảng 88% các phiên bản GHES hiện hành vẫn chưa được cập nhật và dễ bị tấn công.

Khuyến nghị và Hành động cần thiết

• Đối với người dùng GitHub.com: Không cần thực hiện hành động nào vì GitHub đã áp dụng bản vá.
• Đối với quản trị viên GitHub Enterprise Server: Cần hành động ngay lập tức. Hãy nâng cấp phiên bản GHES lên 3.19.3 hoặc mới hơn để khắc phục CVE-2026-3854.

Sự kiện này là lời nhắc nhở mạnh mẽ về tầm quan trọng của việc kiểm tra kỹ lưỡng cách dữ liệu đầu vào của người dùng luân chuyển qua các giao thức nội bộ trong các kiến trúc đa dịch vụ.

"Một phát hiện có quy mô và mức độ nghiêm trọng như thế này là rất hiếm, mang lại một trong những phần thưởng cao nhất trong chương trình Bug Bounty của chúng tôi," - Alexis Wales, CISO của GitHub.

Các quản trị viên hệ thống được khuyến khích kiểm tra kỹ các bản cập nhật bảo mật mới nhất và đảm bảo môi trường của họ luôn được bảo vệ trước các mối đe dọa mới nổi.