---
title: "PHP2Shell: nguyên nhân và hướng dẫn khắc phục"
description: "Hiểu các lỗi trong vòng đời của PHP2Shell, nâng cấp thời gian chạy, giảm thiểu tạm thời, lựa chọn bản vá và xác minh thông qua đường dẫn yêu cầu Web trực tiếp."
language: "vi"
url: "https://keendigit.com/vi/insights/php2shell-remediation-guide"
author: "KeenDigit"
published: "2026-10-22"
---

# PHP2Shell: nguyên nhân và hướng dẫn khắc phục

Hiểu các lỗi trong vòng đời của PHP2Shell, nâng cấp thời gian chạy, giảm thiểu tạm thời, lựa chọn bản vá và xác minh thông qua đường dẫn yêu cầu Web trực tiếp.

**Nguồn được kiểm tra kể từ ngày 22 tháng 10 năm 2026.** **Audience: Người vận hành ứng dụng PHP, người phản hồi bảo mật và kỹ sư duy trì các bản dựng PHP tùy chỉnh.**

Bài viết này tóm tắt nguyên nhân, phạm vi tác động, quy trình sửa chữa chính thức, các biện pháp giảm thiểu tạm thời và triển khai bản vá chính thức cho lỗ hổng PHP2Shell. Văn bản chính được trích dẫn bằng các số như [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1); tất cả các liên kết nguồn được liệt kê trong phần phụ lục ở cuối văn bản. Đoạn cấu hình là một mẫu triển khai, cần được điều chỉnh dựa trên phiên bản thực tế, năng lực kinh doanh và mối quan hệ kế thừa cấu hình.

## TL;DR: Các bước sửa chữa và đề xuất

1. **Nâng cấp thời gian chạy PHP**: nâng cấp nhánh liên quan lên ít nhất là **8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12**. Đối với các gói phân phối, hãy sử dụng phiên bản gói hoàn chỉnh mà nhà cung cấp xác nhận sẽ sửa cả hai CVE. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S10](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-10)
2. **Thay thế tất cả các quy trình cũ**: khởi động lại hoặc chuyển đổi mọi PHP worker, dịch vụ lưu trữ và vùng chứa sau khi nâng cấp và xác nhận rằng các phiên bản cũ đã thoát.
3. **Xác minh thông qua đường dẫn yêu cầu Web thực tế**: kiểm tra Web SAPI, phiên bản gói đầy đủ và phiên bản đang chạy. Chỉ kiểm tra `php -v` không chứng minh được rằng dịch vụ trực tiếp đã được sửa.
4. **Chạy kiểm tra hồi quy kinh doanh và khôi phục ngân sách tài nguyên thông thường**: kiểm tra đăng nhập, xử lý phiên, tải lên, nhập và xử lý lỗi. Nếu giới hạn bộ nhớ PHP tạm thời bị xóa, hãy khôi phục ngân sách hữu hạn thích hợp sau khi vá.
5. **Nếu không thể nâng cấp ngay lập tức**: hạn chế lưu lượng không đáng tin cậy trước khi nó đạt đến PHP. Đánh giá việc vô hiệu hóa tiến trình tải lên và các dấu vết quay ngược nghiêm trọng của PHP 8.5 như được mô tả trong Phần 5. Các biện pháp giảm thiểu cấu hình và quy tắc WAF có phạm vi áp dụng hạn chế và không thể thay thế bản nâng cấp. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

## 1. Tổng quan về lỗ hổng và đánh giá rủi ro

PHP2Shell trong bài viết này đề cập đến hai lỗ hổng cấp độ Critical được PHP chính thức tiết lộ vào ngày 21 tháng 10 năm 2026. Cả hai đều liên quan đến bộ nhớ và yêu cầu quản lý vòng đời của công cụ PHP, gây ra nguy cơ thực thi mã từ xa không được xác thực. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

| dự án                               | CVE-2026-109618                                                                                  | CVE-2026-109619                                                                               |
| ----------------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- |
| tên chính thức                      | RCE via OOM corruption                                                                           | RCE via stale global state                                                                    |
| vấn đề cốt lõi                      | Bộ nhớ không đủ gây ra bước nhảy bất thường, để lại trạng thái chưa hoàn tất quá trình khởi tạo. | Trạng thái toàn cục còn lại trong worker trỏ tới bộ nhớ yêu cầu đã giải phóng.                |
| Thời gian xuất hiện điển hình       | Quá trình khởi tạo, thực hiện hoặc dọn dẹp yêu cầu hiện tại                                      | Yêu cầu trước đó sẽ rời khỏi trạng thái và các yêu cầu tiếp theo sẽ sử dụng trước yêu cầu đó. |
| OOM có phải là điều kiện cần không? | Thuộc cơ chế kích hoạt cốt lõi của lỗ hổng                                                       | Không; các lỗi nghiêm trọng khác và việc dọn dẹp sau chẩn đoán cũng có thể liên quan đến      |
| Hướng sửa chữa cơ bản               | Xử lý an toàn các lỗi phân bổ và chấm dứt yêu cầu                                                | Khắc phục quyền sở hữu nhà nước, thời gian dọn dẹp và khởi tạo sớm                            |
| Yêu cầu xử lý                       | phải được sửa chữa                                                                               | phải được sửa chữa cùng một lúc                                                               |

Cơ sở: Hai bản tin bảo mật chính thức và các bản sửa lỗi được gửi. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-4)

### 1.1 Tìm hiểu các hoạt động triển khai bị ảnh hưởng

PHP chính thức coi việc triển khai **all PHP xử lý các yêu cầu Web** đang gặp rủi ro, bao gồm PHP-FPM, Apache mod\_php, php-cgi, FrankenPHP và LiteSpeed. Cuộc tấn công mod\_php đã được chứng minh có thể xảy ra trước khi mã ứng dụng chạy, do đó, việc kiểm tra đăng nhập, phần mềm trung gian khung và xác thực tải lên ứng dụng không thể bao gồm đường dẫn đó. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)

Cần phân biệt giữa “việc triển khai cần phải được khắc phục” và “một chuỗi tấn công nào đó đã được chứng minh hoàn toàn”. Thông báo của CVE-2026-109618: FPM sẽ thoát khỏi tiến trình con sau khi khởi động yêu cầu không thành công, chặn đường dẫn dọn dẹp tương ứng của mod\_php sau khi khởi động thất bại; tuy nhiên, đường dẫn OOM sau khi khởi động thành công vẫn gặp rủi ro. Thông báo cũng lưu ý rằng việc khai thác FPM đầy đủ cho CVE này vẫn chưa được chứng minh. Hạn chế này không thể dùng để suy ra FPM an toàn, đặc biệt là CVE-2026-109619 không thể bỏ qua. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

Giới hạn quyền ngay lập tức để khai thác thành công phụ thuộc vào danh tính của quá trình lưu trữ PHP và các tài nguyên mà nó có quyền truy cập. Nói chung, cần chú ý đến mã trang web, thư mục tải lên, thông tin xác thực cơ sở dữ liệu, mã thông báo dịch vụ và khả năng truy cập mạng nội bộ; "thực thi mã từ xa" không có nghĩa là có được quyền root một cách tự nhiên. Đánh giá hậu quả ở đây dựa trên mô hình cấp phép quy trình và tác động thực tế cần được đánh giá cùng với các quyền triển khai.

Các tập lệnh CLI dùng một lần thông thường không có cùng mục nhập HTTP; nhưng các quy trình xử lý các tác vụ bên ngoài trong thời gian dài ở chế độ CLI hoặc chế độ nhúng vẫn phải được đưa vào kho thời gian chạy và vòng đời. Chỉ các phần phụ thuộc CMS, framework hoặc Composer mới được cập nhật và công cụ PHP cơ bản không được tự động thay thế.

## 2. Phân tích nguyên nhân

