PHP2Shell là tên gọi của các lỗ hổng nghiêm trọng trong PHP được công bố ngày 21 tháng 10 năm 2026. Nếu website của bạn chạy PHP, câu hỏi cần trả lời ngay là môi trường thực thi đang phục vụ khách truy cập đã có bản sửa lỗi bảo mật hay chưa. Cập nhật plugin hoặc nhìn thấy bảng điều khiển tường lửa hiển thị màu xanh không trả lời được câu hỏi đó.
PHP2Shell ảnh hưởng đến môi trường thực thi PHP bên dưới website và có thể cho phép thực thi mã từ xa mà không cần xác thực. PHP đã phát hành các bản sửa lỗi trong 8.2.35, 8.3.36, 8.4.27 và 8.5.12, và bạn cần xác nhận phiên bản đã sửa hoặc bản vá ngược được nhà cung cấp ghi nhận trong môi trường thực sự phục vụ yêu cầu web. Duy trì các biện pháp phòng vệ, nhưng đừng xem WAF hay thay đổi cấu hình tạm thời là giải pháp thay thế việc vá lỗi.
Trạng thái được kiểm tra: ngày 21 tháng 10 năm 2026, 17:15 UTC. Hướng dẫn này phản ánh các bản sửa lỗi đã công bố, thay vì thông báo trước đó rằng bản phát hành vẫn đang chờ. Hãy kiểm tra lại các khuyến cáo được liên kết trước khi thay đổi vì gói phần mềm của nhà cung cấp và hướng dẫn ứng phó có thể thay đổi nhanh chóng.
PHP2Shell: điều gì đã thực sự được xác nhận?
Nhóm bảo mật PHP xác định hai lỗ hổng có thể cho phép thực thi từ xa mà không cần đăng nhập. Khuyến cáo chính thức cho biết các bản cài PHP phục vụ yêu cầu web có rủi ro và nhấn mạnh Apache dùng mod_php là cấu hình có rủi ro cao nhất. Môi trường thực thi, bản dựng và môi trường xử lý yêu cầu đều ảnh hưởng đến khả năng khai thác.
| Mã định danh | Mô tả của PHP | Rủi ro thực tế |
|---|---|---|
| CVE-2026-109618 | Hỏng dữ liệu do hết bộ nhớ khi dọn dẹp yêu cầu | Trạng thái yêu cầu không hợp lệ có thể bị sử dụng khi PHP xử lý lỗi cấp phát |
| CVE-2026-109619 | Trạng thái toàn cục cũ thuộc về yêu cầu | Yêu cầu tiếp theo trên cùng tiến trình worker có thể gặp tham chiếu đến bộ nhớ đã giải phóng |
Cả hai khuyến cáo đều có điểm CVSS v4.0 là 9.2. Đọc báo cáo gốc về CVE-2026-109618 và CVE-2026-109619 , thay vì dựa vào biện pháp khắc phục tạm thời được đề xuất trong một bài đăng mạng xã hội.
Đây là lý do để hành động kịp thời, không phải bằng chứng rằng mọi website PHP đều đã bị xâm nhập. Lỗ hổng nghiêm trọng, nỗ lực tấn công và vụ xâm nhập đã xác nhận là những kết luận khác nhau. Quá trình ứng phó cần xác định tình huống nào áp dụng cho hệ thống của bạn.
Phiên bản PHP nào khắc phục PHP2Shell?
Các bản phát hành bảo mật cho những nhánh còn được hỗ trợ, công bố hôm nay, được liệt kê dưới đây. Bảng phiên bản là điểm khởi đầu để kiểm tra bản cài từ dự án gốc. Gói của các bản phân phối có thể chứa bản sửa lỗi dưới số hiệu chỉnh gói khác.
| Nhánh PHP | Bản phát hành bảo mật sửa cả hai lỗ hổng |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Các phiên bản này được xác nhận trong thông báo phát hành PHP . Nếu nhà cung cấp bản phân phối hoặc dịch vụ lưu trữ dùng bản vá ngược, hãy yêu cầu thông báo bảo mật và số hiệu chỉnh chính xác của gói đã cài. Chỉ một chuỗi phiên bản có thể khiến bạn phân loại sai gói của nhà cung cấp đã được vá hoặc môi trường PHP đi kèm nhưng đã lỗi thời.
PHP 8.1 trở về trước không còn nhận cập nhật upstream thông thường. PHP cũng cung cấp bản vá ngược mã nguồn tối thiểu cho 7.4, 8.0 và 8.1, nhưng điều này không khôi phục hỗ trợ liên tục. Hãy xác định bản sửa được nhà cung cấp chịu trách nhiệm hỗ trợ hoặc lập kế hoạch nâng cấp. Bảng hỗ trợ PHP giải thích tình trạng hỗ trợ hiện tại của các nhánh.
Kiểm tra riêng container, bản cài PHP nhúng và thiết bị tích hợp. Hướng dẫn vận hành của NCSC-NL cảnh báo rõ rằng cập nhật PHP trên máy chủ nền không nhất thiết cập nhật các môi trường thực thi đó.
WordPress, Laravel và các website PHP khác có bị ảnh hưởng không?
Bắt đầu từ trình thông dịch đang chạy ứng dụng. Một website WordPress, ứng dụng Laravel và cổng PHP tùy chỉnh có thể dùng chung môi trường thực thi lỗi thời dù mã ứng dụng hoàn toàn khác nhau. Cài phiên bản mới nhất của giao diện, plugin hoặc framework không cài bản sửa bảo mật cho môi trường thực thi PHP.
Với dịch vụ lưu trữ được quản lý, hãy hỏi phiên bản PHP hoặc gói đã vá nào đang phục vụ từng website, thay đổi đã tới mọi nút chưa và các tiến trình worker đã khởi động lại ở nơi cần thiết chưa. Yêu cầu bằng chứng từ nền tảng lưu trữ thay vì xem thông báo cập nhật ứng dụng là xác nhận đã xử lý.
Với hệ thống tự quản lý, hãy đưa website phụ, giao diện quản trị, máy chủ ảo cũ và môi trường xem trước vào danh sách kiểm kê. Ứng dụng chính có thể được cập nhật trong khi website cũ vẫn truy cập công khai trên cùng hạ tầng. Ghi rõ người phụ trách và quyết định khắc phục cho từng môi trường bị lộ ra ngoài.
Đừng suy luận rằng biểu mẫu tải lên không được sử dụng sẽ khiến một triển khai trở nên an toàn. Các khuyến cáo PHP mô tả đường xử lý yêu cầu trong môi trường thực thi. Những tính năng ứng dụng mà khách truy cập nhìn thấy không phải là đánh giá đầy đủ về mức độ phơi nhiễm.
Cách vá và xác minh môi trường đang phục vụ khách truy cập
Xác định những gì thực sự đang chạy
Xác định cách tích hợp với máy chủ web, gói môi trường thực thi hoặc ảnh container, nguồn cấu hình và người phụ trách dịch vụ. Liên hệ danh sách kiểm kê đó với tên máy chủ mà khách hàng sử dụng. Kỹ sư kiểm tra nhầm máy có thể tạo báo cáo phiên bản trông thuyết phục nhưng không liên quan.
Các lệnh chỉ đọc sau xác định bản cài dòng lệnh và cấu hình của nó:
1php -v
2php --ini
Chúng không chứng minh PHP-FPM, Apache hay một phương thức tích hợp phục vụ web khác đang chạy gì. Dùng thông tin lưu trữ đã xác thực hoặc kiểm tra quản trị có kiểm soát để xác định môi trường đang phục vụ yêu cầu. Không để lại trang chẩn đoán công khai làm lộ cấu hình và chi tiết môi trường.
Với triển khai container, xác minh ảnh và phiên bản ứng dụng thực sự nhận lưu lượng, không chỉ ảnh thay thế trong kho đăng ký. Đưa tất cả phiên bản chạy phía sau bộ cân bằng tải và mọi dịch vụ worker riêng vào hồ sơ thay đổi.
Áp dụng bản sửa được hỗ trợ và kiểm thử ứng dụng
Dùng quy trình cập nhật được ghi nhận của nguồn gói còn được duy trì hoặc nhà cung cấp ảnh. Ghi lại số hiệu chỉnh đã cài và thông báo của nhà cung cấp đề cập cả hai CVE. Lập kế hoạch khởi động lại dịch vụ hoặc thay thế phiên bản chạy theo cách triển khai, thay vì giả định việc tải gói sẽ thay đổi các tiến trình đang hoạt động.
Lưu giữ nhật ký liên quan trước những thay đổi có thể gián đoạn dịch vụ. Duy trì bản sao lưu đã xác minh và kế hoạch phục hồi, sau đó kiểm thử các luồng ứng dụng tiêu biểu sau khi cập nhật. Đăng nhập, phiên, thanh toán, tải lên và xử lý nền là những trường hợp hữu ích nếu ứng dụng sử dụng chúng.
Hoàn tất thay đổi bằng việc kiểm tra lại môi trường đang phục vụ yêu cầu. Giữ bằng chứng về những phiên bản chạy đã cập nhật, thời điểm chuyển lưu lượng và người chấp nhận kết quả kiểm tra ứng dụng. Tác vụ triển khai được đánh dấu thành công là bằng chứng hữu ích, nhưng không phải toàn bộ quá trình xác minh.
WAF Cloudflare có bảo vệ trước PHP2Shell không?
Cloudflare cho biết đã triển khai biện pháp WAF chống PHP2Shell cho khách hàng WAF Free và trả phí, đồng thời quan sát thấy lưu lượng tấn công. Thông báo mô tả các biện pháp xét thông tin của cả yêu cầu lẫn phản hồi. Cloudflare cũng khuyến nghị rõ khách hàng vá PHP dù đã có các biện pháp này.
Với từng website, xác nhận lưu lượng liên quan thực sự đi qua dịch vụ được bảo vệ và các quy tắc áp dụng đang được bật. Rà soát ngoại lệ, quy tắc bỏ qua và mọi máy chủ gốc có thể truy cập riêng. Đây là kiểm tra cách triển khai, không phải khẳng định thông báo của Cloudflare bảo đảm bảo vệ mọi đường có thể dẫn tới ứng dụng.
Giữ dữ liệu sự kiện WAF làm một phần của quá trình điều tra. Một yêu cầu bị chặn có thể xác định quy tắc đã khớp yêu cầu đó. Nó không chứng nhận rằng máy chủ gốc chưa từng được truy cập qua đường khác hoặc chưa có vụ xâm nhập trước đó.
Dùng WAF như một lớp phòng vệ bổ sung trong khi hoàn tất cập nhật môi trường thực thi. Không trì hoãn bản sửa PHP chỉ vì bảng điều khiển ghi nhận các nỗ lực bị chặn.
Biện pháp tạm thời không phải bản sửa PHP2Shell hoàn chỉnh
Nếu tạm thời chưa thể vá, hãy làm theo khuyến cáo PHP hiện tại cùng kỹ sư hoặc nhà cung cấp chịu trách nhiệm về hệ thống. Khuyến cáo về trạng thái cũ
giải thích vì sao việc tắt session.upload_progress.enabled phải diễn ra trước khi phân tích yêu cầu và đòi hỏi khởi động lại tiến trình worker. Khuyến cáo nêu rõ không dựa vào ini_set() hoặc .user.ini của FPM cho mục đích này.
Thay đổi đó chặn các đường liên quan đến phiên đã được xác nhận, không chặn mọi biến thể. PHP 8.5 còn có hướng dẫn riêng liên quan đến fatal_error_backtraces. Sao chép một đoạn cấu hình ngắn từ diễn đàn không chứng minh cả hai lỗ hổng đã được xử lý.
Khuyến cáo về hết bộ nhớ mô tả các kiểm soát khác, gồm giới hạn yêu cầu và thay đổi cách xử lý giới hạn bộ nhớ. Chúng có tác động đến tài nguyên và tính sẵn sàng. Đọc đầy đủ hướng dẫn cho triển khai thực tế thay vì tùy tiện bỏ giới hạn bộ nhớ trên máy chủ đang hoạt động.
Nếu không thể giảm mức phơi nhiễm đến mức chấp nhận được trước khi vá, hãy trao đổi về hạn chế truy cập công khai vào ứng dụng bị ảnh hưởng. Ghi lại biện pháp tạm thời, giới hạn của nó, người phụ trách và bản sửa lâu dài dự kiến. Giải pháp tạm cần điều kiện gỡ bỏ hoặc rà soát, không nên trở thành thiết lập vĩnh viễn không có tài liệu.
Nên giám sát điều gì sau khi kiểm tra mức độ phơi nhiễm?
Bắt đầu bằng trạng thái hoạt động chuẩn và lưu giữ khoảng thời gian cần xem xét. Đối chiếu yêu cầu web với sự kiện PHP, máy chủ web và máy chủ nền, thay vì xem một yêu cầu bất thường là chẩn đoán đầy đủ. Nếu thiếu nhật ký, ghi rõ hạn chế đó.
| Quan sát | Câu hỏi điều tra |
|---|---|
| Tiến trình PHP thoát bất ngờ hoặc lỗi bộ nhớ | Hành vi ứng dụng có thay đổi không và yêu cầu nào được xử lý gần thời điểm đó? |
| Tệp thực thi mới hoặc bị sửa | Có đợt triển khai được phê duyệt hay thao tác ghi chưa giải thích được không? |
| Tiến trình con hoặc kết nối ra ngoài bất ngờ | Tiến trình web có lý do hợp lệ cho hoạt động đó không? |
| Phát hiện WAF và bản ghi truy cập máy chủ gốc | Yêu cầu nào bị chặn và đường nào đã tới máy chủ gốc? |
| Thay đổi tài khoản, tác vụ định kỳ hoặc thông tin bí mật | Có thể gắn từng thay đổi với một người vận hành được ủy quyền không? |
Đây là gợi ý điều tra, không phải chỉ dấu riêng của PHP2Shell hay bằng chứng đã bị xâm nhập. Hoạt động thông thường cũng có thể tạo triệu chứng tương tự. Tương tự, không có cảnh báo không chứng minh hệ thống chưa vá là an toàn.
Nếu bằng chứng cho thấy có thể đã xảy ra xâm nhập, hãy bảo toàn bằng chứng và tổ chức xử lý sự cố song song với việc vá. Cập nhật trình thông dịch không loại bỏ cơ chế duy trì truy cập, không vô hiệu hóa việc đánh cắp thông tin đăng nhập và không xác định dữ liệu nào đã bị truy cập. Xử lý những việc đó như các câu hỏi riêng trong kế hoạch ứng phó.
Câu hỏi thường gặp
Exploit PHP2Shell là gì? PHP2Shell chỉ các lỗ hổng PHP được theo dõi bằng CVE-2026-109618 và CVE-2026-109619. Chúng liên quan đến quản lý bộ nhớ trong môi trường thực thi và có thể cho phép thực thi mã từ xa không cần xác thực. Đây không đơn thuần là lỗi plugin WordPress.
Cần kiểm tra phiên bản nào cho bản vá PHP2Shell? Các bản sửa cho nhánh được hỗ trợ, phát hành ngày 21 tháng 10 năm 2026, là PHP 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Với bản vá ngược của bản phân phối, lấy khuyến cáo của nhà cung cấp và xác nhận số hiệu chỉnh chính xác của gói đã vá trong môi trường phục vụ yêu cầu.
Cập nhật WordPress có khắc phục PHP2Shell không? Chỉ cập nhật WordPress không cập nhật trình thông dịch PHP bên dưới. Tiếp tục bảo trì ứng dụng, nhưng xác minh riêng bản sửa bảo mật của môi trường PHP với nhà cung cấp lưu trữ hoặc kỹ sư phụ trách máy chủ.
Website phía sau Cloudflare có tự động an toàn không? Cloudflare báo cáo có bảo vệ WAF, nhưng đường đi lưu lượng, quy tắc áp dụng và mức phơi nhiễm máy chủ gốc vẫn cần kiểm tra. Duy trì bảo vệ và vá PHP. Bảng điều khiển tường lửa không chứng minh môi trường đã được sửa hoặc chưa từng bị xâm nhập.
Tắt theo dõi tiến độ tải lên của phiên có đủ không? Không. PHP mô tả biện pháp này là chặn các đường liên quan đến phiên đã xác nhận, không phải mọi biến thể. Phải áp dụng ở lớp cấu hình thích hợp và khởi động lại tiến trình worker. Vẫn cần cập nhật lên môi trường đã sửa hoặc bản vá ngược được nhà cung cấp xác nhận.
Có thể thử exploit công khai trên website đang hoạt động không? Ưu tiên bằng chứng về phiên bản, gói và cấu hình cho kiểm tra ban đầu. Nếu xác minh cần thử exploit, hãy thực hiện với ủy quyền rõ ràng trong môi trường có kiểm soát, có cách ly, giám sát và kế hoạch phục hồi. Không chạy mã khai thác chưa được rà soát trên môi trường sản xuất.
Cài bản vá có chứng minh máy chủ chưa bị xâm nhập không? Không. Bản vá xử lý lỗ hổng của môi trường thực thi, còn đánh giá sự cố xem xét hoạt động trước đó, cơ chế duy trì truy cập, thông tin đăng nhập và khả năng dữ liệu bị truy cập. Kết nối các công việc này và ghi lại giới hạn của bằng chứng hiện có.
Cần hỗ trợ kiểm tra, giám sát hoặc vá website PHP?
Chúng tôi có thể giúp xác định môi trường PHP nào đang phục vụ website, đánh giá mức phơi nhiễm, rà soát nhật ký và kiểm soát phòng vệ hiện có, đồng thời lập kế hoạch vá hoặc nâng cấp có hỗ trợ cần thiết. Nếu môi trường cần theo dõi liên tục, chúng tôi có thể thống nhất phạm vi giám sát, người phụ trách cảnh báo và quy trình chuyển cấp dựa trên rủi ro đã xác định.
Dịch vụ bảo mật ứng dụng của chúng tôi hỗ trợ đánh giá và điều tra, còn dịch vụ bảo mật máy chủ phụ trách ranh giới lưu trữ và cấu hình. Chúng tôi có thể làm việc với nhà cung cấp lưu trữ để xác minh bản sửa, phối hợp thay đổi và ghi nhận kiểm tra ứng dụng sau cập nhật.
Kết quả hữu ích là hồ sơ rõ ràng về những gì đã kiểm tra, đã vá, còn chưa chắc chắn và ai chịu trách nhiệm theo dõi tiếp. Chúng tôi không hứa xác nhận an toàn chỉ từ chuỗi phiên bản hay một lần quét. Phạm vi và khả năng bố trí công việc được thống nhất trước khi bắt đầu.
Liên hệ để kiểm tra phơi nhiễm PHP2Shell, giám sát bảo mật hoặc hỗ trợ vá lỗi . Nêu hình thức lưu trữ, tên miền bị ảnh hưởng, phiên bản PHP đã biết và người được phép phê duyệt thay đổi. Vui lòng không gửi mật khẩu hay token truy cập trong yêu cầu đầu tiên.