Nhân Linux có thể có lỗ hổng, nhưng nền tảng JFrog vẫn an toàn

Nhân Linux trên máy của bạn có thể bị phơi nhiễm và cần phải được vá để bảo vệ môi trường.

Chuyện gì đã xảy ra

Vào ngày 15 tháng 10, nhóm CVE của nhân Linux đã công bố CVE-2026-98432. Đây là một lỗi use-after-free trong mã thiết lập kết nối TCP IPv4 mới, do một điều kiện race gây ra. Lỗi này có từ nhân Linux 4.4. Upstream đã sửa vào ngày 5 tháng 10 sau khi chỉnh bản chính (main line) được vá vào ngày 17 tháng 9; upstream đã được sửa hoàn toàn 10 ngày trước khi CVE được công bố.

Nhóm kernel đánh giá lỗ hổng này 9.8 (điểm CVSS). Red Hat, Oracle, SUSE và Amazon đánh giá thấp hơn, nằm trong khoảng 5.9 đến 8.1.

Sau đó, Anthropic công bố nghiên cứu vào ngày 27 tháng 10 cho biết mô hình Claude của họ đã viết được một khai thác hoạt động. Một kẻ tấn công từ xa không cần chứng thực có thể có shell root trên các máy chủ có listener multipath TCP (MPTCP). Trong thử nghiệm của Anthropic, việc rò rỉ địa chỉ kernel mất 48 phút. Để đạt được thực thi lệnh chỉ mất thêm 5 phút nữa. Trong kịch bản này, một race thua cuộc chỉ làm mất kết nối đó, nên kẻ tấn công có thể thử lại.

Điều quan trọng là, Anthropic không công bố mã khai thác. Tính đến ngày 2 tháng 11, chưa có báo cáo nào về các cuộc tấn công trong thực tế. MPTCP không hẳn là công nghệ hiếm: từ Go 1.24, các chương trình Go yêu cầu MPTCP theo mặc định trên các socket chúng lắng nghe. Nhóm Bảo mật Go cũng cho biết lỗi nền tảng không đặc thù cho MPTCP. (Gợi ý: các triển khai JFrog bao gồm một số dịch vụ viết bằng Go với phiên bản > 1.24.)

Đối với khách hàng JFrog…

Trong triển khai tự quản lý, bạn chịu trách nhiệm về hệ điều hành nơi JFrog hoạt động. Chúng tôi chịu trách nhiệm về bảo mật sản phẩm của mình, còn bạn chịu trách nhiệm về nền tảng bên dưới (host, kernel, cập nhật) theo mô hình trách nhiệm chia sẻ. Một kernel dễ bị tấn công dưới một cài đặt JFrog tốt vẫn đặt host đó và mọi thứ trên nó vào rủi ro.

Tính đến ngày 30 tháng 10, cả Ubuntu lẫn RHEL đều chưa phát hành kernel đã sửa. Ubuntu 22.04 đến 26.10 được đánh dấu là đang tiến hành, và các bản phát hành cũ hơn rõ ràng vẫn dễ bị tấn công. RHEL 8, 9 và 10 được liệt kê là bị ảnh hưởng, không có ngày cụ thể. Debian, Oracle Linux, SUSE và Amazon Linux đã phát hành bản vá cho ít nhất một số kernel. Hãy kiểm tra chính xác bản phân phối và phiên bản của bạn vì mức độ bao phủ khác nhau giữa các distro.

Những việc chúng tôi khuyên bạn làm càng sớm càng tốt

1.     Xác định bạn đang chạy gì. Số phiên bản có thể gây hiểu nhầm, vì các distro thường backport bản vá mà không tăng số phiên bản. Hãy kiểm tra changelog thay vì chỉ nhìn version number.

Trên Debian hoặc Ubuntu:

 apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

Trên RHEL và các hệ sinh thái của nó:

 rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

Nếu lệnh không in ra gì, kernel đang chạy của bạn chưa có bản vá.