### 2.1 Đầu tiên hãy hiểu hai vòng đời

PHP worker thường xử lý nhiều yêu cầu liên tiếp. Bộ nhớ được phân bổ trong quá trình yêu cầu có thể được giải phóng một cách thống nhất khi kết thúc yêu cầu, trong khi chính nhân viên và một số trường toàn cầu của nó vẫn tiếp tục tồn tại.

Do đó, động cơ phải duy trì hai ràng buộc:

- **Ràng buộc khởi tạo**: Dữ liệu hiển thị với các mã khác phải ở trạng thái có thể đọc, duyệt và hủy một cách an toàn.
- **Ràng buộc vòng đời**: khi bộ nhớ yêu cầu đã được giải phóng, các trường tồn tại lâu hơn không được tiếp tục coi các địa chỉ trong bộ nhớ đó là trạng thái hợp lệ.

Hai ràng buộc này tương ứng với các dạng lỗi chính của hai nhóm lỗ hổng. Quy trình sau đây là mô tả cơ chế kết hợp các thông báo và biên soạn bản vá. Điều đó không có nghĩa là mọi hoạt động triển khai đều có cùng một đường dẫn có thể truy cập được. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

### 2.2 CVE-2026-109618: OOM đã làm gián đoạn quá trình cập nhật trạng thái chưa hoàn thành

Cách triển khai cũ sử dụng bước nhảy không cục bộ thuộc loại `longjmp()` để xử lý OOM và đường dẫn liên quan sẽ thoát khỏi bối cảnh thực thi hiện tại thông qua `zend_bailout()`. Điều nguy hiểm là một đoạn mã C có thể đã xuất bản một đối tượng, mảng hoặc trạng thái yêu cầu mới sang mã khác, nhưng vẫn chưa hoàn thành tất cả quá trình khởi tạo trường; tại thời điểm này, bất kỳ lỗi phân bổ nào tại thời điểm thích hợp đều có thể khiến các bước đóng thông thường bị bỏ qua. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

Quá trình thất bại có thể được chia thành bốn bước:

1. Tạo hoặc cập nhật cấu trúc bên trong của yêu cầu và làm cho nó có thể truy cập được.
2. Việc cấp phát bộ nhớ sau đó không thành công và OOM được kích hoạt.
3. Luồng thực thi nhảy khỏi hàm hiện tại và mã ban đầu được sử dụng để hoàn thành trạng thái khởi tạo hoặc khôi phục không được thực thi.
4. Yêu cầu dọn dẹp tiếp tục xử lý các cấu trúc này và xử lý nội dung không hợp lệ dưới dạng trường hoặc địa chỉ hợp lệ.

Vấn đề không phải là hết bộ nhớ luôn gây ra RCE. Đúng hơn, việc cạn kiệt bộ nhớ **sẽ thay đổi luồng điều khiển và vi phạm các giả định của động cơ về các cấu trúc hợp lệ**. Việc phân bổ thất bại không cần trực tiếp liên quan đến cấu trúc mà cuối cùng bị đọc sai. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

#### Tại sao các yêu cầu nhỏ hơn cũng có thể hết bộ nhớ

Số byte trong phần thân yêu cầu và mức sử dụng vùng heap sau khi phân tích cú pháp không giống nhau. Trường A có thể tương ứng với nhiều chuỗi, thành phần mảng và đối tượng siêu dữ liệu bên trong PHP; độ phức tạp của cấu trúc đầu vào sẽ ảnh hưởng đến mức độ khuếch đại bộ nhớ.

Các vấn đề với nhiều phần được liệt kê trong thông báo chính thức bao gồm: khoảng cách kiểm tra kích thước ban đầu khi thiếu độ dài khai báo có sẵn, số lượng tiêu đề cho một phần không đủ giới hạn và các điều khiển tệp trống vẫn tạo ra siêu dữ liệu, với các tên lồng nhau làm tăng thêm khối lượng công việc mảng. Việc giải mã, giải mã hoặc gán lại đầu vào của ứng dụng cũng có thể là nguồn của OOM. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

Hai kết luận bảo vệ có thể được rút ra từ điều này:

- Các hạn chế về nội dung yêu cầu phải được triển khai càng nhiều càng tốt trước khi nhập PHP, đồng thời phải xem xét độ dài đọc thực tế cũng như độ phức tạp của cấu trúc.
- Việc giới hạn riêng kích thước tệp, số lượng tệp hoặc chỉ đóng một cổng tải lên không thể bao gồm tất cả các nguồn OOM.

#### Tại sao xác thực ứng dụng có thể quá muộn

Trong mod\_php, nội dung yêu cầu có thể được phân tích cú pháp tự động trong giai đoạn khởi tạo yêu cầu; ngay cả khi khởi động không thành công, việc dọn dẹp yêu cầu liên quan vẫn sẽ được thực hiện. Do đó, các đường dẫn tấn công được xác nhận có thể xảy ra trước mã ứng dụng. Để giảm mức độ hiển thị ở giai đoạn này, các hạn chế cần được đặt ở proxy ngược, máy chủ Web hoặc ranh giới khác trước quá trình xử lý yêu cầu PHP. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

### 2.3 CVE-2026-109619: Bộ nhớ yêu cầu đã được giải phóng, tham chiếu chung vẫn còn tồn tại

Sự cố này liên quan đến trạng thái lỗi, phiên, đối tượng hoặc tiện ích mở rộng: trường được lưu trữ ở một vị trí truy cập dài hạn của nhân viên, nhưng dữ liệu được trường tham chiếu thuộc về một yêu cầu duy nhất. Miễn là tham chiếu không được dọn sạch đúng cách trước khi đống yêu cầu được giải phóng, các yêu cầu tiếp theo có thể gặp phải trạng thái lơ lửng, hình thành use-after-free. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

Phân tích chính thức chia điều kiện khai thác thành “người sản xuất” và “người tiêu dùng”:

| vai trò hoặc điều kiện | ý nghĩa                                                                                            | Ý nghĩa của việc bảo vệ                                                                        |
| ---------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| nhà sản xuất nhà nước  | Đặt trạng thái thuộc sở hữu của yêu cầu này vào một vị trí mà sau này vẫn có thể truy cập được     | Để kiểm tra xem việc dọn dẹp tương ứng có được hoàn thành sau khi thoát bất thường hay không   |
| Trạng thái vẫn còn     | Nó không được xóa hoặc nó đã được xóa và sau đó được nạp lại do thao tác muộn.                     | Chỉ xóa một lần ở giai đoạn tắt máy trước đó có thể là không đủ                                |
| tái sử dụng công nhân  | Nhân viên tương tự tiếp tục xử lý các yêu cầu tiếp theo                                            | Nhiều công nhân chỉ là sự khác biệt về lịch trình, không phải là sự đảm bảo an toàn cho bộ nhớ |
| người tiêu dùng trước  | Đọc, giải phóng hoặc xác định giá trị dư trước khi trạng thái tương ứng được khởi tạo bình thường. | Phải kiểm tra INI, phiên và các đường dẫn khác trước khi khởi tạo                              |

Những điều kiện này cần phải được đáp ứng kết hợp; bất kỳ nhật ký lỗi nào tự nó không chứng minh rằng lỗ hổng đã được khai thác thành công. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

#### Nó không yêu cầu OOM là điều kiện tiên quyết cần thiết

Các lỗi nghiêm trọng có thể làm gián đoạn việc xuất bản và khôi phục trạng thái được ghép nối. Lỗi biên dịch hoặc phân tích cú pháp, lỗi chưa được xử lý, lỗi `require` và thời gian chờ thực thi có thể để lại các trạng thái cụ thể. Chẩn đoán không gây tử vong muộn trong quá trình dọn dẹp cũng có thể khôi phục lại thông tin lỗi đã bị xóa. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

