PHP2Shell: hai lỗ hổng RCE trong lõi PHP bị khai thác từ trước khi có bản vá, mọi website PHP cần cập nhật ngay

Ngày 21/10/2026, nhóm phát triển PHP phát hành bản vá khẩn cho hai lỗ hổng nghiêm trọng trong lõi PHP, được giới bảo mật gọi chung là PHP2Shell: CVE-2026-109618 và CVE-2026-109619. Trong một số điều kiện, hai lỗi cho phép thực thi mã từ xa (RCE) mà không cần đăng nhập, ngay trước khi mã nguồn của website kịp chạy.

PHP là nền tảng của WordPress, Drupal, Joomla, Laravel, WooCommerce, Magento và phần lớn website trên Internet. Vì lỗi nằm ở chính PHP, cập nhật WordPress, theme hay plugin không vá được lỗ hổng này - phải cập nhật phiên bản PHP trên máy chủ.

Đã bị khai thác từ trước khi có bản vá

Theo Amazon Threat Intelligence, những lần thử khai thác đầu tiên xuất hiện từ ngày 17/10/2026, tức 4 ngày trước khi có bản vá, và tới nay lỗ hổng đang "bị khai thác rộng rãi". Nguyên nhân là một số chi tiết về lỗ hổng bị lộ ra ngoài trước ngày công bố, buộc nhóm PHP phải phát hành sớm hơn kế hoạch.

Tình hình tính tới ngày 22/10:

• Wordfence đã chặn hơn 74.000 lượt khai thác hoặc dò quét liên quan, nhưng chưa ghi nhận website nào bị chiếm quyền thành công.
• Dataminr đánh giá hoạt động hiện chủ yếu là dò quét và dùng các exploit chưa hoạt động, nhưng cảnh báo exploit hoạt động được sẽ sớm xuất hiện.
• Cloudflare cho biết kẻ tấn công đang liên tục sửa payload để tìm cách lách bộ lọc WAF.
• NCSC Anh khuyên cập nhật ngay, hoặc tạm tắt máy chủ PHP cho tới khi vá xong. CISA đưa ra khuyến nghị tương tự.

Chi tiết hai lỗ hổng

CVE-2026-109618 - Hỏng bộ nhớ khi hết bộ nhớ (out-of-memory)

Khi PHP hết bộ nhớ giữa chừng lúc đang xử lý request, một số dữ liệu nội bộ mới được khởi tạo một nửa. Ở bước dọn dẹp sau đó, PHP lại xử lý phần dữ liệu dở dang này như dữ liệu hợp lệ. Nhóm PHP đã xác nhận lỗi dẫn tới RCE không cần đăng nhập trên Apache mod_php. Với PHP-FPM, chuỗi khai thác cụ thể này bị chặn, nhưng FPM vẫn có thể bị ảnh hưởng trong các điều kiện khác.

CVE-2026-109619 - Tham chiếu tới vùng nhớ đã giải phóng

Khi một lỗi nghiêm trọng (fatal error) làm gián đoạn request, tiến trình PHP vẫn giữ tham chiếu tới vùng nhớ đã được giải phóng. Request tiếp theo đi vào cùng tiến trình đó có thể dùng lại các tham chiếu cũ. Lỗi liên quan tới tính năng theo dõi tiến độ tải file (session.upload_progress) và đã được xác nhận dẫn tới RCE trên cả mod_php lẫn PHP-FPM.

Điểm CVSS: NVD chấm cả hai lỗi 9.8; Red Hat chấm 8.1 vì đánh giá việc khai thác phức tạp hơn. Mã độc chạy với quyền của tiến trình web server.

Phạm vi ảnh hưởng: mọi máy chủ dùng PHP để phục vụ web - PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed - từ PHP 5.4 trở lên. Nhóm PHP đánh giá mod_php có rủi ro cao nhất.

Phiên bản cần cập nhật

