Lỗ hổng PHP CVE-2026-109618 và CVE-2026-109619: bản vá, cách kiểm và cách cầm cự

Hai lỗ hổng trong lõi PHP cho phép kẻ tấn công chạy mã trên máy chủ chỉ bằng một request gửi tới website, không cần đăng nhập. Bản vá đã có từ 21/10/2026, và các hãng bảo mật đã ghi nhận những lần thử khai thác, nên website nào đang chạy PHP chưa vá thì nguy cơ là thật.

Bài này trả lời lần lượt bốn câu: website của anh chị có bị ảnh hưởng không, máy chủ đã vá chưa, chưa vá thì làm gì trong lúc chờ, và dấu hiệu nào trong log đáng soát.

Tóm lại trong 30 giây

• Đã vá phía PHP. Bản vá là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Website chỉ hết nguy cơ khi máy chủ thật sự chạy bản đã vá. Chưa nâng PHP thì lỗi vẫn còn nguyên trên máy chủ đó.
• Việc cần làm hôm nay. Biết máy chủ đang chạy PHP nào, nâng hoặc nhờ hosting nâng, rồi khởi động lại PHP-FPM hoặc Apache. Cập nhật gói mà chưa khởi động lại thì worker cũ vẫn chạy mã cũ.
• Mức khẩn. Critical, điểm CVSS v4.0 là 9.2 cho cả hai lỗi. Đã có lần thử khai thác, nhưng Sansec đánh giá ngày 22/10 rằng khai thác hàng loạt ít khả năng hơn dự đoán lúc mới công bố. Vẫn nên vá ngay, vì lỗi nằm trong PHP và không sửa được từ code website.

Website của tôi có bị ảnh hưởng không?

Có, nếu máy chủ chạy PHP chưa vá, bất kể website làm bằng WordPress, Laravel hay Magento. Lỗi nằm trong engine PHP nên code website sạch đến đâu cũng không chặn được, vì PHP xử lý request độc hại trước khi mã website bắt đầu chạy. Mức độ khác nhau theo cách PHP được gọi. Apache mod_php là cấu hình dễ dính nhất, vì advisory ghi đã khai thác thành công chạy mã từ xa trên mod_php với giới hạn mặc định. PHP-FPM, FrankenPHP và LiteSpeed LSAPI cũng nằm trong diện bị ảnh hưởng, mức chứng minh khai thác thấp hơn.

Đã có ai khai thác chưa?

Đã có lần thử. Theo bài FAQ của Tenable, Amazon Threat Intelligence ghi nhận một lần thử khai thác vào ngày 17/10, bốn ngày trước khi công bố, còn Cloudflare và watchTowr thấy các đợt tấn công từ ngày 21/10. Tính đến 22/10, CISA chưa đưa hai lỗi này vào danh mục KEV, và PHP cho biết đội bảo mật chưa tìm thấy exploit hoạt động lúc phát hành. Bản cập nhật ngày 22/10 của Sansec nói thêm rằng các PoC công khai không chạy được trên cài đặt PHP mặc định, và phần lớn cần website đích có sẵn một lỗi khác kiểu local file inclusion. Hai thông tin này không mâu thuẫn nhau: có người đang thử, nhưng chưa có một request đơn lẻ nào khai thác được mọi máy chủ.

Máy chủ của tôi đã vá chưa?

Đã vá khi PHP đang chạy bằng bản bằng hoặc cao hơn bản vá của đúng nhánh mình dùng.

Gói PHP của hệ điều hành và hosting thường vá bằng backport, nghĩa là số phiên bản vẫn thấp dù đã có bản sửa. Vì vậy đừng so số phiên bản để kết luận. Cách đúng là tìm mã CVE trong changelog của gói:

# RHEL, AlmaLinux, Rocky, CloudLinux
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
# Debian, Ubuntu
apt changelog php8.3-fpm | grep -E 'CVE-2026-(109618|109619)'

Thấy dòng chứa mã CVE nghĩa là gói đó đã vá. Không thấy thì hỏi hosting, bằng câu mẫu sau: “máy chủ của tôi đã cập nhật bản vá CVE-2026-109618 và CVE-2026-109619 chưa, và đang chạy bản PHP nào?”

Máy có thể chạy nhiều nhánh PHP song song, mỗi nhánh một master PHP-FPM riêng. Liệt kê chúng bằng lệnh dưới đây, rồi khởi động lại đúng từng master sau khi cập nhật.

ps aux | grep -E "php-fpm: master|apache2|httpd|litespeed|frankenphp" | grep -v grep

Hosting dùng CloudLinux hoặc cPanel

Theo trang trạng thái của CloudLinux lúc 01:19 UTC ngày 22/10, bản vá ea-php (cPanel EasyApache 4) đã vào kho stable từ 20:55 UTC ngày 21/10 cho ea-php52 tới ea-php85. Bản alt-php đã vào stable cho CloudLinux 7, 8, 9 và hoàn tất lúc 00:07 UTC ngày 22/10. PHP gốc của CloudLinux mới có bản stable cho 8.2 và 8.3 trên CloudLinux 9 và 8.2 trên CloudLinux 8, các bản còn lại đang ở testing.

