Bản Vá Khẩn PHP 21/10/2026: 2 Lỗ Hổng RCE CVE-2026-109618 & 109619

Tối 21/10/2026 (giờ Việt Nam), đội ngũ bảo mật PHP đã phát hành bản cập nhật khẩn cấp 8.5.12, 8.4.27, 8.3.36 và 8.2.35 nhằm vá hai lỗ hổng thực thi mã từ xa không cần xác thực (unauthenticated RCE) là CVE-2026-109618 và CVE-2026-109619, cùng có điểm nghiêm trọng CVSS v4.0 là 9.2. Mọi doanh nghiệp đang vận hành website, API, hệ thống thương mại điện tử hoặc phần mềm quản lý trên nền tảng PHP cần cập nhật bản runtime PHP và khởi động lại các tiến trình xử lý ngay lập tức, vì hai lỗi này nằm ở tầng lõi PHP và không thể khắc phục bằng cách sửa code ứng dụng.

Trước đó vào ngày 20/10/2026, nhóm bảo mật PHP đã thông báo trước về đợt phát hành khẩn cấp này (dự kiến lúc 14:00 UTC, tức 21:00 giờ Việt Nam ngày 21/10) để các quản trị viên hệ thống và nhà cung cấp hạ tầng chuẩn bị. Trong thông báo chính thức ngày 21/10/2026, PHP nhấn mạnh: tất cả người dùng PHP được khuyến cáo mạnh mẽ phải cập nhật ngay lập tức ("All PHP users are strongly encouraged to update immediately"). Bài viết này tóm tắt chính xác các thông tin đã xác thực để các founder, chủ doanh nghiệp và đội ngũ kỹ thuật rà soát hệ thống ngay trong hôm nay.

Hai lỗ hổng CVE-2026-109618 và CVE-2026-109619 là gì?#

Unauthenticated Remote Code Execution (RCE không cần xác thực) là loại lỗ hổng cho phép kẻ tấn công từ xa thực thi mã lệnh tùy ý trên máy chủ mục tiêu mà không cần tài khoản đăng nhập hay quyền truy cập hợp lệ trước đó.

Ở góc độ vận hành doanh nghiệp, khi một lỗ hổng RCE nằm ngay trong trình thông dịch PHP, mọi lớp bảo mật viết trong ứng dụng (như middleware xác thực của Laravel, plugin bảo mật của WordPress hay phân quyền trong Magento) đều có thể bị vượt qua. Cuộc tấn công diễn ra ở tầng xử lý yêu cầu của chính PHP trước hoặc sau khi ứng dụng chạy.

Dưới đây là chi tiết kỹ thuật của hai lỗ hổng theo công bố từ nhóm bảo mật PHP:

1. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — RCE qua lỗi hỏng bộ nhớ khi hết bộ nhớ (RCE via OOM corruption)#

Lỗ hổng này xảy ra trong quá trình xử lý tình huống hết bộ nhớ (out-of-memory - OOM). Khi PHP bị ngắt vì hết bộ nhớ đúng vào lúc dữ liệu nội bộ của request mới chỉ được khởi tạo một phần, quy trình dọn dẹp request (request cleanup) sau đó có thể hiểu nhầm phần dữ liệu chưa hoàn chỉnh (không hợp lệ) này là dữ liệu hợp lệ. Từ sự sai lệch trạng thái bộ nhớ đó, kẻ tấn công có thể dẫn dắt tiến trình tới việc thực thi mã từ xa.

2. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — RCE qua trạng thái toàn cục cũ còn sót lại (RCE via stale global state)#

Lỗ hổng thứ hai liên quan đến vòng đời bộ nhớ giữa các request trên cùng một worker. Cụ thể, trạng thái nội bộ thuộc quyền sở hữu của một request có thể tiếp tục tồn tại sau khi vùng bộ nhớ nền của nó đã được giải phóng (freed). Khi một request tiếp theo được xử lý bởi chính worker đó, tiến trình có thể sử dụng lại trạng thái cũ (stale state) này trước khi quy trình khởi tạo thông thường kịp đặt lại (reset) nó.

Hiện tại, thông báo bảo mật chính thức của PHP không đề cập việc hai lỗ hổng này đã bị khai thác ngoài thực tế hay chưa. Tuy nhiên, với mức điểm CVSS v4.0 là 9.2 và việc chi tiết kỹ thuật đã được công bố rộng rãi, việc trì hoãn cập nhật sẽ đặt hệ thống vào rủi ro rất lớn.

