PHP2Shell: Hai lỗ hổng nghiêm trọng cho phép tin tặc chiếm máy chủ PHP không cần đăng nhập

Nếu hệ thống của bạn đang chạy PHP ở bất kỳ đâu, hãy nâng cấp lên PHP 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 ngay lập tức. Hai lỗ hổng nghiêm trọng vừa được công bố với biệt danh PHP2Shell cho phép kẻ tấn công chưa xác thực thực thi mã trên máy chủ chỉ bằng một yêu cầu web được chế tạo đặc biệt. Cả hai đều có điểm CVSS v4.0 là 9.2, mọi phiên bản phát hành trước đó đều bị ảnh hưởng, và đã có ghi nhận khai thác trong thực tế.

Bản vá là phần dễ. Phần khó là tìm ra mọi bản sao PHP trong hệ thống, bởi PHP hiếm khi xuất hiện ở đúng nơi bạn kỳ vọng.

Minh họa về lỗ hổng PHP2Shell

Chuyện gì đã xảy ra?

Chi tiết về lỗ hổng bị rò rỉ trước thời hạn phong tỏa thông tin, nên nhóm bảo mật PHP đã phải hành động gấp và tung bản vá chỉ trong khoảng một ngày sau khi công bố.

• 20/10: CERT-EU phát hành khuyến nghị 2026-018, đề nghị cô lập các ứng dụng PHP hướng ra Internet. PHP công bố bản phát hành bảo mật khẩn cấp sau khi thông tin rò rỉ; watchTowr xác nhận lỗ hổng là thật.
• 21/10, khoảng 13:47 (UTC): Bản dựng Windows đã vá xuất hiện trên downloads.php.net.
• 21/10, khoảng 14:00 (UTC): PHP công bố khuyến cáo chính thức và phát hành các phiên bản 8.5.12, 8.4.27, 8.3.36 và 8.2.35.
• 21/10: watchTowr báo cáo đã quan sát thấy hoạt động khai thác trong mạng lưới honeypot toàn cầu của họ.

Hai lỗ hổng hoạt động thế nào?

Cả hai lỗi đều nằm trong lõi PHP, không phải trong framework hay plugin nào, nên chúng ảnh hưởng tới mọi thứ chạy PHP để phục vụ yêu cầu web.

• CVE-2026-109618: Lỗi hỏng bộ nhớ (memory corruption) phát sinh khi PHP phân tích các yêu cầu multipart (tải tệp lên) trong điều kiện hết bộ nhớ. Đã xác nhận thực thi mã từ xa (RCE) trên mod_php.
• CVE-2026-109619: Lỗi use-after-free trên yêu cầu ngay sau một lỗi nghiêm trọng (fatal error). Đã xác nhận RCE trên mod_php và PHP-FPM.

Các cấu hình máy chủ bị ảnh hưởng gồm PHP-FPM, mod_php, php-cgi, FrankenPHP và LiteSpeed. PHP đánh giá mod_php là rủi ro cao nhất. Kẻ tấn công không cần đăng nhập, chỉ cần tiếp cận được một điểm cuối PHP qua giao thức HTTP.

Mọi phiên bản PHP phát hành trước đều bị ảnh hưởng. PHP cũng đã phát hành bản vá nguồn tối thiểu cho 7.4, 8.0 và 8.1, nhưng không có bản phát hành chính thức cho các nhánh này. Hãy coi những bản vá đó chỉ là giải pháp tạm thời và lên kế hoạch nâng cấp.

Đã bị khai thác chưa?

Có, dù các mã khai thác công khai đáng tin cậy vẫn còn khan hiếm. watchTowr ghi nhận khai thác trong mạng lưới honeypot từ ngày 21/10, và Tenable dẫn lời CTO của Cloudflare cho biết họ đã thấy các cuộc tấn công sớm. Dữ liệu từ nguồn khác như Patchstack chủ yếu cho thấy hoạt động dò quét. Cả hai CVE hiện chưa có trong danh mục KEV của CISA và chưa có chỉ dấu xâm nhập (IoC) công khai nào được công bố.

Mức độ khó khi vũ khí hóa lỗ hổng phụ thuộc vào nền tảng:

• Thực thi mã hoạt động trên ARM64, và trên hệ thống x86 khi tắt ASLR (ngẫu nhiên hóa bố cục không gian địa chỉ).
• Có hàng chục bản proof-of-concept (PoC) công khai, nhưng rất ít bản hoạt động và không bản nào vượt qua được ASLR trên x86-64.
• Red Hat cũng đánh giá việc RCE trên các triển khai PHP-FPM mặc định là khó trong thực tế.

Tuy vậy, đừng lấy đó làm lý do để chờ đợi. Các mã khai thác trưởng thành rất nhanh khi bản diff vá được công khai, và các kho PoC giả cho những CVE nổi bật thường chứa mã độc — hãy cẩn trọng với bất kỳ PoC nào bạn tìm thấy.

Nhóm rủi ro cao nhất là các ứng dụng PHP hướng ra Internet, đặc biệt là những cái chạy mod_php hoặc trên máy chủ ARM64. Cũng nên rà soát ngược log máy chủ web và PHP-FPM gần đây để tìm các vụ tiến trình worker bị sập không rõ nguyên nhân và các yêu cầu multipart bất thường.

Vì sao tìm PHP lại khó hơn tưởng tượng?

