php2shell: Hai lỗ hổng PHP nghiêm trọng và nên vá gì trước

CVE-2026-109618 và CVE-2026-109619 là gì?

PHP phát hành bản vá ngày 21/10/2026 cho hai lỗi nghiêm trọng mà cộng đồng gọi là php2shell. Đội bảo mật PHP chấm cả hai ở mức CVSS v4.0 9.2 và cho biết chúng có thể cho phép thực thi mã từ xa mà không cần xác thực.

CVE-2026-109618 là lỗi liên quan đến hết bộ nhớ. PHP dùng longjmp() để hủy một request khi bộ nhớ cạn. Trong một số ngữ cảnh, bộ nhớ của request vẫn có thể truy cập được trước khi được khởi tạo đầy đủ, nên bước dọn dẹp có thể coi dữ liệu không hợp lệ là hợp lệ.

CVE-2026-109619 là lỗi trạng thái cũ. Trạng thái thuộc request có thể vẫn được công bố sau khi vùng nhớ của request đã được giải phóng. Một thao tác sau đó trên cùng worker có thể đọc trạng thái này trước khi nó được khởi tạo lại.

Sansec mô tả CVE-2026-109618 theo cách khác: đó là lỗi use-after-free trong bộ xử lý upload-progress, có thể trả bộ nhớ đã giải phóng của worker về client trong cookie PHPSESSID. Bài viết này theo mô tả của PHP.

Phiên bản PHP nào bị ảnh hưởng và đã được vá?

Bản phân tích kỹ thuật của Calif cho thấy đường đi bị ảnh hưởng sớm nhất nằm ở PHP 5.4.0. Các bản đã sửa là 8.5.12, 8.4.27, 8.3.36 và 8.2.35.

PHP không phát hành bản chính thức cho các nhánh đã hết hỗ trợ. Đội bảo mật PHP có đưa ra bản backport tối thiểu từ mã nguồn cho PHP 7.4 đến 8.1. Nếu bạn đang chạy nhánh cũ hơn, hãy hỏi nhà cung cấp về gói đã vá hoặc lên kế hoạch chuyển sang phiên bản được hỗ trợ. Kiểm tra phiên bản của file thực thi PHP đang phục vụ request trên từng máy chủ, vì danh sách gói và file đang chạy có thể khác nhau sau một lần nâng cấp chưa hoàn chỉnh.

Có đang bị khai thác không?

Có dấu hiệu khai thác thực tế. Amazon Threat Intelligence ghi nhận một nỗ lực khai thác vào ngày 17/10, bốn ngày trước khi công bố. Amazon nói php2shell hiện đang bị khai thác rộng rãi trên thực tế.

PHP thận trọng hơn. Đội ngũ của PHP đã xem xét các mã PoC xuất hiện sau khi thông tin bị lộ và chưa xác định được exploit hoạt động tại thời điểm phát hành. Cloudflare ghi nhận các cuộc tấn công sớm lúc 07:43 UTC ngày 21/10, trước bản phát hành lúc 14:00 UTC của PHP. Amazon cho biết có thêm nhiều nỗ lực vào ngày 21/10, với payload và hạ tầng cho thấy có nhiều tác nhân khác nhau. Amazon cũng nói chưa rõ liệu có nỗ lực nào trong ngày 21/10 thành công trên hệ thống thực hay không.

Sansec dự đoán sẽ có khai thác hàng loạt khi bản vá và chi tiết kỹ thuật đã công khai. Bản vá đã có cho các nhánh PHP 8.x được hỗ trợ, và các nỗ lực khai thác bắt đầu trước khi công bố. Theo cách hiểu thực tế, hãy coi ngày 17/10 là điểm bắt đầu của khoảng thời gian cần rà soát. Amazon khuyến nghị bắt đầu điều tra từ ít nhất ngày đó, không phải từ ngày công bố.

Ứng dụng nào bị ảnh hưởng?

Calif đã cho thấy kẻ tấn công không cần đăng nhập vẫn có thể chạy mã trên Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 và WHMCS.

Đây là danh sách các ứng dụng đã thử nghiệm, không phải danh sách đầy đủ. Sansec lưu ý rằng lỗi nằm trong lõi PHP, nên các cửa hàng vẫn bị ảnh hưởng dù mã của chính họ sạch. Hãy kiểm tra mọi máy chủ chạy PHP, kể cả môi trường staging và công cụ nội bộ.

Tuần này nên làm gì?