Hệ thống nào bị ảnh hưởng bởi bản vá PHP ngày 21/10/2026?#

Tất cả các bản cài đặt PHP đang phục vụ yêu cầu web (web requests) có phiên bản thấp hơn các bản vá mới nhất trong từng nhánh đều bị ảnh hưởng. Điều này bao gồm mọi môi trường thực thi phổ biến:

• PHP-FPM (mô hình phổ biến nhất khi đi kèm Nginx hoặc Apache)
• Apache với mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Lưu ý đặc biệt quan trọng: PHP đánh giá rủi ro ở mức cao nhất đối với Apache chạy mod_php. Nhóm bảo mật cho biết đã có mã khai thác chứng minh (demonstrated exploit) trong đó một request không cần xác thực có thể kích hoạt cuộc tấn công ngay trước khi bất kỳ đoạn code ứng dụng nào kịp chạy. Do đó, bạn không thể tự bảo vệ bằng cách cập nhật framework hay cài plugin tường lửa ở tầng PHP.

Bảng phiên bản PHP bị ảnh hưởng và phiên bản đã vá#

Với các doanh nghiệp vận hành hệ thống bán lẻ, F&B hay dịch vụ O2O, hệ thống thanh toán, POS hay CRM thường không chỉ chạy trên một máy chủ duy nhất. Đôi khi ứng dụng chính đã lên container mới nhưng một trang landing page WordPress cũ, một cron/webhook server phụ hoặc một cổng nội bộ vẫn chạy bản PHP cũ. Hãy rà soát toàn bộ danh mục máy chủ của bạn.

Checklist hành động ngay cho Founder và đội ngũ kỹ thuật#

Hãy thực hiện theo đúng thứ tự 5 bước dưới đây để đảm bảo hệ thống được vá triệt để:

1. Kiểm tra phiên bản PHP và SAPI trên tất cả máy chủ: Kiểm tra cả giao diện dòng lệnh lẫn tiến trình thực tế đang phục vụ web (PHP-FPM, mod_php, FrankenPHP, LiteSpeed, php-cgi). Đừng chỉ chạy php -v trên terminal rồi chủ quan, vì phiên bản CLI và phiên bản FPM/Apache module trên cùng một máy chủ có thể khác nhau.
2. Cập nhật thông qua gói của hệ điều hành (distro packages) hoặc Docker image chính thức:
   • Nếu dùng bản phân phối Linux (Ubuntu, Debian, RHEL...): Các nhà phân phối Linux và nhà cung cấp LTS đã nhận được bản vá trước từ nhóm PHP. Hãy chạy lệnh cập nhật gói của hệ điều hành. Lưu ý: Các gói của distro thường giữ nguyên số phiên bản cũ của upstream và chỉ ghép bản vá bảo mật (backport) vào. Vì vậy, hãy kiểm tra thông báo bảo mật của nhà cung cấp hoặc lịch sử thay đổi gói (package changelog) chứ không chỉ nhìn vào kết quả của lệnh php -v.
   • Nếu dùng Docker / Container: Khi base image đã có bản PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35, hãy pull lại, rebuild và redeploy toàn bộ container đang chạy, rồi kiểm tra lại phiên bản PHP bên trong container.
   • Cảnh báo quan trọng nếu dùng rpms.remirepo.net: Kho lưu trữ do tình nguyện viên duy trì tại rpms.remirepo.net sẽ không có bản cập nhật vào ngày 21/10/2026. PHP khuyến cáo người dùng đang phụ thuộc vào kho này cần chuyển ngay sang các gói chính thức của bản phân phối Linux hoặc tự biên dịch từ mã nguồn (build from source).
3. Khởi động lại PHP-FPM, Apache và toàn bộ các worker: Cập nhật gói phần mềm trên ổ cứng là chưa đủ nếu các tiến trình trong RAM vẫn đang chạy phiên bản cũ. Hãy restart dịch vụ php-fpm, apache2/httpd, FrankenPHP, LiteSpeed và mọi worker liên quan.
4. Đối với Shared Hosting hoặc Managed Hosting: Nếu doanh nghiệp của bạn đặt website trên shared hosting và không có quyền root để tự nâng cấp PHP, hãy gửi yêu cầu hỗ trợ (ticket) ngay cho nhà cung cấp dịch vụ để xác nhận thời điểm họ cập nhật bản vá cho CVE-2026-109618 và CVE-2026-109619.
5. Xác minh lại sau khi cập nhật: Kiểm tra lại changelog của gói đã cài đặt (trên Linux distro) hoặc phiên bản runtime thực tế mà web server đang nạp, đồng thời kiểm tra thời điểm khởi động (process start time) của các worker để chắc chắn không còn tiến trình cũ nào tồn tại.

