Lỗ hổng CVE nghiêm trọng: Jenkins bị tấn công thực thi mã

Lỗ hổng CVE nghiêm trọng: Jenkins bị tấn công thực thi mã
CLOUD HOSTING
DỊCH VỤ
VPS • CLOUD • SERVER
Hiệu năng cao
Ổn định • Bảo mật • Tốc độ
☁️
SSD NVMe 99.9% 24/7
TÌM HIỂU NGAY

Jenkins vừa công bố một lỗ hổng CVE nghiêm trọng, cho phép kẻ tấn công thực thi mã độc trên Jenkins controller thông qua việc bỏ qua bộ lọc bảo mật trong giao tiếp agent-to-controller.

Lỗ hổng bảo mật trong Jenkins

Lỗ hổng này, được theo dõi dưới mã định danh CVE-2026-70426, ảnh hưởng đến các phiên bản Jenkins sử dụng thư viện Remoting không an toàn. Mức độ nghiêm trọng của lỗ hổng này được đánh giá là Critical theo thang điểm CVSS.

Cụ thể, lỗ hổng này tác động đến Jenkins 2.575 trở về trướcJenkins LTS 2.568.1 trở về trước. Vấn đề tồn tại trong các phiên bản Remoting 3384.v60d89463d9e0 và cũ hơn, ngoại trừ phiên bản 3355.3357.v931d3c992987.

Cách thức hoạt động của lỗ hổng

Jenkins sử dụng thư viện Remoting, thường được phân phối dưới dạng agent.jar hoặc remoting.jar, để thiết lập kênh giao tiếp giữa controller trung tâm và các build agent được kết nối. Các giao tiếp này dựa trên việc tuần tự hóa (serialization) các đối tượng Java.

Do các lỗi liên quan đến quá trình giải tuần tự hóa Java có thể dẫn đến thực thi mã tùy ý, Jenkins áp dụng bộ lọc lớp JEP-200 khi xử lý các đối tượng được gửi qua kênh Remoting. Bộ lọc JEP-200 này được thiết kế để hạn chế các lớp tiềm ẩn nguy hiểm không được giải tuần tự hóa bởi Jenkins controller.

Tuy nhiên, các nhà nghiên cứu đã phát hiện ra rằng bộ lọc này không được áp dụng khi các lớp được phân giải thông qua một fallback path trong quy trình giải tuần tự hóa của Remoting. Điều này tạo ra một kẽ hở cho phép bỏ qua bộ lọc.

Một kẻ tấn công kiểm soát tiến trình agent, chiếm được quyền thực thi mã trên một agent hiện có, hoặc sở hữu quyền Jenkins Agent/Connect có thể khai thác lỗ hổng này để giải tuần tự hóa các lớp Java nhất định mà lẽ ra đã bị chặn.

Tác động của việc khai thác thành công

Việc khai thác thành công có thể cho phép mã độc chạy trên Jenkins controller, hệ thống thường là nhạy cảm nhất trong môi trường Jenkins. Tác động này giới hạn ở các lớp đã có sẵn trên classpath của Jenkins core, bao gồm các lớp đi kèm với Jenkins và các lớp thuộc nền tảng Java.

Các phụ thuộc được đóng gói trong plugin không được giải tuần tự hóa thông qua fallback path bị ảnh hưởng, do đó làm giảm bề mặt tấn công tổng thể. Tuy nhiên, việc thực thi mã ở cấp độ controller vẫn tiềm ẩn rủi ro nghiêm trọng. Một controller bị xâm phạm có thể làm lộ mã nguồn, thông tin bí mật, thông tin xác thực build, khóa triển khai và các pipeline chuỗi cung ứng phần mềm.

Khắc phục và biện pháp phòng ngừa

Jenkins đã khắc phục lỗ hổng này trong thông báo bảo mật SECURITY-3911 với các phiên bản Jenkins 2.576Jenkins LTS 2.568.2. Các bản phát hành này cập nhật thư viện Remoting để đảm bảo bộ lọc JEP-200 được thực thi ngay cả khi sử dụng fallback deserialization path.

Các tổ chức nên cập nhật Jenkins controllers và agents lên các phiên bản đã được vá lỗi càng sớm càng tốt. Đội ngũ an ninh mạng cũng cần xem xét kỹ lưỡng những người dùng, tài khoản dịch vụ và hệ thống nào đang nắm giữ quyền Agent/Connect, vì quyền truy cập này có thể được sử dụng như một phần của lộ trình khai thác.

Các build agent không đáng tin cậy nên được cách ly, giám sát và ngăn chặn truy cập vào các tài nguyên nội bộ nhạy cảm. Lỗ hổng này được báo cáo thông qua Chương trình Thưởng lỗi Jenkins của Ủy ban Châu Âu.

Đối với các môi trường không thể cập nhật ngay lập tức, Jenkins đã công bố một giải pháp tạm thời trên kho lưu trữ GitHub SECURITY-3911-3930. Quản trị viên nên áp dụng biện pháp giảm thiểu này một cách cẩn thận và coi nó như một biện pháp tạm thời cho đến khi có thể triển khai các phiên bản Jenkins đã vá lỗi.

Tham khảo thêm thông tin chi tiết về lỗ hổng này tại Jenkins Security Advisory SECURITY-3911.