PHP 8.1 trở về trước đã hết hỗ trợ. Nhóm PHP chỉ cung cấp bản vá mã nguồn tối thiểu cho 7.4, 8.0 và 8.1, nên nếu còn dùng các bản này, hãy hỏi nhà cung cấp hosting xem họ đã áp dụng bản vá chưa, hoặc lên kế hoạch nâng cấp.

Cần làm gì ngay?

1. Kiểm tra phiên bản PHP đang thực sự phục vụ website (không chỉ phiên bản dòng lệnh): xem trong panel hosting, hoặc tạo tạm một file phpinfo() rồi xóa ngay sau khi xem.
2. Cập nhật PHP lên một trong các bản ở bảng trên, hoặc gói PHP của nhà phân phối (Ubuntu, Debian, Red Hat, cPanel EasyApache, CloudLinux...) được xác nhận đã có cả hai bản vá.
3. Khởi động lại mọi tiến trình PHP (PHP-FPM, Apache) sau khi cập nhật. Nếu không, tiến trình cũ vẫn chạy mã lỗi.
4. Nếu dùng Docker, build lại image với bản PHP mới rồi triển khai lại.
5. Nếu dùng hosting dùng chung, liên hệ nhà cung cấp để xác nhận họ đã cập nhật.

Biện pháp tạm thời nếu chưa vá được

Các biện pháp dưới đây chỉ giảm rủi ro, không thay thế được bản vá:

• CVE-2026-109619: đặt session.upload_progress.enabled = 0 trong php.ini (file được nạp trước khi PHP phân tích request), rồi khởi động lại tiến trình PHP. Đặt qua ini_set() hoặc file .user.ini không có tác dụng. Trên PHP 8.5, đặt thêm fatal_error_backtraces = 0.
• CVE-2026-109618: giữ post_max_size ở mức hợp lý, upload_max_filesize nhỏ hơn post_max_size; giới hạn kích thước request, số phần multipart và số header ở web server hoặc reverse proxy.
• Chặn multipart/form-data ở web server, proxy hoặc WAF nếu website không cần tải file lên.
• Bật WAF: Cloudflare đã tự động bật 7 quy tắc chặn PHP2Shell cho cả gói miễn phí; gói trả phí cần kiểm tra các quy tắc này đang ở chế độ chặn. Wordfence, AWS và Microsoft cũng đã phát hành quy tắc tương ứng.

Dấu hiệu tấn công cần tìm

Theo phân tích của Wordfence, kẻ tấn công gửi request POST dạng multipart chứa trường PHP_SESSION_UPLOAD_PROGRESS kèm hàng trăm trường lặp lại để tạo áp lực bộ nhớ, rồi cố chạy lệnh để:

• đọc biến môi trường, file .env và wp-config.php;
• dò thông tin máy chủ bằng id, uname -a, hostname;
• ghi web shell có tên như wp2s.php vào thư mục uploads, plugin hoặc theme;
• tải payload tiếp theo bằng curl hoặc wget.

Một số chuỗi đánh dấu cần tìm trong log và file: P2S_OK, SHL_OK, NxSP kèm số, wp2s.php, php2shell.php, các file axiom_*.php. Ngoài ra, Wordfence còn thấy nhiều request lợi dụng cùng lúc để thử các chuỗi khai thác object serialization của Laravel, Monolog, Symfony, Guzzle.

Lưu ý: trường PHP_SESSION_UPLOAD_PROGRESS có thể xuất hiện hợp lệ, nên chỉ riêng trường này không chứng minh website đã bị tấn công. Hãy tìm thêm tiến trình PHP gọi shell, file PHP lạ mới xuất hiện, kết nối ra ngoài bất thường. AWS khuyên rà soát log từ ngày 17/10/2026.

Cập nhật PHP không gỡ được mã độc đã cài. Nếu phát hiện dấu hiệu bị xâm nhập, hãy dọn dẹp website, xóa web shell, và đổi toàn bộ mật khẩu database, khóa API, security keys trong wp-config.php cùng các thông tin trong file .env.

Nguồn tham khảo: BleepingComputer, Wordfence, Horizon3.ai và Cloudflare.