Trước hết, lập danh sách mọi máy chủ phục vụ PHP. Ghi lại phiên bản PHP và cách PHP chạy trên từng máy, là PHP-FPM, Apache mod_php hay php-cgi, vì mức rủi ro khác nhau theo cấu hình. Sau đó cập nhật PHP lên bản đã vá, hoặc cài gói đã vá của nhà cung cấp. Vá là cách khắc phục. Các bước khác chỉ giảm mức phơi nhiễm trong lúc chờ vá.

Nếu chưa thể vá ngay, Calif đã đưa ra hai biện pháp giảm thiểu một phần: tắt theo dõi tiến trình upload trong session và bỏ giới hạn bộ nhớ. Sansec cũng nêu một quy tắc web server chặn các request multipart/form-data, nhưng quy tắc này làm hỏng upload file, nên hãy đặt thử một đơn hàng hoặc upload ảnh sản phẩm sau khi thêm quy tắc. Nếu buộc phải ngừng site, hãy dừng PHP-FPM và để web server hiển thị trang bảo trì tĩnh. Chế độ bảo trì của Magento và WordPress không giúp được, vì PHP phân tích từng request trước khi ứng dụng kiểm tra cờ bảo trì.

Banyard cảnh báo rằng chỉ tắt theo dõi tiến trình upload thì chưa đủ, nên hãy kết hợp các cài đặt với các bước khác. Sau đó hãy xem nhật ký từ ngày 17/10 trở đi, không chỉ từ ngày 21/10. Sansec cho biết mọi trigger đã biết đều là request multipart/form-data, nên hãy bắt đầu với các request mang loại nội dung đó và đến được PHP. Tìm mã trạng thái bất thường trên các request này, file mới trong thư mục upload hoặc thư mục web, và tiến trình do người dùng web server khởi chạy mà bạn không nhận ra.

Nếu phát hiện dấu hiệu bị xâm nhập, hãy coi máy chủ đó là đã bị xâm phạm. Thay toàn bộ thông tin bí mật mà nó giữ, gồm mật khẩu cơ sở dữ liệu, khóa API và khóa riêng TLS, vì rò rỉ bộ nhớ có thể làm lộ bí mật của các request khác.

Kẻ tấn công có thể tiếp cận những gì?

Sansec cho biết CVE-2026-109618 cũng tự rò rỉ bộ nhớ, tương tự Heartbleed. Bộ xử lý upload-progress chạy trước mã ứng dụng, nên việc rò rỉ không phụ thuộc vào những gì ứng dụng của bạn làm. Bộ nhớ đó có thể chứa mật khẩu, session token, khóa API và khóa riêng TLS từ các request khác.

Với người vận hành, điều này có nghĩa rủi ro không chỉ giới hạn ở ứng dụng bị tấn công. Mọi bí mật đi qua cùng một PHP worker đều có thể bị lộ, nên hãy đổi thông tin xác thực trên các máy đã có thể truy cập trước khi bạn vá.

Các nguồn mâu thuẫn ở điểm nào?

Ba điểm khác nhau giữa các nguồn. Sansec mô tả CVE-2026-109618 là use-after-free trong upload-progress, còn PHP gọi nó là lỗi hết bộ nhớ (out-of-memory). Quỹ PHP (PHP Foundation) cho biết các định danh CVE bị rò rỉ trước khi phát hành mang điểm CVSS 10.0, trong khi điểm chính thức là 9.2. Amazon và Sansec cho rằng khai thác đang diễn ra rộng rãi, còn PHP chưa xác định được exploit hoạt động tại thời điểm phát hành. Hãy kiểm tra lại các điểm này khi có báo cáo mới.

Người đọc hỏi nhiều nhất điều gì về php2shell?

Ứng dụng sạch có bảo vệ được tôi không?

Không. Lỗi nằm trong lõi PHP, nên các cửa hàng chạy Magento, Shopware hoặc WooCommerce vẫn bị ảnh hưởng dù mã của họ sạch.

Tắt theo dõi tiến trình upload trong session có khắc phục được không?

Không. Đó chỉ là biện pháp giảm thiểu một phần. Banyard cảnh báo rằng riêng biện pháp này là chưa đủ, nên hãy cập nhật PHP lên bản đã sửa.

Phiên bản PHP nào đã có bản vá?

PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 là các bản đã sửa. Các nhánh 7.4 đến 8.1 có backport tối thiểu từ mã nguồn, còn các nhánh cũ hơn không có bản chính thức.