PHP2Shell, Lỗ hổng RCE nghiêm trọng ảnh hưởng nhiều phiên bản PHP, quản trị máy chủ cần cập nhật ngay

PHP vừa phát hành các bản cập nhật bảo mật khẩn cấp để xử lý hai lỗ hổng nghiêm trọng trong chính bộ máy thực thi PHP. Được gọi chung là PHP2Shell, hai lỗ hổng này có thể cho phép kẻ tấn công khai thác lỗi bộ nhớ, đọc dữ liệu nhạy cảm và trong những điều kiện nhất định thực thi mã trên máy chủ mà không cần tài khoản đăng nhập.
Điểm đáng lo ngại là lỗi nằm trong PHP runtime, không phải trong mã nguồn của từng website. Vì vậy, ngay cả những website sử dụng WordPress, Laravel hay các ứng dụng PHP được viết cẩn thận vẫn có nguy cơ nếu máy chủ đang chạy phiên bản PHP chưa được vá.

Hai lỗ hổng được công bố với mã CVE-2026-109618 và CVE-2026-109619, cùng đạt mức nghiêm trọng 9,2 theo thang điểm CVSS 4.0. Các nhà nghiên cứu từ Wiz Research, Calif và nhóm Codex Security của OpenAI đã phối hợp với đội ngũ bảo mật PHP cùng nhóm Gemini của Google trong quá trình điều tra và khắc phục.

PHP2Shell nguy hiểm như thế nào?​

Theo thông tin công bố, hai lỗ hổng liên quan đến cách PHP xử lý bộ nhớ và thiết lập yêu cầu trước khi ứng dụng bắt đầu thực thi đầy đủ.
Trong trường hợp Apache sử dụng module mod_php, một yêu cầu HTTP được tạo đặc biệt có thể kích hoạt quá trình khai thác ngay từ giai đoạn khởi tạo yêu cầu, trước khi mã ứng dụng của website được chạy. Đáng chú ý, kẻ tấn công không cần đăng nhập để thực hiện kiểu tấn công đã được chứng minh này.
Với PHP-FPM, cơ chế xử lý có một số khác biệt. Khi yêu cầu gặp lỗi sớm trong quá trình khởi tạo, worker có thể bị dừng lại. Tuy nhiên, các nhà nghiên cứu vẫn chứng minh được khả năng thực thi mã trong một số trường hợp liên quan đến PHP-FPM, tùy theo lỗ hổng và đường khai thác. Không phải mọi kịch bản đều có mức độ khai thác giống nhau.
Ngoài khả năng thực thi mã, lỗi còn có thể khiến kẻ tấn công đọc dữ liệu từ bộ nhớ của tiến trình PHP. Vùng nhớ này có thể chứa mật khẩu, token xác thực, API key hoặc chứng chỉ được sử dụng trong quá trình xử lý các yêu cầu khác.

Các nhà nghiên cứu cho biết họ đã chứng minh được khả năng đọc bộ nhớ tiến trình PHP đang hoạt động trên những ứng dụng mà họ không kiểm soát. Điều này cho thấy nguy cơ không chỉ giới hạn ở một ứng dụng cụ thể có mã nguồn dễ bị tấn công.

Lỗ hổng ảnh hưởng đến nhiều môi trường chạy PHP, bao gồm PHP-FPM, Apache mod_php, php-cgi, FrankenPHP và LiteSpeed. Theo thông báo bảo mật, phạm vi ảnh hưởng trải dài qua nhiều thế hệ PHP, với các vấn đề tồn tại từ những phiên bản cũ.

Những phiên bản PHP nào đã được vá?​

Để khắc phục triệt để, quản trị viên cần cập nhật PHP runtime lên phiên bản đã sửa lỗi tương ứng với nhánh đang sử dụng.




Các phiên bản thấp hơn phiên bản sửa lỗi tương ứng thuộc phạm vi cần kiểm tra theo thông báo bảo mật.

PHP 8.1 trở về trước đã hết thời gian hỗ trợ cập nhật từ dự án PHP. Đối với các nhánh cũ, nhóm bảo mật PHP đã cung cấp một số bản vá được đưa ngược về PHP 7.4, 8.0 và 8.1, phục vụ những trường hợp cần tự biên dịch hoặc chờ nhà cung cấp phát hành gói cập nhật riêng.

Nếu sử dụng Linux, cần lưu ý rằng một số bản phân phối có thể đưa bản vá bảo mật vào gói phần mềm mà không thay đổi số phiên bản theo cách dễ nhận biết. Do đó, không nên chỉ nhìn số phiên bản PHP để kết luận máy chủ đã an toàn. Hãy kiểm tra thông báo cập nhật và nhật ký thay đổi của gói phần mềm, đặc biệt là thông tin liên quan đến hai mã CVE nói trên.