Do đó, việc thay đổi `memory_limit` thành không giới hạn sẽ không giải quyết được nhóm lỗ hổng này.

#### "Trước khi khởi tạo" cần được xử lý riêng

Thời điểm của hai loại người tiêu dùng được xác nhận là khác nhau:

- Chẩn đoán **Esớm INI**: Một số cấu hình được áp dụng cho cảnh báo, thông báo hoặc ngừng sử dụng vấn đề yêu cầu trước khi khởi tạo trình thực thi thông thường và xử lý chẩn đoán có thể truy cập vào trạng thái lỗi cũ.
- **Tiến trình tải lên phiên**: phiên có thể được xử lý trước trong quá trình phân tích nội dung yêu cầu, nhưng mô-đun thông thường `RINIT` vẫn chưa được hoàn thành; không thể suy ra rằng đường dẫn không tồn tại vì ứng dụng không gọi `session_start()` một cách rõ ràng. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

Không phải tất cả các cấu hình INI đều có cùng thời điểm rủi ro. Cấu hình cấp thư mục của mod\_php và `PHP_VALUE` / `PHP_ADMIN_VALUE` được giao diện người dùng FPM chuyển vào cần phải được phân biệt với cấu hình khởi động `php.ini`, FPM pool và FPM `.user.ini` thông thường. Những cái sau có thời gian cấu hình khác nhau và không thể gọi chung là những người tiêu dùng đầu tiên giống nhau. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

Việc tắt `display_errors`, `log_errors`, giảm `error_reporting` hoặc sử dụng `@` chỉ ảnh hưởng đến khả năng hiển thị của chẩn đoán; trạng thái nội bộ liên quan có thể đã được truy cập trước khi quyết định có xuất nhật ký hay không. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

## 3. Lựa chọn phiên bản sửa chữa và bản vá

### 3.1 Đường cơ sở sửa lỗi ngược dòng chính thức

| Chi nhánh PHP hiện tại      | Phiên bản đầu tiên có bản sửa lỗi chính thức này | Đề xuất                                                                                                    |
| --------------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| 8.2                         | 8.2.35                                           | Nâng cấp lên phiên bản này hoặc phiên bản tiếp theo có cùng các bản sửa lỗi                                |
| 8.3                         | 8.3.36                                           | Tương tự như trên                                                                                          |
| 8.4                         | 8.4.27                                           | Tương tự như trên                                                                                          |
| 8.5                         | 8.5.12                                           | Tương tự như trên                                                                                          |
| 8.1 và các phiên bản cũ hơn | Hỗ trợ chung ngược tuyến đã kết thúc             | Ưu tiên di chuyển đến các chi nhánh được hỗ trợ; phát hành séc ngắn hạn hoặc cổng sau của nhà sản xuất LTS |

Phiên bản và trạng thái hỗ trợ dựa trên thông báo chính thức của PHP và thời gian cơ sở là ngày 22 tháng 10 năm 2026. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)

Đây là **ngưỡng sửa lỗi cụ thể của chi nhánh**. Không thể thay thế chúng bằng tuyên bố rằng mọi phiên bản bên dưới 8.5.12 đều dễ bị tấn công: các phiên bản như 8.2.35 và 8.4.27 ở các nhánh khác đã có bản sửa lỗi.

### 3.2 Kiểm tra phiên bản gói phân phối đầy đủ

Các bản phân phối thường bổ sung các bản sửa lỗi bảo mật dựa trên các phiên bản ngược dòng cũ hơn. Việc chấp nhận cũng nên kiểm tra phiên bản phát hành, nguồn kho lưu trữ, phiên bản gói đầy đủ và bản tin bảo mật.

Ví dụ: phiên bản gói sửa lỗi Ubuntu 24.04 LTS được liệt kê cho Ubuntu USN-8948-1 là:

```text
8.3.6-0ubuntu0.24.04.13
```

Phần ngược dòng của nó vẫn là `8.3.6`, nhưng phiên bản gói đầy đủ của bản phân phối đó được bao gồm trong thông báo sửa lỗi này. Kết luận này chỉ áp dụng cho nguồn gói và phân phối tương ứng và không thể khái quát cho bất kỳ bản dựng nào cũng hiển thị `8.3.6`. [S10](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-10)

### 3.3 Chọn bản vá phù hợp

| bối cảnh                                            | Kế hoạch ưu tiên                                                                             | Những điểm chính để chấp nhận                                                                         |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Sử dụng gói phân phối PHP                           | Cài đặt các bản cập nhật bảo mật do nhà sản xuất phát hành                                   | Thông báo bao gồm cả CVE; phiên bản gói hoàn chỉnh là chính xác                                       |
| Sử dụng bộ chứa PHP chính thức hoặc hình ảnh tự tạo | Cập nhật thời gian chạy cơ sở, xây dựng lại và triển khai                                    | Phiên bản đang chạy sử dụng hình ảnh mới; tất cả các bản sao cũ đã thoát                              |
| Các nhánh được hỗ trợ tự biên dịch                  | Sử dụng phiên bản bảo mật chính thức của chi nhánh này hoặc bộ bản vá chính thức đầy đủ      | So khớp nhánh, hoàn thiện phần phụ thuộc, khả năng tương thích với tiện ích mở rộng và chuyển hồi quy |
| Tuân theo 7.4, 8.0, 8.1                             | Ưu tiên backport của nhà cung cấp; đánh giá nhánh mã nguồn khẩn cấp chính thức nếu cần thiết | Xác định các thay đổi về hành vi và lên lịch di chuyển sang các phiên bản được hỗ trợ                 |

Các bản vá chính thức đã được phát hành và các bản sửa lỗi thực tế sẽ bắt đầu từ các bản vá này. Các đoạn mã trong Phần 6 nhằm mục đích minh họa các điểm nổi bật trong thiết kế và đánh giá và không cấu thành một bản vá hoàn chỉnh có thể được áp dụng độc lập. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-6)

## 4. Quy trình sửa chữa chính thức

### 4.1 Kiểm kê thời gian chạy thực sự xử lý các yêu cầu

Nên lập sổ cái ngắn gọn để ghi lại ít nhất:

- Tên miền hoặc dịch vụ đầu vào, phụ trợ proxy ngược, PHP SAPI.
- Nhánh PHP, phiên bản gói đầy đủ hoặc bản tóm tắt hình ảnh, nguồn xây dựng.
- FPM pool, đơn vị dịch vụ thực tế, thùng chứa hoặc Pod, số lượng bản sao.
- Các phần mở rộng, cấu hình chính và các tệp cấu hình bổ sung đã được tải.
- Có phiên bản PHP nào khác, bản sao triển khai cũ hoặc cổng gốc có thể truy cập trực tiếp không?

Đây là những gợi ý triển khai để việc “nâng cấp” có thể tương ứng với từng mục nhập lưu lượng truy cập thực tế. Đặc biệt kiểm tra xem các dòng lệnh PHP và Web PHP có sử dụng các phiên bản khác nhau hay không, image được build nhưng container cũ vẫn chạy, một phần của pool hoặc bản sao không được thay thế, v.v.

### 4.2 Chọn và triển khai bản cập nhật chính xác

Xác nhận phiên bản sửa lỗi theo Phần 3, tốt nhất là sử dụng nguồn gói đáng tin cậy hiện có hoặc chuỗi xây dựng được kiểm soát. Phạm vi cập nhật phải bao gồm thành phần thực sự lưu trữ yêu cầu, chẳng hạn như gói FPM, mô-đun Apache PHP, tệp nhị phân CGI hoặc bản dựng dịch vụ trong đó PHP được nhúng.

