Ngày 15/10/2026, nhóm bảo mật Linux kernel công bố CVE-2026-98432, một lỗ hổng trong quá trình xử lý kết nối TCP/IPv4, được chấm 9,8/10 theo thang CVSS 3.1. Lỗi này có thể bị kích hoạt từ xa mà không cần đăng nhập. Ngày 27/10, Anthropic công bố một thử nghiệm trong đó mô hình Claude nội bộ tạo được chuỗi khai thác cho phép thực thi lệnh với quyền root trên máy chủ có Multipath TCP (MPTCP) listener, sau tổng cộng khoảng 53 phút. [1][2][3]
Một lỗi trong quá trình thiết lập kết nối TCP
TCP là giao thức truyền tải được sử dụng rộng rãi khi người dùng truy cập website, ứng dụng kết nối API hoặc các hệ thống trao đổi dữ liệu. Trước khi truyền dữ liệu, hai phía thiết lập kết nối bằng quá trình thường gọi là TCP three-way handshake. Công việc này do nhân hệ điều hành xử lý, trước khi yêu cầu được chuyển đến ứng dụng.
CVE-2026-98432 xuất hiện ở bước xử lý các yêu cầu kết nối TCP/IPv4. Theo Linux Kernel CVE Team, khi kernel tạo một socket mới, một số thông tin tùy chọn IPv4 được chuyển từ cấu trúc lưu yêu cầu kết nối sang socket đó mà không sao chép. Đồng thời, một CPU khác có thể vẫn đang đọc thông tin này để xử lý gói SYN gửi lại. [1]
Nếu vùng nhớ bị giải phóng khi CPU còn lại chưa đọc xong, kernel có thể truy cập vào địa chỉ bộ nhớ không còn hợp lệ. Đây là lỗi use-after-free (UAF): chương trình vẫn sử dụng dữ liệu sau khi vùng nhớ chứa dữ liệu đã bị giải phóng. Hậu quả có thể là lỗi bộ nhớ hoặc khiến hệ thống ngừng hoạt động; trong điều kiện khai thác phù hợp, UAF cũng có thể trở thành bước đầu của quá trình chiếm quyền thực thi.
Đáng chú ý, đường xử lý này nằm ở tầng kernel. Việc ứng dụng có đăng nhập, đã cập nhật thư viện hoặc không trực tiếp xử lý gói tin TCP không tự động loại bỏ một lỗ hổng nằm ở tầng hệ điều hành. Tuy nhiên, có thể kích hoạt lỗi qua mạng không đồng nghĩa với việc mọi dịch vụ TCP đều bị khai thác thành công theo cùng một phương pháp.
Từ lỗi bộ nhớ đến khả năng thực thi mã quyền root
Bản thân một lỗi UAF không bảo đảm kẻ tấn công chiếm được hệ thống. Để biến lỗi bộ nhớ thành khả năng thực thi mã, thường cần vượt qua các cơ chế bảo vệ và kiểm soát được chính xác vùng nhớ bị ảnh hưởng.
Trong nghiên cứu ngày 27/10, Anthropic cho biết một mô hình Claude nội bộ chưa phát hành đã xây dựng được chuỗi khai thác CVE-2026-98432 trên máy chủ Linux có Multipath TCP listener. MPTCP là phần mở rộng của TCP cho phép một kết nối logic đi qua nhiều đường truyền, ví dụ trên thiết bị có nhiều giao diện mạng. [3][5]
Anthropic mô tả hai giai đoạn khai thác. Trước tiên, lỗi bộ nhớ được dùng để làm rò rỉ thông tin địa chỉ kernel, qua đó vượt qua Kernel Address Space Layout Randomization (KASLR), cơ chế khiến vị trí mã và dữ liệu trong bộ nhớ khó dự đoán. Sau đó, chuỗi khai thác dùng cùng lỗi để làm thay đổi một con trỏ hàm và điều hướng việc thực thi, cuối cùng chạy lệnh do bên tấn công lựa chọn với quyền root. [3]
Trong thử nghiệm được công bố, giai đoạn làm rò rỉ một con trỏ kernel mất 48 phút; giai đoạn thực thi lệnh mất thêm 5 phút. Anthropic cũng cho biết khi một lần kích hoạt điều kiện cạnh tranh thất bại, quá trình kết nối có thể chỉ không hoàn tất thay vì khiến cả máy chủ sập, tạo cơ hội thử lại. Đây là kết quả do nhà nghiên cứu công bố, không phải một chiến dịch tấn công thực tế đã được xác nhận. [3]
Cần phân biệt phạm vi mã nguồn bị lỗi với phạm vi đã chứng minh khai thác. CVE nằm trong xử lý TCP/IPv4 của kernel, nhưng chuỗi thực thi lệnh quyền root mà Anthropic mô tả sử dụng MPTCP listener. Chưa có đủ bằng chứng công khai để khẳng định chuỗi khai thác tương tự hoạt động trên tất cả máy chủ chỉ dùng TCP thông thường. Tính đến ngày viết bài, các nguồn được đối chiếu chưa xác nhận CVE này bị khai thác trong tấn công thực tế ngoài môi trường nghiên cứu.
Linux đã có bản vá, vì sao Ubuntu vẫn bị ảnh hưởng?
Nhóm Linux Kernel CVE Team đã công bố bản sửa trong upstream kernel. Những nhánh stable được cập nhật bao gồm 5.15.223, 6.12.113, 6.18.56 và 7.2.10; các nhánh được duy trì khác cũng đã nhận bản vá. Thay đổi quan trọng là sử dụng cơ chế Read-Copy-Update (RCU) để trì hoãn việc giải phóng thông tin tùy chọn IPv4 cho đến khi các thao tác đọc liên quan có thể hoàn tất an toàn. [1]
Nhưng bản vá trong mã nguồn upstream không tự động trở thành bản cập nhật có thể cài đặt trên Ubuntu. Canonical duy trì các gói kernel riêng cho mỗi bản Ubuntu và nhiều biến thể dành cho hạ tầng cloud, phần cứng khác nhau. Các bản sửa cần được tích hợp, kiểm thử và phân phối qua hệ thống gói của Ubuntu.
Trong cơ sở dữ liệu CVE của Canonical, được đối chiếu ngày 30/10/2026, gói kernel linux thông thường cho Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS và 26.10 vẫn được đánh dấu Vulnerable với bản sửa đang trong quá trình xử lý. Một số phiên bản cũ hơn như 20.04 LTS cũng được đánh dấu có lỗ hổng. Các số phiên bản kernel package đang chuẩn bị không có nghĩa bản sửa đã phát hành đến người dùng. [2]
Khoảng cách thời gian này quan trọng với doanh nghiệp. Một mã nguồn đã được sửa và một máy chủ production đã chạy kernel an toàn là hai trạng thái khác nhau. Ubuntu cũng thường backport bản vá vào những nhánh kernel cũ, vì vậy chỉ so sánh số phiên bản kernel với upstream không đủ để xác nhận an toàn.
Ngay cả sau khi cài gói kernel có bản sửa, máy chủ có thể tiếp tục chạy kernel cũ cho đến lần khởi động lại. Việc xác minh phải kiểm tra cả gói được cài lẫn kernel đang thực sự chạy.
Doanh nghiệp nên xử lý thế nào khi bản vá chưa sẵn sàng?
Trong thời gian chờ bản vá chính thức, ưu tiên trước hết là kiểm kê hệ thống bị ảnh hưởng và đánh giá mức độ tiếp xúc với mạng không tin cậy. Danh sách cần bao gồm máy chủ Ubuntu, máy ảo, cloud instance, Kubernetes worker node và các dịch vụ công khai; container sử dụng kernel của host nên thay image ứng dụng không đồng nghĩa đã vá được kernel.
Lệnh uname -r cho biết kernel đang chạy, nhưng quản trị viên cần đối chiếu thêm tên và phiên bản package do Canonical cung cấp, kể cả linux-aws, linux-azure hay linux-gcp, với trang theo dõi CVE. Không nên giả định tất cả biến thể kernel có chung trạng thái bản vá.
Tiếp theo, rà soát dịch vụ đang lắng nghe TCP và giới hạn những cổng không cần công khai bằng firewall, security group hoặc phân đoạn mạng. Với hạ tầng sử dụng MPTCP, cần xác định có ứng dụng nào thực sự chạy MPTCP listener. Việc Linux hỗ trợ MPTCP không có nghĩa mọi kết nối đều sử dụng nó; nếu không có nhu cầu vận hành, doanh nghiệp có thể cân nhắc hạn chế MPTCP sau khi đánh giá tác động.
Tuy nhiên, tắt MPTCP không thể được xem là bản vá hoàn chỉnh: lỗi gốc nằm trong xử lý TCP/IPv4, và thử nghiệm được công bố chưa chứng minh mọi đường khai thác khác đều bị loại bỏ. Các biện pháp giới hạn truy cập chỉ giảm bề mặt tấn công trong thời gian chờ cập nhật.
Doanh nghiệp cần chuẩn bị lịch bảo trì, thử nghiệm kernel mới trên staging, kế hoạch rollback và khởi động lại theo nhóm máy chủ để giữ tính sẵn sàng dịch vụ. Khi Canonical phát hành bản sửa phù hợp, hãy triển khai, reboot và xác minh hệ thống thực sự chạy kernel mới. Hoàn tất cập nhật không chỉ là trạng thái gói phần mềm đã tải về.
Khi một bản vá bảo mật trở thành vấn đề vận hành
CVE-2026-98432 cho thấy một lỗi ở tầng hệ điều hành có thể ảnh hưởng đến nhiều ứng dụng không có lỗ hổng tương ứng trong mã nguồn của chúng. Nghiên cứu của Anthropic cũng cho thấy một mô hình AI có thể hỗ trợ xây dựng chuỗi khai thác phức tạp, dù một kết quả phòng thí nghiệm không đủ để suy luận về quy mô tấn công trong thực tế.
Điều được xác nhận là lỗi tồn tại trong Linux kernel, Anthropic báo cáo khai thác thành công trong môi trường thử nghiệm có MPTCP listener, và nhà phân phối cần thời gian đưa mã sửa upstream vào những gói kernel được hỗ trợ. Các kết quả đó đáng quan tâm, nhưng không nên biến thành tuyên bố rằng mọi máy Ubuntu mở TCP đều có thể bị chiếm quyền root. [1][2][3]
Đối với doanh nghiệp, bài học không dừng ở việc cập nhật Ubuntu khi có thông báo. Quản lý lỗ hổng cần liên kết hồ sơ kỹ thuật với danh sách tài sản, độ phơi nhiễm mạng, mức độ quan trọng của dịch vụ, thời gian cần để cập nhật và kết quả kiểm chứng sau reboot. Có như vậy mới quyết định được hệ thống nào cần bảo vệ trước, ngay cả khi bản vá chưa sẵn sàng.
Nguồn tham khảo
- [1]CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period Linux Kernel CVE Team · 2026-10-15
- [2]CVE-2026-98432 — Ubuntu security tracker Canonical · 2026-10-26 (checked 2026-10-30)
- [3]Discovering and exploiting vulnerabilities in critical, real-world software with Claude Anthropic · 2026-10-27
- [4]CVE-2026-98432 — vulnerability information Red Hat · accessed 2026-10-30
- [5]Multipath TCP Linux Kernel Documentation · accessed 2026-10-30




