Hai lỗ hổng Linux kernel vào KEV: Máy chủ cần cập nhật sớm
CISA xác nhận CVE-2025-39964 và CVE-2026-53266 trong Linux kernel đã bị khai thác. Máy chủ dùng chung, host container và hệ thống bridge nên kiểm tra, cập nhật sớm.
Bởi Võ Danh — 19 Tháng 9, 2026 trong Bảo mật
Hai lỗ hổng Linux kernel, CVE-2025-39964 và CVE-2026-53266, vừa được CISA đưa vào danh mục KEV vì đã có bằng chứng bị khai thác thực tế. Đây không phải kiểu lỗi chỉ cần mở một cổng Internet là bị chiếm máy ngay. Cả hai chủ yếu cần kẻ tấn công đã có chỗ đứng cục bộ hoặc quyền phù hợp. Nhưng trên máy chủ dùng chung, máy chạy container và hạ tầng cho phép mã không tin cậy hoạt động, “đã vào được một chân” đôi khi là quá đủ để gây chuyện.
CISA công bố cảnh báo ngày 18/9/2026. Cơ quan này chưa nêu chiến dịch, nhóm tấn công hay chỉ dấu xâm nhập cụ thể. Vì vậy, điều chắc chắn có thể nói là hai lỗi đã bị khai thác; chưa có cơ sở để gắn chúng với ransomware hoặc khẳng định mọi máy Linux đều đang bị nhắm tới.
Hai lỗ hổng Linux kernel làm được gì?
CVE-2025-39964 là lỗi tranh chấp trong giao diện mã hóa AF_ALG. Khi hai luồng cùng ghi vào một socket AF_ALG, dữ liệu có thể bị trộn và trạng thái bên trong socket trở nên không nhất quán. Mô tả của Linux, Ubuntu, Debian và Red Hat đều xác nhận vấn đề nằm ở af_alg_sendmsg. Kịch bản công khai cần quyền truy cập cục bộ; hậu quả rõ nhất là làm hệ thống hoạt động bất thường hoặc mất ổn định.
CVE-2026-53266 nằm ở netfilter bridge/ebtables khi SNAT sửa địa chỉ phần cứng của gói ARP. Trong một cấu hình cụ thể, kernel có thể ghi vào trang nhớ dùng chung hoặc trang được ánh xạ từ tệp. Red Hat đánh giá lỗi ở mức Important và cho biết kẻ tấn công cục bộ có thể gây hỏng bộ nhớ, từ chối dịch vụ hoặc có khả năng nâng quyền. Lỗi này không mặc nhiên ảnh hưởng theo cùng một mức cho mọi máy: hệ thống phải dùng đường xử lý bridge netfilter và quy tắc ebtables SNAT liên quan.
Nói ngắn gọn, đây là hai mắt xích sau xâm nhập hơn là cửa chính mở toang. Đừng vì thế mà xếp chúng cuối hàng. CISA chỉ thêm lỗ hổng vào KEV khi có bằng chứng khai thác, còn máy chủ nhiều người dùng và host container vốn là nơi lỗi cục bộ dễ trở thành bàn đạp.
Ai nên ưu tiên kiểm tra?
- Máy chủ cho nhiều người dùng đăng nhập, máy build CI/CD và môi trường chạy mã do khách hàng hoặc đối tác cung cấp.
- Host container, nền tảng ảo hóa và máy biên có bật bridge networking, ebtables hoặc quy tắc sửa ARP.
- Thiết bị Linux khó cập nhật, kernel tùy biến hoặc máy đã lâu không khởi động lại sau khi cài gói kernel mới.
Máy tính cá nhân vẫn nên cập nhật, nhưng không cần hoảng rồi tắt sạch dịch vụ giữa giờ làm. Việc đầu tiên là xác định kernel đang chạy bằng uname -r, đối chiếu với trang bảo mật của đúng bản phân phối và kiểm tra xem gói kernel mới đã được cài nhưng chưa được nạp hay chưa.
Cách xử lý an toàn
- Cập nhật kernel từ kho chính thức của Ubuntu, Debian, Red Hat, SUSE hoặc nhà cung cấp thiết bị. Không lấy một con số phiên bản upstream rồi kết luận máy đã vá, vì nhà cung cấp có thể backport bản sửa.
- Lên lịch khởi động lại nếu bản vá yêu cầu, sau đó kiểm tra lại kernel đang chạy. Cài xong nhưng vẫn chạy kernel cũ thì bản vá mới chỉ nằm trên đĩa, khá chăm chỉ nhưng chưa giúp được gì.
- Nếu chưa thể cập nhật, rà việc sử dụng AF_ALG và bridge ebtables. Với CVE-2025-39964, Red Hat nêu phương án ngăn module
af_algđược nạp khi chức năng này không cần thiết. Với CVE-2026-53266, có thể tạm bỏ quy tắc ebtables SNAT sửa ARP nếu môi trường không phụ thuộc vào nó. Hãy thử thay đổi trước vì đây là chức năng mạng cấp thấp. - Rà các lần kernel panic, crash bất thường, thay đổi quy tắc netfilter và hoạt động lạ từ tài khoản hoặc container ít quyền. Hiện chưa có IOC dùng chung được CISA công bố, nên một truy vấn log duy nhất không thể chứng minh máy sạch.
Nếu đội IT đang xử lý nhiều cảnh báo cùng lúc, nên ưu tiên theo phơi nhiễm thật: máy nhiều người dùng và host container trước, máy trạm đơn lẻ sau. Cách làm này cũng hợp với nguyên tắc trong bài CVE-2026-76460 trên Cisco ISE: kiểm kê đúng tài sản, giảm bề mặt tấn công rồi vá, thay vì vá theo tiếng chuông to nhất.
Nguồn kiểm chứng