Trước khi nâng cấp, hãy giữ lại cấu hình và danh sách gói, đồng thời xác minh các dịch vụ khởi động và chính trong môi trường tương tự như môi trường sản xuất. Đối với các tiện ích mở rộng tự bảo trì, hãy kiểm tra khả năng tương thích khi xây dựng và chạy tương ứng với phiên bản PHP. Chỉ chọn một cam kết có vẻ phù hợp từ một nhánh khác không đảm bảo rằng toàn bộ các bản sửa lỗi đã được triển khai.

### 4.3 Khởi động lại hoặc cuộn qua các phiên bản đang chạy

Cài đặt một tập tin và tải mã mới vào một tiến trình là hai việc khác nhau. Dịch vụ tương ứng phải được khởi động lại hoặc hoàn thành việc thay thế lăn, đồng thời công nhân cũ và container cũ phải được xác nhận đã thoát ra.

Đối với mod\_php, hãy khởi động lại quy trình Apache lưu trữ mô-đun. Các dịch vụ nhúng PHP cần được thay thế quy trình lưu trữ. Đối với FPM, việc xóa OPcache không thay thế việc cập nhật thời gian chạy và loại bỏ các công cụ cũ.

Khi sử dụng chuyển đổi duyên dáng, bạn cần kiểm tra xem quy trình thế hệ cũ có còn xử lý các kết nối dài hoặc các yêu cầu chưa xử lý hay không. Bản ghi chấp nhận phải bao gồm dịch vụ thực tế, phiên bản triển khai, thời gian hoàn thành thay đổi và kết quả thoát của phiên bản cũ.

### 4.4 Xác minh thông qua các yêu cầu Web thực

Nên kết hợp các bằng chứng sau đây thay vì chỉ dựa vào một lệnh phiên bản duy nhất:

| bằng chứng                                                    | Điều gì có thể được chứng minh                    | Không thể chứng minh bất cứ điều gì một mình          |
| ------------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------- |
| Trình quản lý gói hoặc siêu dữ liệu hình ảnh                  | Nguồn cài đặt và bản dựng đầy đủ                  | Lưu lượng truy cập đã được chuyển sang trường hợp này |
| Trạng thái quy trình và triển khai                            | công nhân hoặc container hoàn thành việc thay thế | Lối vào bên ngoài phải được định tuyến đến nó         |
| Kết quả chẩn đoán bị hạn chế truy cập qua cổng thông tin thực | Web SAPI thực tế và cấu hình đang chạy            | Liệu cổng sau phát hành có bao gồm hai CVE hay không  |
| Thông báo của nhà cung cấp hoặc bản vá hoàn chỉnh             | Bản sửa lỗi này được bao gồm trong bản dựng này   | Tất cả các bản sao được triển khai                    |

`PHP_VERSION`, `PHP_SAPI`, các tệp cấu hình đã tải và cấu hình khẩn cấp có thể được kiểm tra thông qua các khả năng chẩn đoán nội bộ hiện có hoặc các cổng chẩn đoán tạm thời và được kiểm soát quyền truy cập. Đảm bảo yêu cầu không được CDN hoặc bộ đệm trang trả về trực tiếp; xóa mục chẩn đoán tạm thời khi hoàn thành.

`php -v` thường chỉ biểu thị mã nhị phân CLI hiện được shell chọn; các lệnh như `php-fpm -i` không tương đương với việc xác minh nhân viên hiện có đang nhận lưu lượng truy cập. Không hiển thị trang `phpinfo()` hoàn chỉnh trên mạng công cộng trong thời gian dài.

### 4.5 Kiểm tra hồi quy doanh nghiệp và xóa cài đặt khẩn cấp

Xác minh thông tin đăng nhập bình thường, đọc và ghi phiên, biểu mẫu và tải lên, nhập, xử lý lỗi và độ ổn định của nhân viên xung quanh các chức năng bị ảnh hưởng bởi thay đổi này. Kiểm tra xem tỷ lệ lỗi, độ trễ phản hồi, đỉnh bộ nhớ, tần số thoát quá trình và xây dựng lại có bất thường hay không.

Nếu `memory_limit=-1` được đặt tạm thời, ngân sách hạn chế phù hợp với năng lực kinh doanh sẽ được khôi phục sau khi bản vá chính thức có hiệu lực; nếu `pm.max_requests=1` được đặt, cấu hình vòng đời được đánh giá về công suất sẽ được khôi phục sau khi việc sửa chữa được xác nhận. Giới hạn kích thước đầu vào và kiểm soát quyền truy cập nguồn có thể được giữ lại theo nhu cầu kinh doanh.

Nếu vấn đề tương thích phát sinh trong quá trình nâng cấp, bạn nên ưu tiên tạm dừng cổng bị ảnh hưởng, hạn chế quyền truy cập bên ngoài hoặc điều chỉnh ứng dụng trước khi quay trở lại. Việc trực tiếp cho phép thời gian chạy chưa được sửa chữa phục vụ lại mạng công cộng sẽ mở lại rủi ro ban đầu.

## 5. Biện pháp giảm thiểu khi không thể nâng cấp ngay

Phần này nhằm mục đích giảm mức độ phơi nhiễm trong thời gian ngắn hoặc cải thiện tính khả dụng. Mỗi biện pháp chỉ bao gồm một đường dẫn cụ thể và việc kết hợp nhiều biện pháp không tương đương với việc sửa chữa hoàn chỉnh. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

### 5.1 Ưu tiên điều khiển giao thông trước PHP

Nếu dịch vụ cho phép, hãy tạm thời hạn chế các điểm cuối nhạy cảm đối với các nguồn đáng tin cậy hoặc thực thi kiểm soát truy cập trước PHP. Đối với khối lượng công việc tải lên, hãy giới hạn kích thước nội dung yêu cầu, số lượng trường, số lượng phần, tiêu đề cho mỗi phần và độ sâu lồng nhau. Các dịch vụ không cần nhiều phần có thể từ chối nó ở giao diện người dùng. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

Những hạn chế này nhằm bao gồm tất cả các lối vào PHP. Chỉ chặn URL có tên "tải lên" sẽ bỏ lỡ các mục nhập khác vẫn được PHP phân tích cú pháp tự động trong nội dung yêu cầu. Đối với các trường hợp như truyền theo từng đoạn, thiếu độ dài khai báo sẵn có, v.v., giới hạn phải dựa trên kích thước đọc thực tế; ứng dụng cũng phải có ngân sách kích thước đầu ra riêng khi giải nén hoặc mở rộng lại nội dung.

### Mẫu cấu hình 5.2 FPM pool

Đặt các cài đặt sau vào phần cấu hình **FPM pool thực sự phục vụ các yêu cầu**, không phải nguyên văn trong `php.ini`. Giá trị 8M và 4M là ví dụ để điều chỉnh khối lượng công việc. Chừa chỗ cho các trường biểu mẫu và ranh giới nhiều phần khi giới hạn toàn bộ yêu cầu POST. [S11](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-12)

```ini
; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off
```

Chỉ **PHP 8.5**, cộng thêm:

```ini
php_admin_flag[fatal_error_backtraces] = off
```

Chức năng và ranh giới của từng khu vực như sau:

| Cấu hình                              | hiệu quả mong đợi                                                                | Mô tả các hạn chế phải được giữ lại                                                                                                              |
| ------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `memory_limit=-1`                     | Loại bỏ điều kiện kích hoạt giới hạn trên bộ nhớ yêu cầu PHP có thể dự đoán được | Nó không ngăn chặn sự thất bại trong phân bổ cơ bản; việc hủy bỏ ngân sách ban đầu có thể làm tăng nguy cơ cạn kiệt bộ nhớ và gián đoạn dịch vụ. |
| `post_max_size` nhỏ hơn               | Giảm kích thước dữ liệu vào quá trình phân tích cú pháp                          | Trình phân tích cú pháp chưa được sửa có lỗ hổng đã biết; khuếch đại bộ nhớ không thể được ngăn chặn một cách độc lập                            |
| `upload_max_filesize < post_max_size` | Giới hạn kích thước tệp đơn và không gian dành riêng cho yêu cầu                 | Không hạn chế tất cả các trường, siêu dữ liệu hoặc phân bổ trong ứng dụng                                                                        |
| Đóng tiến trình tải lên               | Chặn đường dẫn liên quan đến phiên đã được xác nhận                              | Không bao gồm các biến thể trạng thái toàn cầu khác                                                                                              |
| PHP 8.5 đóng dấu vết chết người       | Chặn các nhà sản xuất trạng thái liên quan được xác nhận                         | Không bao gồm các đường dẫn khác như phiên                                                                                                       |

