# 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 lỗ hổng ảnh hưởng các bản PHP theo từng nhánh như sau:
    

| Nhánh PHP | Phiên bản bị ảnh hưởng | Bản vá khắc phục |
| --- | --- | --- |
| 8.2 | <8.2.35 | 8.2.35 |
| 8.3 | <8.3.36 | 8.3.36 |
| 8.4 | <8.4.27 | 8.4.27 |
| 8.5 | <8.5.12 | 8.5.12 |

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.

*   *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?

![](https://cdn.hashnode.com/uploads/covers/669e7a2f2c109ecd663148bd/c2368491-5a7c-41b1-8cd7-8478137cab98.png align="center")

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. Theo Wiz và Cloudflare (dẫn W3Techs), khoảng 70% website dùng PHP, trong đó có WordPress, Drupal và Joomla.

Lỗi nằm ở chính PHP chứ không phải ở mã ứng dụng. Theo Wiz, ngay cả một ứng dụng “Hello World” đơn giản chạy trên phiên bản PHP bị ảnh hưởng cũng có thể bị khai thác, nên cập nhật ứng dụng hay plugin không khắc phục được, phải cập nhật PHP. 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ớ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 PHP 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. Theo Wiz, kẻ tấn công còn có thể đọc bộ nhớ tiến trình PHP, gồm mật khẩu, token xác thực, khóa API và chứng chỉ thuộc request khác hoặc của chính máy chủ. Việc rò rỉ này không cần RCE trước nên có thể khó bị phát hiện hơn bởi các công cụ chỉ tập trung vào thực thi mã độc.

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. Theo Wiz, việc biến các lỗi này thành exploit chạy được đòi hỏi chuỗi nhiều bước phụ thuộc bố cục bộ nhớ của từng mục tiêu, và các mô hình AI tiên phong giúp tinh chỉnh exploit cho nhiều phiên bản và cấu hình PHP chỉ trong vài giờ.
    

### 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 website đứng sau Cloudflare, WAF của Cloudflare đã bảo vệ mặc định từ 03:02 UTC ngày 21/10/2026 cho cả gói Free và gói trả phí. Với gói Professional, Business và Enterprise, cần kiểm tra Managed Ruleset đang ở chế độ block. Akamai, Imperva, Fastly và một số nhà cung cấp khác cũng đã chuẩn bị biện pháp tạm thời. Cloudflare nhấn mạnh đây chỉ là lớp bảo vệ bổ sung, vẫn phải cập nhật PHP.
    
*   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.
    
    *   Với **CVE-2026-109618**:
        
        *   Đặ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.
            
        *   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.
            
    *   Với **CVE-2026-109619**
        
        *   Đặ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.
            
*   Khi chưa vá, theo Wiz cần chú ý các dấu hiệu sau, vì log ứng dụng có thể có rất ít ngữ cảnh: request multipart bất thường theo sau bởi lỗi vượt giới hạn bộ nhớ hoặc HTTP 500 lặp lại, cookie `PHPSESSID` trong phản hồi lớn bất thường hoặc sai định dạng, và worker PHP bị khởi động lại không rõ lý do.
    
*   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 và xác minh phiên bản của tiến trình đó, không chỉ của PHP CLI. Theo php2shell.com, bản vá của PHP thêm một giới hạn bộ nhớ cứng mới, khi chạm giới hạn tiến trình bị kết thúc, nên cần xem lại `memory_limit` cùng các giới hạn kích thước request, hoàn tác `memory_limit=-1` tạm thời và giữ `max_input_nesting_level` ở mức ứng dụng thực sự cần.
    

### Tham khảo

*   [PHP2Shell](https://www.php2shell.com/)
    
*   [PHP.net](http://PHP.net) [– Security advisory: Critical remote code execution vulnerabilities, update now (21/10/2026)](https://www.php.net/archive/2026.php#2026-10-21-5)
    
*   [PHP.net](http://PHP.net) [– Upcoming Critical PHP Security Release (20/10/2026)](https://www.php.net/archive/2026.php#2026-10-20-1)
    
*   [GitHub – GHSA-w8hw-w9fx-j79w (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
    
*   [GitHub – GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
    
*   [Wiz – PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet](https://www.wiz.io/blog/php2shell-php-rce)
    
*   [Cloudflare – Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
    
*   [Sansec – Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619](https://sansec.io/research/php2shell)
    
*   [watchTowr – FAQ: PHP Remote Code Execution (CVE-2026-109618 & CVE-2026-109619)](https://watchtowr.com/intelligence/php-cve-2026-109618-php-faq/)