Gói ea-php giữ số phiên bản thấp vì là backport: ea-php84 hiện là 8.4.26-2 chứ không phải 8.4.27, ea-php83 là 8.3.35-2. Metadata bảo mật chưa được công bố nên yum --security chưa liệt kê các gói này, anh chị cập nhật bằng lệnh thường:

# CloudLinux 7
yum clean all && yum update "ea-php*"
# CloudLinux 8, 9, 10
dnf clean all && dnf upgrade "ea-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Imunify360 ra ba bộ luật tường lửa ngày 21/10 (8.83 lúc 09:08 UTC, 8.84 lúc 13:07 UTC, 8.85 lúc 17:17 UTC) chặn các mẫu khai thác đã biết, nhưng trang CloudLinux ghi chưa có luật nào chặn đường hết bộ nhớ của CVE-2026-109618. Coi tường lửa là lớp phụ, không thay được bản vá.

Đang chạy PHP 8.1, 8.0, 7.4 hoặc cũ hơn

Ba nhánh 8.1, 8.0 và 7.4 không có bản phát hành chính thức. Anh chị có hai đường: nhận gói backport từ hosting hoặc nhà cung cấp hệ điều hành (CloudLinux, TuxCare, distro đang dùng), hoặc chuyển website sang nhánh còn được vá. Tự biên dịch mã backport được nhưng tốn công hơn nhiều so với chuyển nhánh. PHP 7.3 trở xuống đã hết vòng đời và không có bản vá từ PHP. Tenable dẫn khuyến nghị của CISA rằng hệ thống không vá được ngay, hoặc đang chạy PHP 8.1 trở xuống, nên tạm ngừng cho tới khi vá hoặc nâng cấp.

Chưa vá được ngay thì làm gì

Mọi cách dưới đây chỉ giảm rủi ro. Advisory của PHP ghi rõ cập nhật là cách duy nhất xử lý trọn vẹn.

1. Đặt session.upload_progress.enabled=0 trong php.ini, cấu hình pool FPM hoặc cấu hình server, rồi khởi động lại toàn bộ worker. Cách này chặn đường session đã xác nhận của CVE-2026-109619, không chặn các đường khác.
2. PHP 8.5: đặt thêm fatal_error_backtraces=0, bỏ nguồn sinh trạng thái của bản khai thác mod_php đã xác nhận.
3. Chặn request multipart/form-data ở nginx hoặc Apache khi website không dùng upload. Sansec lưu ý cách này làm hỏng chức năng tải ảnh, nên đặt thử một đơn hàng hoặc đăng một bài sau khi áp dụng.
4. Giữ post_max_size vừa phải, giới hạn số phần multipart, số header mỗi phần và số file upload, và giới hạn kích thước request đã giải mã ở frontend.
5. Cô lập website hướng ra internet nếu không vá được: chặn truy cập hoặc tạm đưa sau tường lửa ứng dụng.

Với CVE-2026-109618, advisory còn nêu memory_limit=-1 ở cấp quản trị. Tụi em không đặt cách này trên server dùng chung khi chưa có giới hạn thay thế, vì một script lỗi vòng lặp sẽ ăn hết RAM của cả máy. Nếu bắt buộc dùng, kèm giới hạn cgroup memory.max cho từng worker, và tuyệt đối không dùng RLIMIT_AS hay RLIMIT_DATA, vì hai giới hạn này làm mmap() thất bại đúng vào đường đang lỗi.

Hai lỗi này hoạt động thế nào

Cả hai lỗi cùng một khuôn: PHP bị ngắt giữa chừng một thao tác nhưng vẫn coi trạng thái dở dang là hợp lệ, rồi một đoạn mã sau đó đọc đúng vùng nhớ ấy. Kẻ tấn công sắp xếp lại bộ nhớ để biến lỗi đọc nhầm thành chạy mã, với quyền của tài khoản web: toàn bộ thư mục mã nguồn, file cấu hình chứa mật khẩu database và mọi thứ tài khoản đó ghi được.

CVE-2026-109618. PHP thoát khỏi lỗi hết bộ nhớ bằng lệnh longjmp(), nhảy thẳng ra khỏi ngữ cảnh mà không đi qua các bước dọn dẹp. Nếu việc đó xảy ra lúc bộ nhớ của request đã truy cập được nhưng chưa khởi tạo xong, bước kết thúc request sẽ đọc dữ liệu hỏng. Kẻ tấn công ép hết bộ nhớ bằng request multipart: header vô hạn trong một phần, file rỗng không tính vào max_file_uploads, hoặc request không khai độ dài hợp lệ để qua post_max_size.

CVE-2026-109619. PHP giữ nhiều biến toàn cục trỏ vào bộ nhớ của từng request. Nếu request kết thúc bất thường trước khi xoá chúng, request sau trên cùng worker có thể đọc lại con trỏ cũ, tức use-after-free. Hai đường đã xác nhận là cảnh báo lúc áp cấu hình INI và session upload progress, vốn bật mặc định và không cần website gọi session_start().