Ranh giới đo đến từ thông báo chính thức; để biết cú pháp nhóm và ngữ nghĩa cấu hình cấp quản lý, hãy xem hướng dẫn sử dụng PHP. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-11)

Các cài đặt `php_admin_*` cấp quản lý không thể bị ghi đè bởi các ứng dụng thông qua `ini_set()`. Tất cả các cấu hình đến ở cấp độ thư mục, cấp thư mục và giao diện người dùng vẫn phải được xem xét để xác nhận rằng các giá trị trên các yêu cầu thực tế là như mong đợi. Sau khi sửa đổi, hãy xây dựng lại tất cả công nhân để ngăn các quy trình hiện có tiếp tục giữ trạng thái cũ.

Nếu bạn chọn sửa đổi trực tiếp `php.ini`, cú pháp sẽ được thay đổi thành:

```ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off
```

Không giống như `php_admin_value` trong nhóm, việc chỉ đặt `memory_limit=-1` trong `php.ini` không ngăn ứng dụng sửa đổi lại. Cần kiểm tra khung, mã ứng dụng và các cấu hình khác để xem liệu chúng có đặt lại giá trị giới hạn hay không; khi cần thực thi, hãy sử dụng cài đặt cấp quản lý phù hợp cho SAPI hiện tại và kiểm tra giá trị hiệu quả thực tế. [S11](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-12)

Chỉ thêm `fatal_error_backtraces = Off` cho PHP 8.5. Không sử dụng `ini_set()` cấp ứng dụng như một giải pháp thay thế cho việc vô hiệu hóa tiến trình tải lên và không dựa vào FPM `.user.ini` để làm cho nó có hiệu quả trước khi yêu cầu phân tích cú pháp. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)

### 5.3 Quản lý chi phí loại bỏ giới hạn bộ nhớ PHP

`memory_limit=-1` là giải pháp giảm thiểu đường dẫn tạm thời cho các môi trường chưa được trộn và không được sao chép dưới dạng cấu hình mặc định dài hạn. Khi một ứng dụng hoặc yêu cầu vượt khỏi tầm kiểm soát, nó có thể sử dụng nhiều bộ nhớ của máy chủ hơn. Do đó, trước khi sử dụng, bạn nên đánh giá số lượng đồng thời, công suất đơn cao nhất và tổng công suất dịch vụ, đồng thời triển khai các giới hạn đầu vào của giao diện người dùng. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

Giới hạn bộ nhớ vùng chứa hoặc nhóm có thể cung cấp ranh giới khả dụng nhưng không đảm bảo rằng việc phân bổ sẽ không bao giờ thất bại; toàn bộ container, master và tất cả worker cũng có thể bị chấm dứt khi giới hạn được kích hoạt. Các chiến lược chấm dứt và chi tiết cách ly cần được đánh giá cùng với quá trình triển khai và không thể gọi là bảo vệ hoàn toàn cho hai CVE này. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

Không thay thế các chiến lược trên bằng `RLIMIT_AS`, `RLIMIT_DATA` hoặc các hạn chế về không gian địa chỉ quy trình tương ứng; chúng có thể trực tiếp khiến việc phân bổ cơ bản không thành công trên đường dẫn OOM vẫn còn có vấn đề. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)

### Ví dụ về cấu hình 5.4 Nginx

Áp dụng cho việc triển khai trong đó Nginx chuyển tiếp yêu cầu đến PHP-FPM. Nó có thể được đặt ở cấp cấu hình của dịch vụ lưu trữ thực tế:

```nginx
client_max_body_size 8m;
fastcgi_request_buffering on;
```

`client_max_body_size` giới hạn kích thước nội dung yêu cầu; `fastcgi_request_buffering on` cho phép Nginx đọc nội dung yêu cầu hoàn chỉnh trước rồi gửi nó đến phần phụ trợ FastCGI. Việc nó có hiệu lực trong một `server` hoặc `location` nhất định hay không cần phải được kiểm tra cùng với các mối quan hệ kế thừa và bảo hiểm hiện có. [S13](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-14)

**Chỉ khi doanh nghiệp không cần multipart**, bạn mới có thể thêm quy tắc từ chối vào lối vào dịch vụ tương ứng:

```nginx
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}
```

Đây là mẫu hạn chế mục nhập đơn giản sử dụng `if` và `return`, không phải là quy tắc lọc chung cho các lỗ hổng của trình phân tích cú pháp. Xác minh cú pháp cấu hình và các yêu cầu thông thường trước khi triển khai, đồng thời kiểm tra xem `error_page` tùy chỉnh có chuyển hướng 403 yêu cầu đến PHP hay không. Việc so khớp chuỗi không cung cấp sự đảm bảo đầy đủ về tất cả các khác biệt về phân tích cú pháp. [S15](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-15)

Ngoài ra, các cấu hình này không tự động giới hạn lượng dữ liệu, số lượng trường hoặc số lượng đối tượng PHP mà ứng dụng có thể giải nén; doanh nghiệp cần tải lên nên sử dụng các hạn chế bổ sung để hiểu cấu trúc yêu cầu của họ.

### 5.5 Giảm thiểu tùy chọn: một yêu cầu cho mỗi nhân viên FPM

Đối với các triển khai FPM có đủ khả năng chi trả, có thể đánh giá các thiết lập ngắn hạn:

```ini
pm.max_requests = 1
```

Và xây dựng lại công nhân hiện có. Nó chặn chuỗi yêu cầu chéo được mô tả ở cấp độ tái sử dụng của nhân viên, nhưng sẽ làm tăng chi phí khởi tạo và tạo quy trình; đồng thời, nó không thể sửa chữa cùng một yêu cầu OOM và các vấn đề dọn dẹp của CVE-2026-109618. Khi giá trị nhỏ hơn nhưng lớn hơn 1 thì vẫn có cửa sổ sử dụng lại yêu cầu. [S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-11)

### Giới hạn vùng phủ sóng 5.6 WAF và Cloudflare

Cloudflare đã công bố các thỏa thuận triển khai để bảo vệ chống lại PHP2Shell, bao gồm cả gói Free. Khi sử dụng dịch vụ của nó, bạn nên kiểm tra xem lưu lượng truy cập thực tế có đi qua proxy hay không, liệu các quy tắc bảo vệ có hiệu lực hay không và liệu trang gốc có thể được bỏ qua trực tiếp hay không; đối với gói trả phí, bạn cũng cần kiểm tra cấu hình và ngoại lệ của Quy tắc được quản lý tương ứng. [S16](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-16)

Một số phát hiện được nhà cung cấp mô tả sử dụng tín hiệu phản hồi, do đó, tất cả các biện pháp bảo vệ không thể được hiểu là "mọi cuộc tấn công đều bị chặn trước khi tiếp cận PHP". WAF có thể giúp giảm mức độ phơi nhiễm và cung cấp thông tin quan sát, nhưng việc tiếp tục nâng cấp lên PHP vẫn là cần thiết. [S16](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-16)

### 5.7 Tại sao các biện pháp thông thường là không đủ

