PHP phát hành bản vá khẩn cấp cho hai lỗ hổng RCE nghiêm trọng CVE-2026-109618 và CVE-2026-109619

Ngày 20/10/2026, nhóm bảo mật PHP ra thông báo trước về một bản phát hành bảo mật khẩn cấp xử lý hai lỗ hổng mức critical, mỗi lỗ hổng được chấm 9.2 theo thang CVSS v4.0. Ngày 21/10/2026, PHP phát hành các bản vá PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35, xác nhận hai lỗ hổng mang mã CVE-2026-109618 và CVE-2026-109619. Theo PHP, cả hai đều có thể dẫn đến thực thi mã từ xa (RCE) mà không cần xác thực. PHP khẳng định chỉ cập nhật mới là biện pháp khắc phục hoàn chỉnh.

Thông tin chi tiết

• Định danh lỗ hổng: CVE-2026-109618 và CVE-2026-109619

• Điểm CVSS (4.0): 9.2 cho mỗi lỗ hổng (theo PHP).

• Mức độ nghiêm trọng: CRITICAL – Cực kỳ nghiêm trọng

• Mô tả:

  • CVE-2026-109618 là RCE do hỏng bộ nhớ khi hết bộ nhớ (OOM). PHP dùng longjmp() để thoát khỏi ngữ cảnh hiện tại khi gặp lỗi OOM. Trong một số ngữ cảnh, bộ nhớ của request đã truy cập được trước khi khởi tạo xong. Nếu một lần cấp phát thất bại đúng lúc đó, PHP không xử lý đúng việc thoát sớm và để bộ nhớ request ở trạng thái không hợp lệ, sau đó bước kết thúc request đọc hoặc rẽ nhánh theo trạng thái này. Có nhiều cách gây OOM mà request vẫn nằm trong giới hạn bề ngoài của PHP, chủ yếu qua xử lý multipart. Ví dụ, request multipart không có độ dài khai báo dùng được có thể vượt kiểm tra post_max_size ban đầu, và một phần multipart có thể chứa số lượng header không giới hạn.

  • CVE-2026-109619 là RCE do trạng thái toàn cục còn sót lại. PHP giữ nhiều trạng thái toàn cục (lỗi, session, đối tượng, extension) trong worker nhưng trỏ tới bộ nhớ thuộc một request. Nếu không được đặt lại trước khi bộ nhớ bị giải phóng, một số thao tác chạy trước bước khởi tạo của request kế tiếp sẽ truy cập trạng thái cũ, gây use-after-free. Với bố trí heap phù hợp, lỗi này có thể dẫn đến RCE. Hai request (một request tạo trạng thái, một request dùng trạng thái) phải do cùng một worker xử lý. Cả hai được xếp loại CWE-416 (Use After Free).

• Phiên bản bị ảnh hưởng: Theo advisory GitHub của PHP, cả hai ảnh hưởng PHP trước 8.2.35, 8.3.36, 8.4.27 và 8.5.12 (trên từng nhánh tương ứng). PHP cho biết rủi ro áp dụng với mọi cài đặt PHP phục vụ web request (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed), cao nhất với mod_php. Các nhánh 8.1 trở xuống không còn được PHP hỗ trợ và không được liệt kê trong advisory, nhưng PHP vẫn cung cấp backport mã nguồn tối thiểu cho 7.4, 8.0 và 8.1. Theo Sansec, mọi máy chủ chạy PHP từ 5.4 trở lên đều bị ảnh hưởng, bao gồm các ứng dụng chạy trên PHP như Magento, Shopware và WooCommerce.

• Bản vá phát hành: PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 (21/10/2026, theo lịch 14:00 UTC, tức 21:00 giờ Việt Nam)

• Tình trạng khai thác: Các reporter đã chứng minh RCE hoàn chỉnh qua HTTP nhắm vào mod_php với giới hạn mặc định của PHP. Với CVE-2026-109619, RCE qua cơ chế session upload progress được chứng minh trên cả mod_php và PHP-FPM. Theo Sansec, Cloudflare ghi nhận các cuộc tấn công sớm vào sáng 21/10/2026, trước khi PHP phát hành bản vá.

PHP là gì và vì sao hai lỗ hổng này đáng lo ngại?

PHP là ngôn ngữ lập trình phía máy chủ được dùng rộng rãi để xây dựng ứng dụng web. Mạng lưới doanh nghiệp thường chạy các hệ thống quản lý nội dung (CMS) và công cụ nội bộ dựa trên PHP, vì vậy các máy chủ chạy PHP thường xử lý dữ liệu khách hàng và logic nghiệp vụ có thể truy cập được từ Internet.

Lỗi nằm ở chính PHP chứ không phải ở mã ứng dụng. Với Apache mod_php, PHP cho biết bước kết thúc request luôn được gọi ngay cả khi khởi động request thất bại, nên tấn công diễn ra hoàn toàn trước khi bất kỳ mã ứng dụng nào chạy. Vì vậy việc khắc phục phải thực hiện ở cấp máy chủ bằng cách cập nhật PHP, không thể xử lý trong mã ứng dụng. Với PHP-FPM, tiến trình con thoát khi khởi động request thất bại nên đường tấn công OOM ở giai đoạn khởi động không áp dụng giống mod_php. Tuy nhiên đường tấn công qua session upload progress đã được chứng minh trên cả FPM, và phụ thuộc vào một thao tác ứng dụng phù hợp.