Dấu hiệu cần soát trong log

Advisory không hứa log sẽ lộ dấu vết, và không có dòng lỗi nào cũng chưa chắc là an toàn. Việc làm được là bật tạm log_errors=On, một error_log chạy được và error_reporting=E_ALL trong cấu hình khởi động, rồi tìm trong log Apache, PHP-FPM và proxy:

• Warning và deprecation lặp đi lặp lại trước khi script đích chạy.
• Lỗi fatal, parse error, uncaught error và dòng Maximum execution time exceeded.
• Một loạt request multipart bất thường tới cùng một địa chỉ, nhất là request không có độ dài nội dung hợp lệ.
• Tiến trình web sinh ra shell, file lạ trong thư mục upload hoặc file theme và plugin bị sửa.

Nếu đã thấy dấu hiệu lạ, đừng chỉ vá rồi bỏ đó: cập nhật xong còn phải quét mã độc, đổi mật khẩu database và khoá bí mật trong file cấu hình. Hướng đi từng bước nằm ở bài phát hiện và xử lý website dính mã độc và danh sách 14 dấu hiệu website bị hack.

Checklist 10 bước trong ngày

1. Liệt kê mọi nhánh PHP đang chạy trên máy, gồm cả nhánh cài song song cho một vài site.
2. Ghi lại cách chạy của từng nhánh: mod_php, FPM, LSAPI hay FrankenPHP. Mod_php xử lý trước.
3. Xếp từng nhánh vào nhóm có bản vá chính thức (8.2 tới 8.5) hay nhóm chỉ có backport (7.4, 8.0, 8.1).
4. Cập nhật bằng trình quản lý gói của hệ điều hành hoặc control panel, hoặc chuyển nhánh.
5. Khởi động lại đúng từng master: Apache, từng PHP-FPM, LiteSpeed.
6. Xác nhận bằng changelog gói, không dựa vào số phiên bản của gói backport.
7. Tắt session.upload_progress.enabled nếu code không dùng. Kiểm bằng grep -rn "upload_progress" trong thư mục mã nguồn.
8. Rà post_max_size, max_file_uploads, max_input_nesting_level và giới hạn kích thước request ở frontend.
9. Soát log lỗi PHP và web server theo các dấu hiệu ở mục trên.
10. Ghi ngày giờ và bản đang chạy của từng máy, để đợt vá sau không phải dò lại từ đầu.

Cả mười bước anh chị tự làm được nếu có quyền root và một cửa sổ bảo trì vài chục phút, không cần thuê ai.

Tụi em xử lý hạ tầng của mình theo thứ tự nào

Việc đầu tiên tụi em làm là đếm. Hạ tầng tụi em quản có ba nhánh PHP chạy song song, mỗi nhánh một master PHP-FPM riêng, trong đó có nhánh cũ nằm ngoài diện có bản phát hành chính thức. Đếm xong mới biết nhánh nào chỉ cần cập nhật gói, nhánh nào phải chuyển. Sau khi cập nhật gói, tụi em khởi động lại từng master một, vì lệnh restart của một dịch vụ không chạm tới hai master còn lại.

Chuyển nhánh PHP cho một website có rủi ro thật: theme và plugin viết cho PHP 7.4 có thể lỗi trên 8.x, nên tụi em thử trên bản sao trước rồi mới đổi pool. Nếu anh chị có nhiều website chạy nhánh không còn bản vá, hoặc không có thời gian kiểm từng máy, tụi em nhận xử lý theo dịch vụ chăm sóc website hoặc chuyển sang cloud VPS do tụi em quản trị. Gọi hotline 1900 636 648 và cho biết máy đang chạy nhánh PHP nào, dùng control panel nào, tụi em trả lời được ngay nhánh đó có bản vá chưa.

Đọc tiếp để dọn nốt phần còn lại của server

Vá PHP chỉ đóng một cánh cửa. Phần còn lại của việc giữ server nằm ở những bài này: server là gì và VPS là gì cho người mới quản máy, SSH là gì để ra lệnh an toàn, LiteSpeed Web Server nếu anh chị dùng LSAPI, tường lửa là gì và DDoS là gì cho lớp chặn phía trước, sao lưu dữ liệu website trước mỗi lần nâng cấp, bảo mật website và plugin bảo mật WordPress, công cụ quét mã độc, cách chọn mua hosting và danh sách nhà cung cấp hosting Việt Nam.

Nguồn

• GHSA-w8hw-w9fx-j79w, RCE via OOM corruption và GHSA-6wmf-4rv5-p3rp, RCE via stale global state, nhóm bảo mật PHP, công bố 21/10/2026.
• Trang trạng thái gói đã vá của CloudLinux, cập nhật 01:19 UTC ngày 22/10/2026.
• Tenable, FAQ về hai lỗ hổng, cập nhật 22/10/2026.
• Sansec, php2shell, cập nhật 22/10/2026.

Số liệu đối chiếu tới 23/10/2026. Trạng thái khai thác và trạng thái gói của từng nhà cung cấp còn đổi theo giờ, anh chị mở nguồn để xem bản mới nhất trước khi cập nhật.