Cảnh báo Copy Fail (CVE-2026-31431): Lỗ hổng kernel Linux nghiêm trọng dịp nghỉ lễ 30/4 – 1/5

Cảnh báo Copy Fail (CVE-2026-31431): Lỗ hổng kernel Linux nghiêm trọng dịp nghỉ lễ 30/4 – 1/5

Cập nhật: 01 tháng 5 2026

Đúng vào kỳ nghỉ lễ 30/4 – 1/5, một lỗ hổng kernel Linux cực kỳ nghiêm trọng vừa được công bố với tên gọi Copy Fail (CVE-2026-31431). Đây là lỗ hổng ảnh hưởng đến mọi kernel Linux từ năm 2017 đến nay và cho phép bất kỳ user thường nào trên server có thể leo lên quyền root chỉ bằng một đoạn Python 732 byte.

Tệ hơn, hiện tại chưa có patch chính thức từ các nhà phát hành Linux phổ biến. CloudLinux, AlmaLinux, RHEL đều đang gấp rút build và dự kiến 6-24 tiếng tới mới có. Trong khi đó, exploit công khai đã được công bố trên copy.fail kèm proof-of-concept hoàn chỉnh.

Nếu bạn vận hành shared hosting, VPS multi-tenant hoặc bất kỳ server nào có nhiều user shell, đây là kịch bản tệ nhất. Một website WordPress của khách bị hack, một user shared hosting bị compromise, là cả node có thể bị chiếm root.

Mức độ nguy hiểm

  • Mã CVE: CVE-2026-31431 (tên gọi: Copy Fail)
  • Loại lỗ hổng: Local Privilege Escalation (leo thang quyền cục bộ)
  • Module bị lỗi: algif_aead trong AF_ALG kernel crypto API
  • Phạm vi ảnh hưởng: Toàn bộ kernel Linux từ 2017 đến nay
  • Yêu cầu khai thác: Chỉ cần có shell access trên server (user thường, không cần quyền gì đặc biệt)
  • Kích thước exploit: 732 byte Python, đã có PoC công khai
  • Tình trạng patch: Chưa có patch chính thức cho production, dự kiến 6-24h tới

Tại sao lỗ hổng này nguy hiểm với hosting

Khác với lỗ hổng remote code execution, lỗ hổng leo thang quyền cục bộ thường bị đánh giá thấp hơn vì cần access ban đầu. Nhưng với hosting có shared environment, ranh giới này rất mỏng:

  1. Shared hosting: Mọi user trên cùng node đều có shell qua SSH/cPanel terminal/cron. Một user trong số hàng trăm khách hàng bị yếu mật khẩu, một website bị nhiễm web shell, là attacker đã có shell. Sau đó dùng Copy Fail để leo lên root toàn node.
  2. VPS có nhiều người dùng: Nhân viên, freelancer, contractor được cấp tài khoản. Một tài khoản bị lộ là toàn server toang.
  3. Container escape: Một số môi trường container chia sẻ kernel host. Lỗ hổng kernel có thể bị exploit từ trong container nếu cấu hình không chặt.
  4. Server có service tự động: Bất kỳ service nào chạy với user thường (www-data, nobody, mysql) bị RCE đều có thể chain với Copy Fail để biến thành full root compromise.

Cảnh báo: Workaround đang lan truyền KHÔNG hoạt động

Trên oss-security mailing list và một số forum đang lan truyền workaround dạng:

echo "install algif_aead /bin/false" > /etc/modprobe.d/cve-2026-31431.conf
rmmod algif_aead

Đây là workaround SAI và KHÔNG hoạt động trên CloudLinux, AlmaLinux, RHEL hay bất kỳ distro nào trong RHEL family. Lý do: module algif_aead được build sẵn vào kernel (CONFIG_CRYPTO_USER_API_AEAD=y), không phải module rời. Lệnh modprobe và rmmod chạy không lỗi nhưng hệ thống không thay đổi gì cả. Server vẫn vulnerable y nguyên trong khi sysadmin tưởng đã safe.

Verify module là built-in trên hệ thống của bạn:

modinfo algif_aead | grep filename
# Output: filename: (builtin)

Mitigation đúng cách (áp dụng ngay)

Cho đến khi patch kernel chính thức ra, cách duy nhất hiệu quả trên RHEL family là disable initcall của module algif_aead qua kernel boot parameter. Điều này ngăn module được register khi boot, đóng hoàn toàn attack surface.

Bước 1: Apply mitigation

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Bước 2: Verify sau khi reboot

sudo grubby --info=ALL | grep initcall_blacklist

Output phải có dòng initcall_blacklist=algif_aead_init trên kernel boot entry đang active.

Bước 3: Sau khi patch chính thức ra, revert

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Mitigation có break gì không?

Đây là điểm tốt của cách mitigation này: gần như không break gì trên web hosting bình thường. Cụ thể, các thành phần sau KHÔNG phụ thuộc vào AF_ALG nên hoàn toàn không bị ảnh hưởng:

  • dm-crypt và LUKS (mã hóa disk)
  • kTLS (kernel TLS)
  • IPsec, WireGuard, OpenVPN
  • SSH
  • OpenSSL và GnuTLS với build mặc định
  • HTTPS, TLS thông thường
  • MySQL, PostgreSQL, Redis encryption