Tác động đã được xác nhận là thực thi mã từ xa không cần xác thực với quyền của tài khoản web worker, kèm khả năng lộ bộ nhớ. Với website chạy trên shared hosting hoặc dịch vụ do nhà cung cấp quản lý, việc cập nhật PHP phụ thuộc vào nhà cung cấp, doanh nghiệp cần yêu cầu họ xác nhận phiên bản đã cập nhật.

PHP chỉ chính thức hỗ trợ từ phiên bản 8.2 trở lên, và PHP 8.2 sẽ hết hỗ trợ ngày 31/12/2026. Nếu doanh nghiệp còn website hoặc ứng dụng chạy PHP 8.1 trở xuống, các hệ thống này sẽ không nhận bản phát hành chính thức từ PHP. Cần nhờ nhà cung cấp bản phân phối hoặc LTS backport bản vá, dùng backport mã nguồn tối thiểu PHP cung cấp cho 7.4, 8.0, 8.1 (nếu tự build từ source), hoặc nâng cấp lên phiên bản được hỗ trợ.

Tổng quát quá trình khai thác

• Với mod_php, một request không cần xác thực có thể kích hoạt tấn công trước khi mã ứng dụng chạy.

• CVE-2026-109618: kẻ tấn công gây hết bộ nhớ trong lúc PHP xử lý request, chủ yếu qua multipart (không có độ dài khai báo, nhiều header trong một phần, nhiều trường file rỗng, tên trường lồng nhau). PHP thoát sớm bằng longjmp() và để dữ liệu request ở trạng thái không hợp lệ, bước kết thúc request xử lý dữ liệu này và dẫn đến RCE.

• CVE-2026-109619: một request gây lỗi nghiêm trọng (lỗi fatal, hết bộ nhớ...) khi trạng thái thuộc request đã được công bố, nên bộ nhớ bị giải phóng nhưng worker vẫn giữ tham chiếu. Request sau do cùng worker xử lý dùng trạng thái cũ trước khi khởi tạo, gây use-after-free. Hai đường đã xác nhận là fatal error backtrace trên PHP 8.5 và session upload progress (bật mặc định, không cần gọi session_start()).

• Kết quả là RCE với quyền của tài khoản web worker.

Khuyến nghị & Khắc phục

Đội ngũ FPT Threat Intelligence khuyến nghị người dùng và quản trị viên cần cân nhắc thực hiện các hành động sau:

• Cập nhật lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35. PHP khẳng định không có biện pháp giảm thiểu hoàn chỉnh, cập nhật là lựa chọn an toàn duy nhất.

• Nếu cài PHP từ gói của bản phân phối Linux hoặc nhà cung cấp LTS, kiểm tra gói đã được cập nhật. PHP cho biết các bên này đã nhận bản vá trước.

• Nếu dùng hosting, VPS hoặc dịch vụ do bên thứ ba quản lý, yêu cầu họ xác nhận bằng văn bản phiên bản PHP đã cập nhật và thời điểm cập nhật.

• Với PHP 8.1 trở xuống, liên hệ nhà cung cấp để backport bản vá hoặc nâng cấp lên bản được hỗ trợ.

• Kiểm kê toàn bộ máy chủ và ứng dụng đang chạy PHP, ưu tiên các hệ thống chạy mod_php và các hệ thống công khai ra Internet.

• Nếu chưa thể cập nhật ngay, PHP nêu các biện pháp sau. Chúng chỉ giảm rủi ro ở một số đường tấn công cụ thể, không làm hệ thống an toàn.

  • Đặt memory_limit=-1 ở cấp quản trị (ví dụ php_admin_value trong FPM pool hoặc cấu hình Apache) và khởi động lại mọi worker. Biện pháp này chưa loại bỏ hoàn toàn rủi ro vì lỗi cấp phát bộ nhớ nền vẫn có thể chạm đường lỗi.

  • Giữ post_max_size thấp (8M nếu không cần upload, 32M nếu cần) và giới hạn kích thước request đã giải mã ngay tại frontend. Nếu ứng dụng không dùng multipart/form-data, chặn loại request này ở frontend trước khi tới PHP.

  • Đặt session.upload_progress.enabled=0 trong php.ini, FPM pool hoặc cấu hình server rồi khởi động lại mọi worker. PHP khuyến nghị cân nhắc tắt tính năng này kể cả sau khi vá nếu không dùng đến.

  • Trên PHP 8.5, đặt thêm fatal_error_backtraces=0 và khởi động lại mọi worker.

  • Không dùng RLIMIT_AS hoặc RLIMIT_DATA để giới hạn bộ nhớ vì có thể gây chính lỗi cấp phát này.

• Sau khi cập nhật, đảm bảo tiến trình PHP thực sự phục vụ web đã nạp phiên bản mới (khởi động lại PHP-FPM hoặc Apache) và xác minh phiên bản của tiến trình đó, không chỉ của PHP CLI.

Tham khảo

• PHP.net – Security advisory: Critical remote code execution vulnerabilities, update now (21/10/2026)

• PHP.net – Upcoming Critical PHP Security Release (20/10/2026)

• GitHub – GHSA-w8hw-w9fx-j79w (CVE-2026-109618)

• GitHub – GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)

• Sansec – Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619

• watchTowr – FAQ: PHP Remote Code Execution (CVE-2026-109618 & CVE-2026-109619)