PHP vừa phát hành các bản vá khẩn cấp cho hai lỗ hổng thực thi mã từ xa không cần xác thực, CVE-2026-109618 và CVE-2026-109619, được gọi chung là PHP2Shell. Cả hai đều được chấm 9,2 theo CVSS v4.0 và nằm trong chính bộ máy PHP, vì vậy rủi ro không phụ thuộc vào việc ứng dụng đang chạy WordPress, Joomla, Drupal hay mã tùy biến.
Nhóm PHP xác nhận mọi kiểu triển khai phục vụ yêu cầu web đều có thể nằm trong phạm vi ảnh hưởng, gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. Rủi ro được đánh giá cao nhất với mod_php vì đã có phương thức khai thác cho phép yêu cầu chưa xác thực kích hoạt lỗi trước khi mã ứng dụng bắt đầu chạy.
PHP2Shell là gì?
PHP2Shell là tên gọi chung cho hai lỗi quản lý trạng thái và bộ nhớ trong quá trình PHP xử lý một yêu cầu web kết thúc bất thường. Thay vì xuất phát từ một plugin hoặc hệ quản trị nội dung cụ thể, lỗi nằm ở runtime được hàng triệu website sử dụng. Điều này làm phạm vi xử lý rộng hơn: quản trị viên phải kiểm tra phiên bản PHP thực tế trên từng máy chủ, container và dịch vụ được quản lý.
Cả hai lỗ hổng đều có thể dẫn tới thực thi mã với quyền của tài khoản web worker. Quyền này chưa chắc là root, nhưng thường đủ để đọc mã nguồn, lấy bí mật ứng dụng, truy cập cơ sở dữ liệu theo quyền đã cấu hình, sửa nội dung website hoặc tạo bàn đạp di chuyển trong hạ tầng.
CVE-2026-109618: hỏng bộ nhớ khi hết hạn mức
CVE-2026-109618 liên quan đến cách PHP xử lý tình trạng hết bộ nhớ. Một lỗi out-of-memory có thể ngắt quá trình khởi tạo khi dữ liệu nội bộ của yêu cầu mới chỉ hoàn thành một phần. Giai đoạn dọn dẹp sau đó có thể coi vùng dữ liệu chưa hợp lệ là cấu trúc hợp lệ, làm bộ nhớ bị hỏng và mở đường cho thực thi mã.
Điểm quan trọng là kẻ tấn công có thể tác động đến lượng bộ nhớ được tiêu thụ qua dữ liệu đầu vào HTTP. Vì lỗi xảy ra bên dưới tầng ứng dụng, việc cập nhật mã CMS hoặc kiểm tra quyền đăng nhập không loại bỏ nguyên nhân gốc.
CVE-2026-109619: trạng thái cũ sống lâu hơn bộ nhớ
CVE-2026-109619 là lỗi trạng thái toàn cục cũ. Một phần trạng thái thuộc về yêu cầu có thể còn tồn tại sau khi vùng nhớ phía dưới đã được giải phóng. Nếu cùng web worker tiếp tục xử lý một yêu cầu khác trước khi trạng thái được đặt lại bình thường, PHP có thể sử dụng tham chiếu đã hết hiệu lực.
Hệ quả có thể gồm use-after-free trên heap, rò rỉ bộ nhớ và cuối cùng là thực thi mã từ xa. Mô hình worker tái sử dụng trong máy chủ web khiến lỗi này đặc biệt đáng chú ý: một yêu cầu tạo điều kiện và một yêu cầu tiếp theo có thể cùng tham gia vào chuỗi khai thác.
Phiên bản đã vá và phạm vi cần kiểm kê
Các bản phát hành an toàn do dự án PHP công bố ngày 21/10/2026 là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Máy chủ đang dùng các nhánh tương ứng cần nâng cấp ít nhất lên những phiên bản này hoặc cài gói đã được nhà phân phối Linux hay nhà cung cấp LTS vá ngược.
PHP 8.1 trở xuống không còn được dự án chính thức hỗ trợ. Nhóm PHP vẫn cung cấp bản vá nguồn tối thiểu cho 7.4, 8.0 và 8.1 trong tình huống đặc biệt, nhưng hướng đi bền vững vẫn là chuyển sang nhánh còn hỗ trợ. PHP 8.2 cũng dự kiến kết thúc vòng đời vào ngày 31/12/2026, nên tổ chức đang dùng nhánh này cần lập kế hoạch nâng cấp tiếp thay vì dừng ở bản vá khẩn cấp.
Vì sao tường lửa ứng dụng không phải lời giải hoàn chỉnh?
Một số nhà cung cấp đã triển khai quy tắc WAF để chặn các mẫu khai thác đã biết. Tuy nhiên, nhóm PHP nhấn mạnh không có biện pháp giảm thiểu nào bảo vệ hoàn toàn. Quy tắc ở lớp HTTP chỉ nhận diện được những biểu hiện đã biết, trong khi nguyên nhân gốc nằm trong cơ chế quản lý bộ nhớ của runtime và đường khai thác có thể thay đổi.
WAF vẫn hữu ích như lớp giảm rủi ro tạm thời và nguồn telemetry để săn tìm yêu cầu đáng ngờ. Dù vậy, nó không nên được dùng làm lý do trì hoãn cập nhật PHP hoặc đưa một máy chủ chưa vá trở lại Internet.
Biện pháp tạm thời khi chưa thể cập nhật
Đối với CVE-2026-109618, cảnh báo chính thức đề xuất đặt memory_limit=-1 ở lớp mà ứng dụng không thể ghi đè, đồng thời giảm post_max_size và giới hạn kích thước yêu cầu tại proxy hoặc máy chủ web. Cách này loại bỏ một đường gây lỗi bộ nhớ có thể điều khiển, nhưng vẫn không ngăn được mọi tình huống cấp phát thất bại.
Đối với CVE-2026-109619, quản trị viên có thể tắt session.upload_progress.enabled rồi khởi động lại toàn bộ worker. Trên PHP 8.5, việc tắt fatal_error_backtraces cũng chặn một đường đã xác nhận. Các thiết lập này chỉ giảm bề mặt tấn công; bản vá vẫn là biện pháp khắc phục đầy đủ duy nhất.
Quy trình ứng phó ưu tiên cho quản trị viên
- Kiểm kê: liệt kê phiên bản PHP trên máy chủ vật lý, máy ảo, container, image CI/CD, môi trường dự phòng và dịch vụ do bên thứ ba quản lý.
- Ưu tiên hệ thống lộ Internet: xử lý trước các máy chủ dùng mod_php, cổng tải tệp, API nhận dữ liệu lớn và website có lưu bí mật giá trị cao.
- Cập nhật và khởi động lại: cài gói đã vá, restart toàn bộ worker rồi xác minh phiên bản mà tiến trình web thực sự đang sử dụng, không chỉ phiên bản CLI.
- Săn tìm dấu hiệu: rà soát yêu cầu bất thường, lỗi hết bộ nhớ, worker crash, tiến trình con lạ, tệp mới trong thư mục web và kết nối ra ngoài không thường lệ.
- Luân chuyển bí mật nếu cần: nếu có bằng chứng xâm nhập, cô lập máy chủ và thay khóa API, mật khẩu cơ sở dữ liệu, token phiên cùng thông tin xác thực mà tài khoản web có thể đọc.
Bài học phòng thủ từ một lỗi ở tầng runtime
PHP2Shell cho thấy quản lý lỗ hổng không thể dừng ở plugin và mã ứng dụng. Runtime, máy chủ web, thư viện hệ thống và image container đều là thành phần của bề mặt tấn công. Danh mục tài sản cần ghi được phiên bản đang chạy, nguồn gói, người chịu trách nhiệm và thời gian có thể triển khai bản vá.
Đối với CVE-2026-109618 và CVE-2026-109619, thứ tự hợp lý là cập nhật ngay, xác minh worker đã nạp bản mới, sau đó mới đánh giá các biện pháp phòng thủ bổ sung. Khi một lỗ hổng có thể xảy ra trước mã ứng dụng, chỉ sửa ứng dụng hoặc thêm chữ ký chặn không thể thay thế việc loại bỏ lỗi trong PHP.
VNCyberS tổng hợp từ PHP Security Team và BleepingComputer
Tiếng Việt
English