Mitigation chỉ ảnh hưởng các ứng dụng explicit dùng AF_ALG cho AEAD ciphers, ví dụ: OpenSSL biên dịch với afalg engine bật, hoặc app dùng hardware crypto offload qua AF_ALG. Trên web hosting điển hình, các trường hợp này gần như không tồn tại.

Kết luận: bạn có thể apply mitigation ngay trên production mà không cần lo break gì.

Phương án nâng cao

Cho ai có KernelCare

KernelCare đang phát triển livepatch cho CVE này, bao phủ tất cả các distro được hỗ trợ. Khi livepatch ra, hệ thống sẽ tự nhận patch qua flow chuẩn kcarectl --update, áp dụng không cần reboot. Customer KernelCare không cần làm gì thêm.

Update từ KernelCare: first release cho AlmaLinux 9.6 FIPS đã đang trong review hôm nay, các distro khác đang active build/test. Đây là lựa chọn nhanh nhất nếu bạn không muốn reboot 2 lần.

Cho CloudLinux user

Phiên bản Có bị ảnh hưởng? Cách patch
CL7 Không Không cần làm gì
CL7h, CL8 CloudLinux kernel rebuild (vào beta channel cloudlinux-updates-testing trước, stable sau)
CL9, CL10 AlmaLinux kernel (đã có ở testing repo)

Với CL9/CL10, kernel đã có ở testing repo nếu bạn không muốn chờ stable:

  • CL9: kernel-5.14.0-611.49.2.el9_7 hoặc mới hơn
  • CL10: kernel-6.12.0-124.52.2.el10_1 hoặc mới hơn

Lưu ý: kernel testing chưa qua community verification, cân nhắc kỹ trước khi đưa lên production.

Cho ai có Imunify360

Imunify360 đã update để detect các indicators of compromise của CVE-2026-31431 cùng với heuristics mở rộng để phát hiện biến thể mới. Đây là layer phòng thủ thêm trong khi chờ patch kernel, không thay thế việc cập nhật kernel.

Hành động ngay trong dịp lễ

Đây là kịch bản kết hợp tệ nhất cho hosting: lỗ hổng kernel, exploit công khai, chưa có patch, đúng dịp nghỉ lễ dài. Hacker biết rõ thời điểm này dev và sysadmin đang nghỉ, monitoring không chặt.

Checklist tối thiểu cần làm trong tối nay hoặc sáng mai:

  1. Apply grubby mitigation trên tất cả các node có Linux kernel mới hơn 2017 (gần như là tất cả).
  2. Reboot rolling, mỗi node cách nhau 30 phút để duy trì service cho khách hàng.
  3. Verify mitigation đã active sau reboot bằng grubby --info=ALL | grep initcall_blacklist.
  4. Check status page CloudLinux và mailing list của distro đang dùng để biết khi nào patch stable ra.
  5. Tăng cường monitoring log, đặc biệt là login bất thường, process lạ chạy với user thường, file /tmp có execute bit.
  6. Sau khi patch chính thức ra (6-24h tới), upgrade kernel rồi revert mitigation.

Khuyến nghị dài hạn

  • Subscribe KernelCare cho tất cả production server. Chi phí 3-5 USD/server/tháng nhưng lần sau có CVE kernel tương tự, bạn không phải reboot và mất downtime nữa.
  • Subscribe Imunify360 nếu vận hành shared hosting. Layer detection IOC cho các CVE đời mới giúp giảm window of exposure.
  • Hạn chế user shell trên hosting node. Nếu có thể, disable SSH cho user shared hosting và chỉ cho phép qua SFTP. Mỗi shell user là một entry point cho local privilege escalation.
  • Cô lập tenant tốt hơn. Cân nhắc các giải pháp như CloudLinux LVE, namespaces, hoặc move workload nhạy cảm sang VPS riêng thay vì shared.
  • Có quy trình patch kernel khẩn. CVE kernel có exploit trong vài giờ là chuyện ngày càng thường. Quy trình rolling reboot trong 1-2h cho cả cluster là năng lực ops cần có.

TND.vn đã xử lý gì cho khách hàng

Đội ngũ kỹ thuật TND.vn đã apply grubby mitigation trên toàn bộ shared hosting node và các VPS được TND quản lý trong tối 30/4. Reboot rolling đã hoàn tất, service không gián đoạn. Khách hàng VPS tự quản trị, vui lòng tự áp dụng theo hướng dẫn ở trên.

Khi patch kernel chính thức ra, TND sẽ áp dụng tự động cho khách hàng managed hosting và thông báo lại trên blog này. Khách hàng cần hỗ trợ khẩn cấp trong dịp lễ liên hệ qua hotline kỹ thuật, email hoặc live chat trên tnd.vn.

Tài liệu tham khảo


Bài viết được cập nhật khi có thông tin mới về patch chính thức. Nếu thấy hữu ích, hãy share cho bạn bè đang làm sysadmin, devops hoặc đang vận hành hosting trong dịp lễ. Một bài share có thể cứu cả một cluster server cuối tuần này. Công đức vô lượng.