Sau khi cập nhật, cần khởi động lại Apache, PHP-FPM và các tiến trình PHP chạy lâu dài có liên quan để bảo đảm mã đã vá thực sự được sử dụng.

Một điểm cần nhấn mạnh: cập nhật WordPress, Laravel hay mã nguồn website không đồng nghĩa với việc PHP runtime đã được cập nhật. Thành phần này thường được quản lý riêng thông qua hệ điều hành, nhà cung cấp hosting, cấu hình máy chủ hoặc image container.

Chưa thể cập nhật ngay thì làm gì?​

Nhóm bảo mật PHP nhấn mạnh rằng chỉ cập nhật lên phiên bản đã vá mới là biện pháp khắc phục đầy đủ. Một số thay đổi cấu hình có thể hạn chế những đường khai thác nhất định, nhưng không thể thay thế bản vá.

Với CVE-2026-109618, các biện pháp được đề cập bao gồm đặt memory_limit=-1 theo cách ứng dụng không thể tự ghi đè, giữ post_max_size ở mức thấp phù hợp và giới hạn kích thước yêu cầu tại web server hoặc proxy.

Với CVE-2026-109619, có thể tắt session.upload_progress.enabled=0, sau đó khởi động lại các worker. Trên PHP 8.5, thông tin khắc phục còn đề cập đến việc đặt fatal_error_backtraces=0.

Tuy nhiên, những biện pháp này chỉ giảm nguy cơ từ một số đường khai thác đã biết. Riêng việc tắt session upload progress không xử lý được CVE-2026-109618 và cũng không ngăn chặn mọi biến thể khai thác CVE-2026-109619.
Sau khi cập nhật, quản trị viên cũng nên kiểm tra lại cấu hình bộ nhớ. Bản vá bổ sung giới hạn bộ nhớ cứng mới; khi tiến trình chạm giới hạn, nó có thể bị kết thúc và các trình xử lý khi shutdown không được chạy như thông thường. Vì vậy, cần cân đối memory_limit và post_max_size với nhu cầu thực tế của ứng dụng.

Đã có dấu hiệu tấn công ngoài thực tế?​

Trước khi bản vá chính thức được phát hành, Cloudflare cho biết họ ghi nhận những nỗ lực khai thác ban đầu và đã triển khai các quy tắc giảm thiểu trên hệ thống bảo vệ của mình. Công ty đồng thời cảnh báo rằng các quy tắc tường lửa chỉ là biện pháp tạm thời, bởi kẻ tấn công có thể thay đổi payload để tìm cách vượt qua.


Trong bản cập nhật ngày 21/10, đơn vị nghiên cứu watchTowr cho biết đang quan sát các nỗ lực khai thác cả hai lỗ hổng. Cloudflare cũng ghi nhận lưu lượng tấn công nhắm vào khách hàng và những thay đổi trong payload nhằm né tránh quy tắc bảo vệ.


Tuy nhiên, tại thời điểm các thông tin trên được công bố, chưa có nguồn nào xác nhận một vụ xâm nhập thành công cụ thể do PHP2Shell gây ra.


Một số tổ chức đã chủ động tạm ngừng dịch vụ để phòng ngừa. Theo thông tin được đưa ra, BambooHR ngừng hoạt động dịch vụ tại Mỹ, Canada và Ireland, đồng thời cảnh báo khả năng gián đoạn hoạt động trả lương. Tại Hà Lan, một số dịch vụ công và hệ thống giáo dục cũng được báo cáo là ngoại tuyến.


Nếu đã cập nhật bản vá nhưng nghi ngờ máy chủ từng bị khai thác trước đó, quản trị viên nên kiểm tra các yêu cầu multipart bất thường, lỗi bộ nhớ xuất hiện cùng những phản hồi HTTP 500 lặp lại, cookie PHPSESSID có kích thước bất thường và các lần khởi động lại worker không rõ nguyên nhân. Đây là những dấu hiệu cần điều tra, không phải bằng chứng khẳng định máy chủ đã bị xâm nhập.

AI giúp tìm ra lỗ hổng tồn tại nhiều năm​

Một chi tiết đáng chú ý của PHP2Shell là vai trò của các công cụ AI trong quá trình nghiên cứu.

Theo nhóm nghiên cứu, các lỗi nền tảng đã tồn tại trong PHP hơn một thập kỷ. Calif cho biết nguồn gốc của vấn đề có liên quan đến những nghiên cứu về PHP từ năm 2004. Tuy nhiên, việc biết đến một lỗi cũ không đồng nghĩa với việc có thể ngay lập tức biến nó thành một phương thức khai thác thực tế.

