CVE-2026-98432: Ubuntu và RHEL vẫn chưa có bản vá, còn một mô hình Claude thì đã viết xong mã khai thác

Hai sự thật về CVE-2026-98432 không hẳn ăn khớp với nhau. Đây là lỗi use-after-free trong quá trình bắt tay IPv4 TCP của nhân Linux, có thể tiếp cận qua mạng mà không cần đăng nhập và không cần tương tác, và nhóm CVE của nhân đã chấm điểm 9.8. Tính đến ngày 30 tháng 10 năm 2026, Ubuntu chưa phát hành bản vá nào cho 22.04, 24.04, 26.04 hay 26.10, còn Red Hat liệt kê RHEL 8, 9 và 10 là bị ảnh hưởng, không có bản vá và không có biện pháp giảm thiểu được khuyến nghị. Sự thật thứ hai là vào ngày 27 tháng 10, Anthropic đã công bố nghiên cứu cho biết một mô hình Claude chưa phát hành đã tạo ra bằng chứng khái niệm hoạt động cho việc chiếm quyền root từ xa không cần xác thực nhắm vào một máy chủ có trình lắng nghe MPTCP — khoảng 48 phút để rò rỉ một địa chỉ kernel và thêm năm phút nữa để thực thi lệnh.

Một lỗ hổng mà hai nhà cung cấp Linux doanh nghiệp lớn nhất vẫn chưa thể vá, với một exploit đang hoạt động được viết một phần bởi máy, không phải là một Patch Tuesday thông thường. Đây là trường hợp quyết định xem quy trình nâng cấp kernel và chính sách truy cập agent của bạn có liên quan gì đến nhau hay không.

Lỗi này, gói gọn trong một đoạn văn

Khi một kết nối TCP đang được thiết lập, các tùy chọn IP gắn với gói tin đến được chuyển cho socket mới thay vì được sao chép. Nếu quá trình bắt tay truyền lại, gói tin có thể được xử lý trên một CPU khác với CPU đang sở hữu bộ đệm tùy chọn — và CPU thứ hai đó có thể đọc vùng nhớ mà CPU thứ nhất đã giải phóng. Một cuộc đua tương tự cũng tồn tại trên đường di chuyển yêu cầu. Phạm vi bị ảnh hưởng bắt đầu từ kernel 4.4, nghĩa là hầu hết các máy vẫn đang chạy một kernel được duy trì. Bản vá upstream, commit code>e3f33b0a1d89/code>, trì hoãn việc giải phóng các bộ đệm tùy chọn cho đến khi không còn lõi nào khác có thể vẫn giữ tham chiếu.

Khả năng khai thác bắt nguồn từ cơ chế: không cần xác thực, không cần tương tác người dùng, một đường dẫn có thể truy cập qua mạng, và một cuộc đua có thể thử lại. Bản tóm tắt của chính Anthropic về lý do PoC khả thi chính là đặc tính đó — một cuộc đua thua chỉ làm hỏng một lần bắt tay thay vì làm sập máy, nên kẻ tấn công thử lại.

Ba nhà cung cấp, ba con số mức độ nghiêm trọng

Cách phân chia điểm chính là phần đáng để ghi nhớ, vì nó quyết định liệu scanner của bạn có mở một ticket trong tuần này hay không.

• Nhóm CVE Kernel — 9,8, mức nghiêm trọng. Có thể truy cập qua mạng, không yêu cầu đặc quyền, không cần tương tác.

• Red Hat — 8.1, Quan trọng. Quan điểm của công ty là cuộc đua này khó giành chiến thắng trên thực tế.

• Ubuntu — Ưu tiên cao, không có điểm số bằng số nào được công bố trên các trang đã kiểm tra.

Khoảng cách giữa 9.8 và 8.1 không phải là bất đồng về lỗi; mà là bất đồng về xác suất thắng một race. Cả hai đều có thể biện luận được, và khác biệt này có ý nghĩa về mặt vận hành: một mức 9.8 với PoC công khai là tình huống khẩn cấp, còn một mức 8.1 với race khó thắng là bản vá theo lịch. Cho đến khi ai đó công bố số liệu tái hiện trên phần cứng thực tế, cách hiểu trung thực là race này có thể thắng được, vì theo báo cáo, một mô hình tiên phong đã thắng nó.

Ai có giải pháp, và ai thì không