| biện pháp hoặc phán quyết                                 | những thiếu sót                                                                                                                             |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| Chỉ đóng `file_uploads`                                   | Không thể bao gồm tất cả quá trình xử lý nhiều phần và áp dụng đường dẫn OOM của riêng nó                                                   |
| Cài đặt `enable_post_data_reading=Off`                    | Thay đổi hành vi tự động điền POST/FILES; ứng dụng vẫn có thể đọc nội dung yêu cầu và có thể làm gián đoạn hoạt động kinh doanh bình thường |
| Tắt hiển thị lỗi, ghi nhật ký hoặc sử dụng `@`            | Xử lý chẩn đoán nội bộ vẫn có thể truy cập trạng thái lơ lửng                                                                               |
| Tăng số lượng công nhân                                   | Không thiết lập cơ chế dọn dẹp trạng thái an toàn, cũng như không loại bỏ việc tái sử dụng một công nhân                                    |
| Chỉ định cấu hình `disable_functions` hoặc `open_basedir` | Những hạn chế này không khắc phục được lỗi hỏng bộ nhớ lớp công cụ C                                                                        |
| Chỉ kiểm tra một phiên bản hoặc một bản sao một lần       | Không thể chứng minh rằng tất cả các lối vào và phiên bản đang chạy đã được thay thế                                                        |
| Không có nhật ký ngoại lệ nào được nhìn thấy              | Nó không thể chứng minh rằng lỗ hổng không tồn tại hoặc nó chưa được khai thác trước đó.                                                    |

Trong số đó, cơ sở cấu hình và cơ chế dễ bị tổn thương của PHP có thể được tìm thấy trong [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-12); các đánh giá về ranh giới phạm vi, sự chấp nhận và quyền được dựa trên các đề xuất thực hiện do các cơ chế này đưa ra.

## 6. Ý tưởng triển khai và điểm đánh giá của bản vá chính thức

### 6.1 Sử dụng các bản sửa lỗi hoàn chỉnh cho đúng nhánh

Bài nộp chính thức đại diện cho PHP 8.5 là:

```text
31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout
```

Cam kết liên kết rõ ràng hai CVE, cả hai đều để điều chỉnh cơ chế thoát OOM và khắc phục trạng thái chung có thể được truy cập trong giai đoạn khởi tạo. Gửi trang có đầy đủ khác biệt, xem [S4](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5). Các nhánh khác nên sử dụng các bản phát hành bảo mật chính thức hoặc các bản vá phù hợp của riêng họ và không thể cho rằng những thay đổi đối với 8.5 có thể được áp dụng trực tiếp cho bất kỳ phiên bản cũ nào.

### 6.2 OOM Repair: khôi phục trạng thái có thể xử lý trước, sau đó chấm dứt yêu cầu