2.     Vá ở nơi đã có bản sửa, rồi khởi động lại. Cập nhật kernel không có tác dụng cho tới khi máy khởi động vào kernel mới. Nếu bạn tự build kernel, bản sửa nằm trong các phiên bản 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 và 7.3. Nhóm kernel khuyến nghị chuyển sang bản stable mới nhất thay vì chọn lẻ từng commit.
3.     Nơi chưa có bản sửa, hãy chủ động. Red Hat nói rằng hiện không có biện pháp giảm thiểu nào đáp ứng tiêu chuẩn của họ. Tắt MPTCP theo từng chương trình là giải pháp mong manh, và nhóm Go cũng nói rõ điều đó: chỉ cần một listener bị quên là bạn lại bị phơi nhiễm. Hạn chế ai có thể tiếp cận những host đó ở lớp mạng, theo dõi advisory của nhà phân phối cho CVE-2026-98432, và vá ngay khi gói có sẵn. Một lựa chọn giảm phơi nhiễm khác là dùng load balancer L7 hoặc reverse proxy với TCP termination để giảm việc tiếp xúc trực tiếp của host dễ bị tấn công. Giảm phơi nhiễm không sửa lỗi, nhưng giảm số người có thể thử khai thác lỗi đó.
4.     Làm cho lần sau đơn giản hơn. Nếu bạn proxy kho Debian hoặc RPM của mình qua Artifactory, kernel đã sửa sẽ xuất hiện trong repo mà các host của bạn đang lấy. Hãy stage, promote và rollout theo các giai đoạn, dùng cùng quy trình bạn dùng cho mọi thứ khác. Gói kernel là một artifact như bất kỳ artifact nào, và nên có hệ thống quản lý bản ghi.

JFrog Xray quét chuỗi cung ứng, artifact và image của bạn. Nó không thể cho biết kernel mà host của bạn đang chạy, vì kernel không nằm trong các artifact đó; bước một là lệnh bạn phải chạy thủ công.

Cửa sổ thời gian lớn, nhưng đang thu hẹp

Khi khoảng thời gian từ bản vá tới khai thác tiến gần về không, việc vá nhanh trở nên bắt buộc. Bản vá cho lỗ hổng này được đưa lên công khai vào ngày 5 tháng 10. Một bài báo về khai thác hoạt động xuất hiện vào ngày 27 tháng 10. Đến ngày 30 tháng 10, hai trong số các distro doanh nghiệp phổ biến nhất vẫn chưa có cập nhật.

Lời khuyên của chúng tôi để bảo vệ hệ thống của bạn rất đơn giản:

Chạy kiểm tra changelog trên mọi host đang chạy JFrog ngay hôm nay. Cập nhật và khởi động lại nơi đã có kernel đã sửa. Ở nơi chưa có bản sửa, hạn chế truy cập và theo dõi advisory của distro cho CVE-2026-98432 để bản vá không bị bỏ quên trong hàng đợi.

Lưu ý: Nội dung blog này được cung cấp cho mục đích thông tin và minh họa chung. Nó phản ánh thông tin có sẵn tại ngày xuất bản được ghi bên dưới và có thể không được cập nhật. Các ví dụ và kết quả mang tính minh họa; kết quả thực tế có thể khác tùy theo môi trường và trường hợp sử dụng của bạn. JFrog không tuyên bố hay bảo đảm rằng nội dung là đầy đủ, chính xác, hiện thời hoặc phù hợp cho hoàn cảnh cụ thể của bạn. Bạn chịu trách nhiệm đánh giá nội dung trước khi dựa vào nó. Nội dung blog này không sửa đổi bất kỳ thỏa thuận nào điều chỉnh việc sử dụng sản phẩm hoặc dịch vụ JFrog của bạn. Việc sử dụng sản phẩm vẫn chịu điều khoản trong Thỏa thuận Đăng ký JFrog hoặc các thỏa thuận bằng văn bản khác giữa bạn và JFrog.

Hành động khuyến nghị từ Softribution

Nếu bạn cần tư vấn chuyên sâu, kiểm tra môi trường hoặc triển khai các giải pháp vá, hãy liên hệ Softribution để được tư vấn kỹ thuật và cung cấp giải pháp phù hợp — bao gồm hỗ trợ quản lý bản vá, cấu hình proxy/reverse-proxy, hoặc tích hợp với quy trình quản lý artifact hiện có. Đội ngũ chuyên gia của Softribution sẽ giúp bạn đánh giá rủi ro, lập kế hoạch triển khai và thực hiện các bước cần thiết để giảm thiểu phơi nhiễm nhanh và an toàn.