Tính đến ngày 29–30 tháng 10, tình hình không đồng đều theo cách đánh lừa những ai cho rằng kernel ổn định nghĩa là đã được vá.

• Debian 12 bookworm — đã sửa trong 6.1.190-1 qua DLA-4841-1.

• Debian 13 trixie — đã được sửa trong 6.12.113-1 qua DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — chưa có bản vá phát hành; đang được xử lý.

• Ubuntu 16.04, 18.04, 20.04 — dễ bị ảnh hưởng, chưa có bản vá nào được phát hành.

• RHEL 8, 9, 10 và OpenShift 4 — bị ảnh hưởng, không có bản sửa lỗi và không có biện pháp giảm thiểu nào được Red Hat chấp thuận.

• RHEL 6 và 7 — không bị ảnh hưởng.

• Amazon Linux 2023 — kernel 6.18 được báo cáo là đã được sửa; Oracle Linux UEK được báo cáo là đã được sửa; SUSE báo cáo rằng một số bản phát hành đã được sửa và những bản khác vẫn đang trong quá trình thử nghiệm, mà không nêu rõ phiên bản.

Các bản phát hành ổn định upstream có chứa bản sửa lỗi là 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 và 7.3 — đây là danh sách để đối chiếu với bản dựng của chính bạn nếu bạn tự biên dịch nhân thay vì dùng gói từ bản phân phối.

Tại sao MPTCP cứ liên tục được nhắc đến

Lỗ hổng này không phải là đặc thù riêng của MPTCP, và đây chính là chỗ mà nhiều bài đưa tin đã đi sai. Red Hat coi bất kỳ dịch vụ TCP nào có thể truy cập được là một yếu tố kích hoạt tiềm năng. Điều MPTCP cung cấp là một đường dẫn đã được chứng minh, còn thứ tạo ra lưu lượng là Go: phiên bản 1.24 trở lên bật TCP đa đường theo mặc định cho các socket lắng nghe trên Linux khi nhân hệ điều hành đã bật MPTCP. Nhóm bảo mật của Go đã cảnh báo về sự kết hợp này vào ngày 29 tháng 10.

Vì vậy, "tắt MPTCP" chỉ loại bỏ con đường mà Anthropic đã trình diễn, chứ không loại bỏ lỗ hổng. Đây là một biện pháp tạm thời có thể biện minh được, kèm một lưu ý cụ thể: nó đáng làm trên các dịch vụ Go ngay hôm nay, và nó không thay thế cho một kernel đã được vá.

Các bước kiểm tra ngắn gọn:

• code>ss -Mltnp/code> — liệt kê các socket hiện đang sử dụng MPTCP.

• code>net.mptcp.enabled/code> — liệu tính năng của kernel có được bật hay không.

• code>net.ipv4.tcp_migrate_req/code> — mặc định tắt; nếu bạn đã bật, hãy tắt lại.

Cụ thể đối với Go, code>GODEBUG=multipathtcp=0/code> khi chạy, hoặc một dòng code>godebug/code> trong code>go.mod/code>, sẽ khiến binary không sử dụng tính năng này.

Không có giải pháp nào trong số này được nhà cung cấp chứng thực. Red Hat nói thẳng rằng họ không có biện pháp giảm thiểu nào đáp ứng tiêu chuẩn của chính mình, một câu hữu ích hơn danh sách những giải pháp thay thế đầy hy vọng.

Anthropic thực sự đã công bố gì

Nghiên cứu này hẹp và cụ thể. Một mô hình Claude chưa phát hành, khi được cung cấp CVE và một mục tiêu có trình lắng nghe MPTCP, đã tạo ra một chuỗi làm rò rỉ địa chỉ kernel trong khoảng 48 phút và đạt được thực thi lệnh khoảng năm phút sau đó. Anthropic chưa công bố bản khai thác, và tính đến ngày 29 tháng 10, cả các nhà cung cấp lẫn hồ sơ CVE đều chưa báo cáo các cuộc tấn công ngoài thực tế; lỗ hổng này không nằm trong danh mục KEV của CISA. Vào ngày 30 tháng 10, một kho lưu trữ GitHub của bên thứ ba đã công bố công cụ thí nghiệm kích hoạt điều kiện race và rò rỉ bộ nhớ — một bộ khung tái tạo, dừng lại trước khi đạt tới thực thi mã đầy đủ.