Việc triển khai chính thức giới thiệu hai cấp độ xử lý OOM mềm và cứng: khi đạt đến giới hạn mềm, trạng thái chờ xử lý sẽ được ghi lại và việc thoát có kiểm soát được thực hiện tại một vị trí an toàn như VM; giao diện phân bổ lỗi cho phép người gọi xử lý lỗi một cách rõ ràng. Đối với các hoạt động phân bổ không thể trực tiếp trả về lỗi, nếu dự kiến ​​sẽ vượt quá ngưỡng cứng cao hơn thì quy trình sẽ bị chấm dứt trực tiếp để tránh tiếp tục xử lý các yêu cầu ở trạng thái trung gian không an toàn. [S2](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

Sau đây là đoạn trích mã khóa trong 8.5 diff được sử dụng để đánh dấu OOM đang chờ xử lý:

```c
EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);
```

Xử lý ngắt VM và các vị trí an toàn khác sau đó gọi `zend_handle_delayed_oom()`. Bối cảnh thực thi mã người dùng của nó sử dụng đường dẫn thư giãn được kiểm soát; đường dẫn OOM cứng gọi `_exit(137)`. [S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

Từ góc độ thiết kế, những thay đổi quan trọng là: **Z tránh tùy ý vượt qua ngăn xếp cuộc gọi C khi cấu trúc ở trạng thái trung gian và đặt lối ra tại vị trí** có thể duy trì các ràng buộc trạng thái. Sau khi giới hạn mềm được kích hoạt, bộ nhớ bổ sung có thể được yêu cầu để hoàn tất quy trình, do đó, ngưỡng mềm mới không thể được hiểu là giới hạn trên tuyệt đối cho tổng bộ nhớ của quy trình.

Cũng không thể tóm tắt là "PHP đã xóa tất cả `zend_bailout()`". Bản vá vẫn sử dụng các cơ chế liên quan trong các bối cảnh cụ thể; điều được khắc phục là thời điểm thoát hiểm nguy hiểm và sự quản lý nhà nước đi kèm. [S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

### 6.3 Cập nhật các lệnh gọi phân bổ và phân tích cú pháp nhiều phần cùng nhau

Nếu bạn chỉ thay đổi hàm phân bổ thành "trả về NULL khi thất bại" và người gọi ban đầu vẫn cho rằng một con trỏ hợp lệ luôn được trả về, thì bạn sẽ đưa ra các quyền truy cập con trỏ null mới hoặc dọn dẹp không đầy đủ. Giao diện phân bổ lỗi trong bản vá cần được xem xét cùng với việc kiểm tra người gọi và truyền bá ngoại lệ. [S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

Các bản sửa lỗi liên quan đến nhiều phần cũng bao gồm thực hiện kiểm tra tích lũy dựa trên khối lượng đọc thực tế, giảm việc xử lý các tiêu đề vô dụng hoặc trùng lặp, đồng thời áp dụng logic thoát và dọn dẹp nhất quán khi OOM đang chờ xử lý. Những thay đổi này vừa làm giảm khả năng khuếch đại tài nguyên vừa khiến trình phân tích cú pháp tuân thủ giao thức OOM mới. [S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

Đối với các nhóm duy trì các chi nhánh của riêng mình, các vấn đề sau đây nên là trọng tâm của việc xem xét mã:

- Trạng thái có hiển thị với thế giới bên ngoài trước khi nó được khởi tạo hoàn toàn không?
- Sau khi phân bổ không thành công hoặc ngoại lệ gọi lại, quyền sở hữu có còn duy nhất và rõ ràng không?
- Bạn có thể đạt được lối thoát dọn dẹp thống nhất nếu thất bại giữa chừng không?
- Chức năng dọn dẹp có thể nhận ra các trường chưa được khởi tạo hoặc đã giải phóng không?
- Ngân sách phân tích cú pháp có dựa trên khối lượng xử lý thực tế chứ không chỉ dựa trên các yêu cầu yêu cầu tin cậy không?
- Giá trị trả về lỗi mới đã được tất cả người gọi xử lý chưa?

Đây là những câu hỏi đánh giá được tóm tắt dựa trên cơ chế khắc phục và không phải là kết luận của quá trình kiểm tra đã được hoàn thành đối với cơ sở mã không được cung cấp.

### 6.4 Khắc phục yêu cầu chéo: khởi tạo sớm hơn, dọn dẹp lần cuối sau

Tương ứng với CVE-2026-109619, bản vá điều chỉnh nhiều ranh giới vòng đời cùng một lúc. Các tệp và thao tác được liệt kê bên dưới lấy khác biệt chính thức của PHP 8.5 làm ví dụ. [S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

| vị trí                                           | đổi hướng                                                                     | Đã giải quyết vấn đề                                                                                    |
| ------------------------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `Zend/zend_execute_API.c`, v.v.                  | Đặt lại trạng thái thực thi như lỗi, ngoại lệ, trình xử lý, đối tượng, v.v.   | Sau khi yêu cầu kết thúc, vẫn còn các tài liệu tham khảo cũ có thể được truy cập bởi yêu cầu tiếp theo. |
| Đường dẫn khởi động của `main/main.c`            | Gọi `php_basic_early_rinit()` trước khi SAPI được kích hoạt                   | Khi một người tiêu dùng sớm xuất hiện, trạng thái cơ bản có liên quan vẫn chưa được khởi tạo.           |
| Đóng đường dẫn của `main/main.c`                 | Phá hủy HTTP globals và đánh dấu nó là không xác định                         | Giá trị được phát hành vẫn được coi là một đối tượng hợp lệ                                             |
| trước khi đống yêu cầu cuối cùng được giải phóng | Dọn dẹp thông báo lỗi cuối cùng một lần nữa                                   | Chẩn đoán dọn dẹp muộn khôi phục lại trạng thái lỗi                                                     |
| `ext/session/session.c`                          | tiến trình tải lên Đường dẫn ban đầu được khởi tạo toàn cầu phiên đầu tiên    | Mô-đun thông thường RINIT đã truy cập trạng thái cũ trước đây                                           |
| Mã liên quan đến tuần tự hóa                     | Hạn chế phân tích cú pháp lớp và gọi lại người dùng trong quá trình xử lý sớm | Thực thi mã người dùng bổ sung khi quá trình khởi tạo chưa hoàn tất                                     |

Ví dụ: trình tự khởi động bao gồm:

```c
zend_activate();
php_basic_early_rinit();
sapi_activate();
```

Sau khi HTTP globals bị phá hủy, hãy thêm dấu lỗi trạng thái:

```c
zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);
```

Những đoạn trích này minh họa hai nguyên tắc: **khởi tạo trước người tiêu dùng sớm nhất có thể và thực hiện dọn dẹp cuối cùng sau thao tác cuối cùng có thể tạo lại trạng thái.** Chỉ đặt lại con trỏ trong RINIT bình thường hoặc giai đoạn tắt máy trước đó có thể bỏ lỡ các truy cập sớm hơn hoặc muộn hơn. [S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

### 6.5 Tại sao không nên tự thực hiện "sửa chữa một dòng"?

Việc thay thế tất cả `zend_bailout()` bằng `_exit()` hoặc chỉ thêm kiểm tra con trỏ null vào một mục nhập nhất định sẽ mở rộng một số lượng lớn các bối cảnh thực thi khác nhau. Họ có thể bỏ qua các trường trạng thái khác hoặc có thể thay đổi việc hủy, gọi lại mở rộng, lưu trữ quy trình và ngữ nghĩa cuối yêu cầu.

Đối với các phiên bản được hỗ trợ, các bản sửa lỗi đầy đủ đã được phát hành sẽ được ưu tiên. Quá trình di chuyển của các nhánh riêng phải ghi lại nguồn của các bản vá, đường cơ sở có thể áp dụng, xử lý xung đột và thay đổi hành vi, đồng thời sử dụng các trường hợp sử dụng hồi quy ngược dòng tương ứng và xác minh quy trình kinh doanh này. Các đề xuất ở đây xuất phát từ việc phân tích phạm vi của bản vá trên các thay đổi trong vòng đời của bộ cấp phát, VM, phiên và yêu cầu. [S4](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-5)

## 7. Cổng hỗ trợ khẩn cấp của PHP 7.4, 8.0, 8.1

PHP chính thức cung cấp backport mã nguồn tối thiểu của ba nhánh cũ dựa trên mức độ nghiêm trọng. Tên chi nhánh là:

```text
PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619
```

Để biết các liên kết nhánh, hãy xem [S7](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-9). Đây là những đợt cung cấp khẩn cấp cho lỗ hổng này và không thể hiện sự quay trở lại hỗ trợ ngược dòng thường xuyên cho nhánh cũ cũng như không thay thế các bản cập nhật bảo mật khác. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)

### 7.1 Lấy cổng sau PHP 8.1 làm ví dụ

Các nội dung gửi có liên quan cho PHP 8.1 là:

```text
1d7dec178a094e6e75b229ce22754045f8c6070a
```

Chiến lược của nó thiên về lỗi nhanh: gọi `_exit(1)` sau khi xuất chẩn đoán trong đường dẫn OOM tương ứng, đồng thời bao gồm trạng thái toàn cầu và các chỉnh sửa có liên quan khác; đồng thời vô hiệu hóa nội bộ quá trình xử lý tương ứng của tiến trình tải lên phiên. Để gửi mã nguồn có liên quan, hãy xem [S6](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-6).

Đây là điểm khác biệt về hành vi so với thiết kế OOM bị trì hoãn hoàn chỉnh hơn trong nhánh được hỗ trợ. Chỉ vì cấu hình vẫn hiển thị tiến trình tải lên đang bật, không có nghĩa là hành vi xử lý nội bộ sau cổng sau này sẽ không thay đổi.

### 7.2 Cái giá bạn cần chấp nhận khi triển khai

Việc trực tiếp thoát khỏi quy trình có thể khiến yêu cầu hiện tại không thành công, bỏ qua các cuộc gọi lại tắt máy PHP thông thường và một phần của việc đóng ứng dụng; nếu máy chủ áp dụng mô hình luồng, thì cũng cần phải đánh giá tác động của việc thoát toàn bộ quá trình máy chủ đối với công việc đồng thời khác. Việc người quản lý quy trình có thể đưa ra quy trình thay thế kịp thời hay không cũng cần được đưa vào quá trình xác minh.

Vì vậy, người dùng các phiên bản cũ hơn nên cân nhắc theo thứ tự:

1. Di chuyển sang nhánh PHP được hỗ trợ và phiên bản cố định của nó.
2. Sử dụng bản phát hành bao gồm rõ ràng cả bản cập nhật của nhà sản xuất CVE hoặc LTS.
3. Nếu nó thực sự tuân theo phiên bản cũ của mã nguồn, hãy sử dụng cổng sau khẩn cấp chính thức của phiên bản phù hợp để xác minh các thay đổi hoàn chỉnh và tính tương thích, đồng thời sắp xếp quá trình di chuyển tiếp theo.

"Cập nhật tối thiểu" ở đây mô tả khả năng tương thích và phạm vi triển khai do quan chức lựa chọn và không được tự động hiểu là "các bản sửa lỗi lỗ hổng chưa hoàn chỉnh đã biết". Bạn nên đánh giá dựa trên mã nguồn của chi nhánh tương ứng và thông báo của nhà sản xuất, không tự ý xóa các thay đổi hỗ trợ. [S1](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/vi/insights/php2shell-remediation-guide#source-6)

## 8. Tiêu chí chấp nhận và kiểm tra tiếp theo

Nên sử dụng các kết quả sau làm cơ sở để hoàn thành việc sửa chữa này:

| Mặt hàng chấp nhận              | Tiêu chuẩn hoàn thành                                                                                                                |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| bảo hiểm lỗ hổng                | Thông báo về bản dựng hoặc nhà cung cấp khắc phục rõ ràng CVE-2026-109618 và CVE-2026-109619                                         |
| Phạm vi triển khai              | Tất cả các cổng, nhóm, dịch vụ và bản sao đều sử dụng thời gian chạy đã sửa chữa                                                     |
| Quá trình có hiệu lực           | Worker cũ, tiến trình máy chủ cũ và vùng chứa cũ đều thoát                                                                           |
| Xác thực yêu cầu xác thực       | Đã xác nhận SAPI, được xây dựng và định cấu hình với liên kết Web thực tế để loại bỏ việc định hướng sai bộ đệm                      |
| tính khả dụng của doanh nghiệp  | Các chức năng chính như phiên, tải lên, nhập và xử lý lỗi đã hoạt động bình thường.                                                  |
| Chấm dứt các biện pháp tạm thời | Bộ nhớ không giới hạn và cấu hình tái chế nhân công cực cao đã được khôi phục theo kế hoạch dung lượng hoặc có lý do giữ lại rõ ràng |
| Bằng chứng về sự thay đổi       | Ghi lại phiên bản gói hoặc thông báo hình ảnh, phạm vi cập nhật, thời gian hoàn thành và kết quả xác minh                            |

Trên đây là những gợi ý để thực hiện. Nếu cần xác minh hành vi của OOM, lối thoát bất thường hoặc các bản vá tùy chỉnh, bạn nên sử dụng thử nghiệm hồi quy ngược dòng hoặc chèn lỗi có kiểm soát trong môi trường biệt lập để tránh liên tục tạo ra tình trạng cạn kiệt bộ nhớ trong môi trường sản xuất như một phương pháp chấp nhận.

Đồng thời kiểm tra PHP gây tử vong, sự cố của nhân viên, khởi động lại bất thường, tỷ lệ lỗi yêu cầu và các sự kiện WAF trước và sau khi cập nhật. Nhật ký chỉ có thể cung cấp manh mối điều tra: sự xuất hiện của OOM không có nghĩa là nó đã bị khai thác và việc thiếu cảnh báo không chứng minh rằng không có hoạt động khai thác nào xảy ra. Bản nâng cấp sửa các đường dẫn dễ bị tổn thương có thể xảy ra trong tương lai; nếu phát hiện thấy những điều bất thường như giả mạo tệp hoặc rò rỉ thông tin xác thực thì cần tiến hành điều tra sự cố riêng biệt.

## Phụ lục: Nguồn và link được trích dẫn

Tất cả các liên kết nguồn được thu thập dưới đây. Các tư vấn, bản vá và hướng dẫn của nhà cung cấp phản ánh các bước kiểm tra kể từ **O ngày 22 tháng 10 năm 2026**; những lần triển khai tiếp theo nên kiểm tra các bản cập nhật của nhà cung cấp. Các trích dẫn được đánh số trong văn bản đề cập đến các mục này.

### S1 — Phiên bản sửa chữa và bản tin bảo mật chính thức của PHP

- Nguồn: Dự án PHP, ngày 21 tháng 10 năm 2026.
- Mục đích: Phạm vi rủi ro, bốn phiên bản sửa chữa chính thức, các biện pháp tạm thời chính thức và hướng dẫn quay trở lại khẩn cấp cho các chi nhánh cũ.
- Nguồn tham khảo: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) có trong kho lưu trữ bản tin hàng năm

### S2 — Bản tin kỹ thuật chính thức của CVE-2026-109618

- Nguồn: php/php-src GitHub Security Advisory, ngày 21 tháng 10 năm 2026.
- Nhận dạng: GHSA-w8hw-w9fx-j79w.
- Mục đích: Ranh giới phủ sóng cho OOM, khuếch đại nhiều phần, sự khác biệt và giảm thiểu SAPI.
- Nguồn tham khảo: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

### S3 — Bản tin kỹ thuật chính thức của CVE-2026-109619

- Nguồn: php/php-src GitHub Security Advisory, ngày 21 tháng 10 năm 2026.
- Nhận dạng: GHSA-6wmf-4rv5-p3rp.
- Mục đích: Trạng thái treo yêu cầu chéo, nhà sản xuất và người tiêu dùng, khởi tạo sớm, giảm thiểu cấu hình.
- Nguồn tham khảo: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)

### S4 — Gửi bản sửa lỗi chính thức của PHP 8.5

- Nguồn: php/php-src.
- Gửi: `31c0ea7d7ff1d1fccb6492e52dab544011628065`.
- Mục đích: Xác nhận việc gửi chính thức để khắc phục hai lỗ hổng cùng lúc và giải thích hướng thay đổi tổng thể.
- Nguồn tham khảo: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065)

### S5 — PHP 8.5 Chính thức được khôi phục và hoàn thiện khác biệt

- Nguồn: khác với cùng một bản đệ trình chính thức.
- Mục đích: Kiểm tra việc triển khai cụ thể của bộ cấp phát, VM, HTTP globals, phiên, tuần tự hóa và vòng đời yêu cầu.
- Nguồn tham khảo: [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff)

### S6 - Gửi backport khẩn cấp chính thức của PHP 8.1

- Nguồn: php/php-src.
- Gửi: `1d7dec178a094e6e75b229ce22754045f8c6070a`.
- Mục đích: Kiểm tra việc thoát nhanh của các nhánh cũ và tải lên các thay đổi về hành vi tiến trình.
- Nguồn tham khảo: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a)
- Nguồn tham khảo: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff)

### S7 - Chi nhánh cổng sau khẩn cấp chính thức của PHP 7.4

- Nguồn: Các nhánh mã nguồn php/php-src, PHP được liệt kê trong bản tin bảo mật chính thức.
- Nguồn tham khảo: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619)

### S8 - Chi nhánh cổng sau khẩn cấp chính thức của PHP 8.0

- Nguồn: Các nhánh mã nguồn php/php-src, PHP được liệt kê trong bản tin bảo mật chính thức.
- Nguồn tham khảo: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619)