Không ai có một danh sách đầy đủ các ứng dụng dựa trên PHP, và mọi thứ tự phát triển đều không nằm trong bất kỳ danh sách nào. PHP ẩn mình ở nhiều nơi cùng lúc:

• Gói của hệ điều hành trên Linux (php, php-fpm, php8.x) — thứ mà trình quản lý gói và hầu hết công cụ kiểm kê đều thấy.
• Homebrew và tương tự trên macOS, nằm ngoài danh sách gói của hệ thống.
• Bản đóng kèm trên Windows. PHP trên Windows thường đến dưới dạng tệp zip giải nén vào một thư mục hoặc nằm trong các gói như XAMPP, WampServer, Laragon hay một sản phẩm của nhà cung cấp. Nó thường không bao giờ được đăng ký như một ứng dụng đã cài đặt.
• Ứng dụng tự đóng gói PHP riêng, khi đó việc vá phụ thuộc vào nhà cung cấp ứng dụng chứ không phải hệ điều hành.
• Container, nơi phiên bản được đóng cứng vào thẻ image.

PHP thường phổ biến hơn nhiều so với dự đoán và không chỉ chạy trên máy chủ. Công cụ dành cho lập trình viên, bộ web cục bộ và các ứng dụng đóng kèm cũng đưa PHP lên máy trạm, thường mà không đăng ký như ứng dụng đã cài.

Cách trả lời đáng tin cậy là soi vào chính các tệp nhị phân. Trong thử nghiệm, các bản dựng PHP từ phiên bản 5 đến 8 đều nhúng chuỗi phiên bản (X-Powered-By: PHP/x.y.z), nên có thể đọc chính xác phiên bản thẳng từ tệp mà không cần chạy nó.

Doanh nghiệp cần làm gì ngay bây giờ?

Thực hiện theo thứ tự sau, ba bước đầu là quan trọng nhất trong hôm nay:

• Tìm mọi bản cài PHP, kể cả các bản trên Windows chưa từng đăng ký như ứng dụng. Ghi lại phiên bản chính xác của từng bản.
• Xếp hạng theo mức độ phơi nhiễm. Ưu tiên máy chủ hướng ra Internet, các cấu hình mod_php và máy chủ ARM64.
• Vá lên 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 qua nhà cung cấp hệ điều hành, bản dựng php.net hoặc nhà cung cấp ứng dụng. Khởi động lại PHP-FPM và các tiến trình worker của máy chủ web để nạp tệp nhị phân mới.
• Nếu chưa vá được, hãy cô lập các ứng dụng PHP hướng ra Internet như CERT-EU khuyến nghị, và đặt trước chúng các quy tắc WAF hoặc IDS (Cloudflare và VulnCheck đều đã phát hành quy tắc cho các vector đã biết).
• Thận trọng với cấu hình giảm thiểu một phần. Thiết lập session.upload_progress.enabled=0 chỉ chặn được một đường khai thác đã được trình diễn của CVE-2026-109619 và không có tác dụng gì với CVE-2026-109618. Nó phải được đặt trong php.ini, một pool FPM hoặc cấu hình máy chủ, rồi khởi động lại worker; ini_set() và .user.ini sẽ không áp dụng được.
• Truy vết (hunt). Rà soát log máy chủ web và PHP-FPM gần đây để tìm các vụ tiến trình worker bị sập và các yêu cầu tải tệp multipart dị dạng.
• Lên kế hoạch loại bỏ PHP hết hạn hỗ trợ. Mọi bản trên 8.1 hoặc cũ hơn đều không có bản phát hành chính thức đã vá.

Bảng trạng thái bản vá PHP2Shell theo nền tảng

Bản vá đang ở đâu? (tính đến 16:30 UTC ngày 21/10)

Các gói của bản phân phối vẫn đang được tung ra, nên hãy kiểm tra với nhà cung cấp trước khi cho rằng đã có bản vá.

Nền tảng	Trạng thái
Ubuntu 22.04, 24.04, 26.04, 26.10	Đã vá (USN-8948-1)
Ubuntu 20.04	Chỉ vá cho người dùng Ubuntu Pro
Debian 12 và 13	Đã vá
Windows (bản dựng php.net)	Đã vá
Image Docker php chính thức	Đã vá thẻ 8.5.12, 8.4.27, 8.3.36, 8.2.35
cPanel EasyApache 4	Đã vá trong 25.91
Plesk cho Linux	Đã vá; Plesk cho Windows vẫn chờ
RHEL 8, 9, 10 và các bản dựng lại	Đang chờ
SUSE, Alpine, Chocolatey, Homebrew core	Đang chờ
Amazon Linux 2023	Đang chờ cho php8.2 đến 8.5; không có kế hoạch vá cho php8.1

Kho Remi sẽ không tung cập nhật trong ngày hôm nay, nên PHP khuyến nghị chuyển sang gói của bản phân phối hoặc tự biên dịch từ mã nguồn nếu bạn phụ thuộc vào nó.

Với các tổ chức tại Việt Nam đang vận hành website và ứng dụng nội bộ trên PHP — từ WordPress, Laravel đến các hệ thống tự phát triển — việc kiểm kê toàn bộ bản cài PHP, kể cả trên máy trạm của lập trình viên và các container chưa được theo dõi, là bước cấp thiết nhất lúc này.