Calif cho rằng các mô hình AI hiện nay chưa đủ tin cậy để tự tìm ra mọi kỹ thuật khai thác từ những chi tiết ít được chú ý có tuổi đời hàng chục năm. Kiến thức nền tảng và kinh nghiệm của nhà nghiên cứu vẫn đóng vai trò quan trọng.

Nhóm nghiên cứu cho biết các công cụ AI đã giúp rút ngắn đáng kể quá trình biến những vấn đề bộ nhớ tồn tại lâu năm thành khai thác có thể hoạt động. Một nhà nghiên cứu ước tính công việc này có thể được hoàn thành trong khoảng một tuần thay vì cần cả nhóm làm việc trong nhiều tháng.
Tuy vậy, câu chuyện không chỉ nằm ở khả năng của AI mà còn ở cách cộng đồng mã nguồn mở tiếp nhận và xử lý báo cáo bảo mật.

Tranh luận về quá trình công bố lỗ hổng​

PHP2Shell được dự kiến công bố vào ngày 22/10/2026, nhưng thông tin đã bị lộ trước thời điểm đó. Tối 20/10, một video trình diễn proof of concept của Calif bị đăng nhầm. Sáng 21/10, một số image đã chứa bản vá cũng được công bố trước khi bản cập nhật chính thức đến tay toàn bộ người dùng.
PHP sau đó đẩy lịch công bố lên ngày 21/10 và phát hành các phiên bản sửa lỗi. Diễn biến này khiến quá trình công bố phối hợp không diễn ra như kế hoạch ban đầu.

Trong các cuộc thảo luận trên Hacker News, nhiều ý kiến bất bình vì quản trị viên và người vận hành hệ thống có thể không nhận được đủ thời gian chuẩn bị, trong khi những người có quyền tiếp cận sớm đã biết về vấn đề. Một số người cho rằng bản vá tạm thời nên được phát hành sớm hơn mà không cần công bố chi tiết khai thác.

Ở chiều ngược lại, những người bảo vệ quy trình tiết lộ có trách nhiệm cho rằng công bố bản vá cũng có thể giúp kẻ tấn công phân tích sự khác biệt trong mã nguồn để tái tạo cách khai thác. Nếu bản vá được phát hành khi chưa có đủ thời gian kiểm tra, hoặc khi phần lớn hệ thống chưa thể cập nhật, nguy cơ có thể tăng lên.

PHP Foundation cũng thừa nhận quy trình xử lý có vấn đề. Theo thông tin của tổ chức, một cuộc kiểm toán bên ngoài năm 2024 đã phát hiện dấu hiệu đầu tiên của lỗi bộ nhớ liên quan đến CVE-2026-109618. Tuy nhiên, thời điểm đó chưa xác định được con đường cụ thể dẫn đến thực thi mã.

Việc thống nhất phương án sửa lỗi gặp khó khăn do những thay đổi khác nhau có thể ảnh hưởng đến khả năng tương thích, tạo ra nguy cơ từ chối dịch vụ hoặc buộc các phần mở rộng của bên thứ ba phải điều chỉnh. Quá trình này bị đình trệ trong nhiều tháng, và PHP Foundation gọi đây là thất bại mang tính cơ cấu trong cơ chế ra quyết định cũng như nguồn lực.

Các báo cáo mới từ Calif, OpenAI và Wiz đã chứng minh được khả năng khai thác thực tế, khiến vấn đề được ưu tiên xử lý. PHP Foundation cho biết đã thay đổi cách ra quyết định về bảo mật, đồng thời bổ sung nhân sự và công cụ nhằm phát hiện những vấn đề tương tự sớm hơn.

Kết luận​

PHP2Shell là lời nhắc nhở rằng một website không nhất thiết phải có lỗi trong mã nguồn mới có thể bị tấn công. Nếu nền tảng PHP bên dưới còn tồn tại lỗ hổng, toàn bộ ứng dụng sử dụng runtime đó đều có thể chịu rủi ro.

Với quản trị viên website, việc cần làm trước tiên là kiểm tra phiên bản PHP thực tế đang phục vụ yêu cầu web, cập nhật gói đã vá từ nhà cung cấp đáng tin cậy và khởi động lại các tiến trình liên quan. Không nên xem các thiết lập giảm thiểu hay quy tắc WAF là phương án thay thế bản vá chính thức.

Bên cạnh vấn đề kỹ thuật, sự cố cũng cho thấy việc phối hợp công bố lỗ hổng giữa nhà nghiên cứu, đội ngũ duy trì phần mềm và nhà cung cấp hạ tầng quan trọng không kém việc tìm ra lỗi. Một bản vá tốt chỉ thực sự phát huy hiệu quả khi người vận hành có thể tiếp cận, triển khai và xác minh nó kịp thời.


Nguồn tham khảo chính:

https://www.php2shell.com/

https://www.wiz.io/blog/php2shell-php-rce

https://calif.io/php2shell/