Sự kết hợp đó mới là phần thú vị. Năng lực đã được chứng minh, vũ khí thì bị giữ kín, và chi tiết tạo nên khả năng đó — thuộc tính thử lại biến một race mong manh thành một race đáng tin cậy — lại được công bố công khai bằng lời văn. Giờ đây, bất kỳ ai có thể tái tạo race đều biết vì sao nó đáng để kiên trì theo đuổi.

Việc cần làm trong tuần này

• Vá và khởi động lại ở nơi có bản sửa lỗi. Bản sửa lỗi kernel được cài đặt nhưng chưa khởi động lại thì chưa phải là đã sửa; xác minh bằng code>uname -r/code>

• Khi bản phân phối của bạn chưa có bản vá — Ubuntu 22.04 đến 26.10, RHEL 8 đến 10 — hãy quyết định ngay bây giờ xem bạn sẽ dùng bản vá trực tiếp từ nhà cung cấp, chuyển sang một phiên bản đã được sửa lỗi, hay chấp nhận rủi ro với MPTCP bị tắt trên các dịch vụ Go.

• Hãy rà soát mức độ phơi lộ MPTCP thay vì cho rằng nó đang tắt. Giá trị mặc định đã thay đổi trong Go, chứ không phải trong cấu hình của bạn, và thay đổi đối với giá trị mặc định sẽ không hiển thị trong config diff.

• Hãy tập dượt việc khởi động lại. Loại sửa lỗi này cần khởi động lại toàn bộ, và những tổ chức sẽ mất nhiều thời gian nhất chính là những tổ chức phát hiện ra phương án chuyển đổi dự phòng của mình trong khung thời gian bảo trì.

Hai câu hỏi mà CVE này thực sự đặt ra

Điều thứ nhất liên quan đến việc tạo ra exploit, và nó không mang tính triết lý. Một mô hình đã tìm ra một chuỗi mà rất nhiều nhà nghiên cứu con người đã không tìm thấy, trên một mục tiêu có cấu hình cho phép cụ thể, trong vòng chưa đầy một giờ. Dù exploit có được công bố hay không, dòng thời gian đã thay đổi: khoảng thời gian giữa một bản khuyến cáo công khai và một exploit hoạt động được giờ đây được đo bằng tốc độ của những mô hình đọc chính bản khuyến cáo đó.

Điều thứ hai nói về ý nghĩa của việc vá lỗi khi các nhà cung cấp không thể vá. Bản phân phối cung cấp cho bạn một nhân và nhân có bản sửa lỗi không phải là cùng một đối tượng, và khoảng cách giữa chúng chính là nơi lỗ hổng này tồn tại đối với hầu hết độc giả của bài viết này. OrcaRouter AI Incident Archive lập chỉ mục các sự cố như thế này đối chiếu với nguồn sơ cấp, mức độ nghiêm trọng và độ tin cậy của chúng, đây là phiên bản của câu chuyện đáng giữ lại khi chu kỳ tin tức trôi qua.

Điều không nên làm là xếp việc này vào mục "chờ nhà cung cấp". Trang của chính nhà cung cấp nói rằng vẫn chưa có gì để chờ đợi.

Ghi chú nguồn: cơ chế, phạm vi bị ảnh hưởng từ kernel 4.4, commit thượng nguồn code>e3f33b0a1d89/code>, danh sách phiên bản ổn định và hướng dẫn giảm thiểu được lấy từ bản ghi CVE và các khuyến cáo của bản phân phối được đọc vào ngày 30 tháng 10 năm 2026. Các mức đánh giá 9.8, 8.1 và High của Ubuntu lần lượt thuộc về nhóm CVE của kernel, Red Hat và Canonical. Tình trạng bản vá theo từng bản phân phối được lấy từ DLA-4841-1 và DSA-6568-1 của Debian, các trang CVE của Red Hat và Ubuntu, cùng các tuyên bố của nhà cung cấp vào cùng ngày. Dòng thời gian proof-of-concept, các con số 48 phút và năm phút, và thuộc tính thử lại là nghiên cứu ngày 27 tháng 10 của Anthropic, nghiên cứu này đã giữ kín exploit. Kho lưu trữ phòng thí nghiệm ngày 30 tháng 10 được mô tả là của bên thứ ba và không phải của chúng tôi.