Cách giảm thiểu rủi ro tạm thời nếu chưa thể cập nhật ngay hôm nay#

Nhóm bảo mật PHP nhấn mạnh rằng các biện pháp dưới đây chỉ giúp giảm mức độ phơi nhiễm trước một số hướng tấn công cụ thể và KHÔNG làm cho hệ thống trở nên an toàn. Cập nhật PHP lên phiên bản mới vẫn là cách khắc phục hoàn chỉnh duy nhất. Tuy nhiên, nếu bạn buộc phải chờ cửa sổ bảo trì, hãy áp dụng ngay các cấu hình sau:

Giảm thiểu cho CVE-2026-109618 (OOM corruption)#

• Đặt memory_limit=-1 theo cách mà code ứng dụng không thể ghi đè được (ví dụ: sử dụng chỉ thị php_admin_value trong cấu hình FPM pool hoặc cấu hình Apache).
• Đặt giá trị post_max_size ở mức thấp: 8M nếu ứng dụng không cần tải tệp lên (upload), hoặc 32M nếu ứng dụng có chức năng tải tệp; đồng thời giữ upload_max_filesize thấp hơn post_max_size.
• Áp đặt giới hạn kích thước request ngay tại tầng web server hoặc reverse proxy.
• Sử dụng giới hạn bộ nhớ ở tầng container hoặc cgroup làm ranh giới tài nguyên khả dụng; KHÔNG sử dụng RLIMIT_AS hoặc RLIMIT_DATA.

Giảm thiểu cho CVE-2026-109619 (Stale global state)#

• Đặt session.upload_progress.enabled=0 trực tiếp trong php.ini, cấu hình FPM pool hoặc cấu hình máy chủ (không dùng hàm ini_set() trong code và không đặt qua tệp .user.ini), sau đó khởi động lại tất cả các worker.
• Nếu đang chạy PHP 8.5, hãy đặt thêm fatal_error_backtraces=0 và khởi động lại các worker.
• Rà soát và sửa các lỗi nghiêm trọng (fatal errors) cũng như các điểm có thể bị hết thời gian thực thi (execution timeouts) mà kẻ tấn công từ bên ngoài có thể chủ động kích hoạt.

Lưu ý cho hệ thống chạy PHP 8.1 trở xuống và hạn EOL của PHP 8.2#

Nếu hệ thống của bạn vẫn đang chạy PHP 8.1 hoặc các phiên bản cũ hơn, các nhánh này hiện không còn nhận được bản cập nhật định kỳ từ dự án PHP. Bạn có hai hướng xử lý:

1. Kiểm tra xem bản phân phối Linux hoặc nhà cung cấp LTS của bạn có cung cấp bản vá backport cho gói PHP hiện tại hay không.
2. Nếu bạn tự biên dịch từ mã nguồn, nhóm bảo mật PHP đã công bố các bản vá mã nguồn tối thiểu (minimal source backports) dành cho PHP 7.4, 8.0 và 8.1 trên GitHub để hỗ trợ khắc phục khẩn cấp. Về lâu dài, bạn cần lên kế hoạch nâng cấp lên phiên bản đang được hỗ trợ.

Ngoài ra, các đội ngũ kỹ thuật đang dùng PHP 8.2 cũng cần lưu ý: nhánh PHP 8.2 sẽ chính thức kết thúc vòng đời hỗ trợ (End of Life - EOL) vào ngày 31/12/2026. Sau khi hoàn tất đợt vá khẩn cấp lên 8.2.35 trong hôm nay, việc đưa lộ trình nâng cấp lên PHP 8.3 hoặc 8.4 vào kế hoạch kỹ thuật quý 4/2026 là quyết định cần thiết để tránh rơi vào thế bị động trước các đợt cảnh báo bảo mật tiếp theo.

Nguồn: Thông báo bảo mật chính thức từ php.net và các khuyến cáo bảo mật trên kho lưu trữ GitHub php-src (GHSA-w8hw-w9fx-j79w / CVE-2026-109618 và GHSA-6wmf-4rv5-p3rp / CVE-2026-109619).