### S9 - Chi nhánh cổng sau khẩn cấp chính thức của PHP 8.1

- Nguồn: Các nhánh mã nguồn php/php-src, PHP được liệt kê trong bản tin bảo mật chính thức.
- Nguồn tham khảo: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619)

### S10 — Bản tin bảo mật Ubuntu USN-8948-1

- Nguồn: Canonical / Ubuntu, ngày 21 tháng 10 năm 2026.
- Mục đích: Phát hành bản backport và các ví dụ về phiên bản gói hoàn chỉnh.
- Nguồn tham khảo: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1)

### S11 — Hướng dẫn sử dụng PHP-FPM Configuration

- Nguồn: Tài liệu chính thức của PHP.
- Mục đích: Ngữ nghĩa cấu hình như `php_admin_value`, `php_admin_flag`, `pm.max_requests`, v.v.
- Nguồn tham khảo: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php)

### S12 — Hướng dẫn cấu hình PHP Core INI

- Nguồn: Tài liệu chính thức của PHP.
- Mục đích: Định nghĩa và phạm vi của nội dung yêu cầu, tải lên, bộ nhớ và cấu hình đọc POST tự động.
- Nguồn tham khảo: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php)

### S13 — Giới hạn kích thước nội dung yêu cầu Nginx

- Nguồn: Tài liệu chính thức của Nginx.
- Mục đích: Ý nghĩa của `client_max_body_size` và các mức cấu hình có sẵn.
- Nguồn tham khảo: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)

### S14 — Bộ đệm yêu cầu Nginx FastCGI

- Nguồn: Tài liệu chính thức của Nginx.
- Mục đích: Trình tự xử lý và chức năng của `fastcgi_request_buffering`.
- Nguồn tham khảo: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering)

### S15 — Nginx Hướng dẫn tình trạng và hoàn trả

- Nguồn: Tài liệu chính thức của Nginx.
- Mục đích: Cú pháp cấu hình của `if` và `return`.
- Nguồn tham khảo: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if)

### S16 — Hướng dẫn bảo vệ Cloudflare PHP2Shell

- Nguồn: blog chính thức của Cloudflare.
- Mục đích: Mô tả phạm vi triển khai WAF, cơ chế phát hiện và sắp xếp kế hoạch Free.
- Nguồn tham khảo: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)

## Tư vấn bảo trì an ninh

Cần trợ giúp cập nhật hệ thống PHP của bạn? Chúng tôi có thể đánh giá mức độ phơi nhiễm, lập kế hoạch cập nhật và xác minh ứng dụng đang chạy.

[Thảo luận về các cập nhật bảo mật](<https://keendigit.com/vi/contact?service=security-remediation#form>)

[Trang gốc](<https://keendigit.com/vi/insights/php2shell-remediation-guide>) · [chỉ mục nội dung](<https://keendigit.com/vi/llms.txt>)

KeenDigit LLC · ID hồ sơ Wyoming: 2026-002106155

[Xác minh với Bộ trưởng Ngoại giao Wyoming](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · Sheridan, Wyoming, Hoa Kỳ · Mọi quyền được bảo lưu.