Lỗ hổng PHP2Shell: Hướng dẫn rà soát và vá lỗi cho doanh nghiệp

1. Lỗ hổng PHP2Shell là gì?

Lỗ hổng PHP2Shell là tên gọi chung của hai lỗ hổng bảo mật mức nghiêm trọng (Critical) mang mã CVE-2026-109618 và CVE-2026-109619, được nhóm phát triển PHP công bố cùng bản vá vào ngày 21/10/2026. Cả hai đều là lỗi hỏng bộ nhớ (memory corruption), độc lập với nhau nhưng có thể bổ trợ cho nhau, và nằm ngay trong lõi trình thông dịch PHP.

Điểm cần lưu ý là PHP2Shell không phải lỗi ở tầng ứng dụng như các lỗi bảo mật web thường gặp, chẳng hạn SQL injection, XSS hay các lỗ hổng trong danh sách Top 10 OWASP. Lỗ hổng không nằm trong các framework hay hệ thống quản trị nội dung (CMS) như WordPress, Laravel hay Drupal, mà nằm ở chính phần mềm PHP đang vận hành các ứng dụng đó. Vì vậy, mọi website chạy trên PHP đều cần được rà soát, bất kể doanh nghiệp đang dùng nền tảng nào.

Theo nhóm phát triển PHP, cả hai lỗ hổng cùng được chấm 9,2 điểm theo thang CVSS v4.0, thang đo mức độ nghiêm trọng của lỗ hổng với điểm tối đa là 10. Lỗ hổng được giới nghiên cứu phát hiện với sự hỗ trợ của các công cụ trí tuệ nhân tạo (AI) và đã được thông báo cho nhóm phát triển PHP trước khi công bố.

2. Cơ chế hoạt động của lỗ hổng PHP2Shell

Hai lỗ hổng trong PHP2Shell cùng khai thác cách PHP quản lý bộ nhớ khi quá trình xử lý request bị gián đoạn, nhưng khác nhau ở thời điểm vùng nhớ không an toàn bị truy cập.

2.1 CVE-2026-109618: Thực thi mã từ xa (RCE) qua lỗi hỏng bộ nhớ khi xử lý OOM

CVE-2026-109618 phát sinh từ cách PHP xử lý tình trạng hết bộ nhớ. PHP dùng chỉ thị memory_limit để giới hạn bộ nhớ cho mỗi request, và khi vượt ngưỡng, PHP báo lỗi hết bộ nhớ (OOM) rồi dừng xử lý ngay lập tức, bỏ qua quy trình dọn dẹp tài nguyên thông thường.

Kẻ tấn công gửi request multipart/form-data được chế tạo đặc biệt, chứa nhiều phần dữ liệu lồng nhau, để kích hoạt lỗi OOM đúng lúc PHP đang phân tích request và dữ liệu nội bộ mới được khởi tạo một phần. Khi đó, quá trình dọn dẹp có thể xem dữ liệu dở dang này là hợp lệ, gây hỏng bộ nhớ heap của tiến trình. Apache mod_php dùng chung không gian bộ nhớ với tiến trình Apache nên dễ bị khai thác hơn, còn PHP-FPM vẫn bị ảnh hưởng với độ phức tạp khai thác cao hơn một chút.

2.2 CVE-2026-109619: Thực thi mã từ xa (RCE) qua trạng thái global còn sót giữa các request

Nếu CVE-2026-109618 khai thác lúc PHP hết bộ nhớ, thì CVE-2026-109619 lợi dụng việc PHP-FPM worker hoạt động lâu dài và xử lý nhiều request liên tiếp. Ở request độc hại đầu tiên, payload gây lỗi nghiêm trọng (fatal error) trong bộ phân tích multipart, khiến PHP giải phóng một số vùng nhớ nhưng vẫn giữ các con trỏ trỏ tới chúng.

Khi request độc hại thứ hai được gửi tới cùng worker, PHP có thể dùng lại các con trỏ cũ này trước khi trạng thái được khởi tạo lại, tạo ra lỗi use-after-free. Bằng cách kiểm soát bố cục bộ nhớ, kẻ tấn công có thể ghi đè con trỏ hàm nội bộ và thực thi mã tùy ý trong tiến trình PHP.

3. Lỗ hổng PHP2Shell nguy hiểm đến mức nào?

Lỗ hổng PHP2Shell được xếp mức nghiêm trọng vì cho phép kẻ tấn công thực thi mã tùy ý từ xa trên máy chủ mục tiêu mà không cần xác thực, thông tin đăng nhập, cookie phiên, token hay bất kỳ lỗi nào trong ứng dụng web.

3.1 Hậu quả khi lỗ hổng bị khai thác thành công

Khi khai thác thành công, kẻ tấn công có thể chạy lệnh hệ điều hành dưới quyền của tiến trình PHP, từ đó:

• Tải lên webshell và cài cửa hậu (backdoor) để duy trì quyền truy cập lâu dài.
• Đọc các tệp cấu hình chứa thông tin đăng nhập cơ sở dữ liệu, khóa API và các thông tin bí mật khác.
• Trích xuất dữ liệu từ cơ sở dữ liệu của ứng dụng, gây ra sự cố rò rỉ dữ liệu (data breach).
• Cài mã độc (malware) đào tiền ảo hoặc mã độc tống tiền (ransomware).
• Di chuyển ngang để tấn công các máy chủ khác trong mạng nội bộ.
• Thay đổi giao diện website và can thiệp vào dữ liệu.

3.2 Website không có tính năng tải tệp lên vẫn có thể bị tấn công

Quá trình khai thác lỗ hổng PHP2Shell diễn ra khi PHP phân tích phần thân (body) của các HTTP request dạng multipart/form-data, ngay cả trước khi bất kỳ mã ứng dụng PHP nào được thực thi. Website không cần có tính năng tải tệp lên. Chỉ cần SAPI của PHP chấp nhận request POST dạng multipart/form-data, dịch vụ đã nằm trong diện bị đe dọa. Ngược lại, request GET thông thường không thể kích hoạt lỗ hổng nào.

3.3 Tình trạng khai thác sau khi lỗ hổng được công bố

Theo PHP Foundation, khả năng thực thi mã từ xa đã được chứng minh trên Apache mod_php với cấu hình mặc định, và mã khai thác thử nghiệm đã xuất hiện công khai ngay trong ngày công bố. Mức độ nghiêm trọng này khiến nhiều cơ quan chính phủ trên thế giới phải tạm đóng website để phòng ngừa. Tại Việt Nam, Cục An ninh mạng và Hiệp hội An ninh mạng quốc gia khuyến cáo các tổ chức, doanh nghiệp vận hành website PHP sớm rà soát hệ thống và cập nhật bản vá.

4. Doanh nghiệp nào cần rà soát lỗ hổng PHP?

Doanh nghiệp cần rà soát lỗ hổng PHP2Shell nếu đang vận hành website, cổng thông tin hoặc hệ thống nội bộ chạy PHP ở phiên bản chưa vá. Mức độ ảnh hưởng phụ thuộc vào cách PHP được triển khai trên máy chủ (server) thông qua SAPI và nhánh phiên bản PHP đang sử dụng.

4.1 Các SAPI bị ảnh hưởng

SAPI (Server API) là lớp giao tiếp giữa PHP và máy chủ web. Các SAPI sau đều bị ảnh hưởng bởi lỗ hổng PHP2Shell:

• PHP-FPM
• Apache mod_php (rủi ro cao nhất đối với CVE-2026-109618)
• php-cgi
• FrankenPHP
• LiteSpeed SAPI

4.2 Phiên bản bị ảnh hưởng và phiên bản đã vá

Nhóm phát triển PHP đã phát hành bản vá cho cả bốn nhánh còn được hỗ trợ. Doanh nghiệp đối chiếu nhánh PHP đang dùng với bảng dưới đây để xác định phiên bản cần nâng cấp:

4.3 Các nhánh PHP đã hết hỗ trợ

Các nhánh PHP đã hết hỗ trợ (5.x, 7.x, 8.0, 8.1) không có bản vá chính thức. Doanh nghiệp đang dùng các nhánh này bắt buộc phải chuyển sang PHP 8.2 trở lên, là các nhánh còn được hỗ trợ.

Do mức độ nghiêm trọng của lỗ hổng, nhóm bảo mật PHP có cung cấp bản sửa tối thiểu dạng mã nguồn cho PHP 7.4, 8.0 và 8.1, đồng thời một số bản phân phối Linux và nhà cung cấp hỗ trợ dài hạn (LTS) cũng phát hành gói cập nhật cho các nhánh này. Đây chỉ là giải pháp tình thế trong lúc chuẩn bị nâng cấp. Ngoài ra, PHP 8.2 sẽ hết vòng đời vào ngày 31/12/2026, nên doanh nghiệp đang dùng nhánh này cũng nên sớm lên kế hoạch chuyển sang phiên bản mới hơn.

4.4 Website đặt trên dịch vụ hosting

Với website đặt trên dịch vụ hosting, phiên bản PHP thường do nhà cung cấp quản lý. Doanh nghiệp nên liên hệ nhà cung cấp hosting để xác nhận phiên bản PHP đang chạy và tình trạng bản vá trên máy chủ.

5. Cách khắc phục lỗ hổng PHP2Shell

Giải pháp triệt để, và cũng là cách duy nhất đạt hiệu quả hoàn toàn, là nâng cấp PHP lên phiên bản đã vá rồi khởi động lại dịch vụ PHP. Nhóm phát triển PHP cũng khẳng định không có biện pháp giảm thiểu nào hoàn chỉnh, cập nhật là lựa chọn an toàn duy nhất.

5.1 Thông tin về bản vá chính thức

• Bản vá được phát hành lúc 14:00 UTC ngày 21/10/2026 (21:00 giờ Việt Nam), sớm hơn so với kế hoạch ban đầu là ngày 22/10. Trước đó, mã CVE của hai lỗ hổng đã bị rò rỉ từ chiều ngày 20/10.
• Điểm CVSS chính thức của hai lỗ hổng là 9,2. Theo PHP Foundation, con số 10.0 lan truyền trong thông tin rò rỉ là không chính xác.
• Các bản phân phối Linux và nhà cung cấp LTS đã nhận bản vá trước khi công bố, nên doanh nghiệp có thể kiểm tra gói cập nhật từ nhà cung cấp hệ điều hành.
• Mã nguồn và bản build cho Windows có sẵn trên trang tải chính thức của PHP.

Bước 1: Nâng cấp các gói PHP lên phiên bản đã vá

Nâng cấp các gói PHP lên phiên bản an toàn tương ứng với nhánh PHP đang cài đặt trên máy chủ, theo bảng phiên bản ở phần trên.

Bước 2: Khởi động lại dịch vụ PHP

Sau khi nâng cấp, bắt buộc khởi động lại dịch vụ PHP (php-fpm hoặc Apache). Việc cập nhật các gói RPM/DEB không tự động dừng các tiến trình PHP worker đang chạy. Tệp nhị phân (binary) cũ vẫn nằm trong bộ nhớ, khiến lỗ hổng tiếp tục tồn tại cho đến khi dịch vụ được khởi động lại.

Bước 3: Kiểm tra lại phiên bản

Sau khi khởi động lại, kiểm tra phiên bản PHP và PHP-FPM để chắc chắn hệ thống đã chạy bản vá. Lưu ý, một số bản phân phối Linux như Ubuntu vá lỗi trên phiên bản đang phát hành và giữ nguyên số phiên bản gốc, nên lệnh php -v có thể vẫn hiển thị số cũ dù gói đã được cập nhật. Trong trường hợp này, cần đối chiếu phiên bản gói đã cài với thông báo bảo mật của chính bản phân phối đó. Nếu dùng kho lưu trữ bên thứ ba và phiên bản chưa thay đổi sau khi cập nhật, kho có thể chưa có bản mới, khi đó nên chuyển sang gói của bản phân phối hoặc build từ mã nguồn.

5.2 Lệnh nâng cấp theo hệ điều hành

Debian 12 / Debian 13

# cập nhật chỉ mục kho lưu trữ (repository index)
apt update
# nâng cấp tất cả các gói php8.2
apt install php8.2-fpm php8.2-cli php8.2-{bz2,curl,gd,intl,mbstring,mysql,opcache,xml,zip}
# khởi động lại php-fpm
systemctl restart php8.2-fpm
# kiểm tra phiên bản
php8.2 -v
php-fpm8.2 -v

Nếu đang sử dụng php8.3 hoặc php8.4, thay "8.2" trong các lệnh trên bằng phiên bản PHP cụ thể mà máy chủ đang dùng.

Ubuntu 22.04 / 24.04

apt update
apt install php8.2-fpm php8.2-cli php8.2-{bz2,curl,gd,intl,mbstring,mysql,opcache,xml,zip}
systemctl restart php8.2-fpm
php8.2 -v
php-fpm8.2 -v

Rocky Linux 9 (kho lưu trữ Remi PHP)

# cập nhật các gói php
dnf update php php-fpm php-bz2 php-curl php-gd php-intl php-mbstring php-mysqlnd php-opcache php-xml php-zip
# khởi động lại dịch vụ
systemctl restart php-fpm
# kiểm tra phiên bản
php -v
php-fpm -v

6. Biện pháp giảm thiểu tạm thời trên máy chủ

Khi chưa thể nâng cấp PHP ngay, doanh nghiệp có thể áp dụng các biện pháp giảm thiểu tạm thời trên máy chủ. Các biện pháp này làm tăng độ khó cho việc khai thác nhưng vẫn có thể bị vượt qua bởi những kẻ tấn công có kỹ năng, vì vậy chỉ giúp giảm rủi ro và không thể thay thế việc vá lỗi:

• Quy tắc WAF: Chặn các yêu cầu POST có Content-Type: multipart/form-data nếu chúng có cấu trúc lồng nhau quá mức, số lượng thành phần (part) quá nhiều hoặc các trường dữ liệu (form field) có kích thước bất thường.
• Thiết lập trong tệp INI: session.upload_progress.enabled = Off` — loại bỏ một phương thức phổ biến thường được dùng để dàn dựng bộ nhớ (heap shaping) trong các cuộc tấn công khai thác.
• Chạy các tiến trình PHP (PHP workers) dưới quyền một người dùng chuyên biệt không có đặc quyền quản trị. Tuyệt đối không chạy PHP với quyền root.
• Điều chỉnh tham số memory_limit một cách hợp lý để gây khó khăn cho việc kích hoạt tình trạng thiếu bộ nhớ (OOM - Out of Memory), mà không làm ảnh hưởng đến hoạt động bình thường của ứng dụng.
• Network ACL: Hạn chế các địa chỉ IP nguồn có thể truy cập vào cổng web (web port) nếu không cần thiết phải mở quyền truy cập công khai.
• Bật tính năng ghi nhật ký truy cập (access logging) đầy đủ và giám sát các lưu lượng truy cập POST dạng multipart có dấu hiệu bất thường.

7. Vai trò của WAF trong lúc chờ vá lỗ hổng PHP

Tường lửa ứng dụng web (WAF) hoạt động ở Layer 7 trong mô hình OSI, có thể chặn các request POST multipart/form-data có cấu trúc lồng nhau quá mức, quá nhiều thành phần hoặc trường dữ liệu bất thường trước khi chúng chạm tới máy chủ. Cục An ninh mạng và Hiệp hội An ninh mạng quốc gia nhận định WAF được cấu hình tốt sẽ giảm đáng kể khả năng bị tấn công, giúp doanh nghiệp có thêm thời gian triển khai bản vá an toàn trong chiến lược phòng thủ nhiều lớp (Defense in Depth).

VNIS (VNETWORK Internet Security) là nền tảng bảo mật và tăng tốc Web/App/API của VNETWORK, bảo vệ theo thời gian thực trước tấn công DDoS đa tầng, bot độc hại và các hình thức khai thác lỗ hổng, kể cả lỗ hổng zero-day. Nền tảng ứng dụng AI để phát hiện sớm hành vi bất thường mà vẫn đảm bảo hiệu suất và trải nghiệm người dùng.

7.1 Mô hình bảo vệ hai lớp của VNIS

VNIS bảo vệ hệ thống của doanh nghiệp qua hai lớp, xử lý tấn công từ tầng hạ tầng mạng đến tầng ứng dụng:

• Lớp bảo vệ tầng hạ tầng: VNIS kết hợp AI Smart Load Balancing và Multi-CDN để xử lý các cuộc tấn công DDoS ở tầng mạng. AI tự động phân tích hành vi truy cập, phân phối lưu lượng hợp lý và loại bỏ nguồn lưu lượng bất thường trước khi gây quá tải hệ thống.
• Lớp bảo vệ tầng ứng dụng: VNIS triển khai WAAP (Web Application and API Protection) ứng dụng AI để ngăn chặn DDoS Layer 7, bot độc hại và các lỗ hổng bảo mật phổ biến theo danh sách OWASP Top 10. Lớp này bảo vệ trực tiếp logic xử lý của Web/App/API, nơi thường bị khai thác sâu và khó phát hiện.

7.2 Tính năng nổi bật của VNIS

• Phát hiện và ngăn chặn DDoS đa tầng (Layer 3/4/7) theo thời gian thực.
• WAAP tích hợp AI WAF với bộ quy tắc bảo mật được cập nhật liên tục, tự động lọc và chặn các cuộc tấn công khai thác lỗ hổng.
• Giám sát hành vi truy cập, phân tích log theo thời gian thực để phát hiện lưu lượng bất thường.
• Multi-CDN toàn cầu giúp duy trì tốc độ và độ ổn định của website kể cả khi bị tấn công.
• Đội ngũ SOC giám sát 24/7, hỗ trợ doanh nghiệp ứng phó nhanh khi có sự cố.

8. Kết luận

Lỗ hổng PHP2Shell cho thấy rủi ro có thể nằm ngay ở tầng nền tảng, nơi doanh nghiệp ít để ý khi rà soát bảo mật website. Ba việc cần ưu tiên lúc này là nâng cấp PHP lên phiên bản đã vá, khởi động lại dịch vụ để bản vá có hiệu lực và bổ sung lớp WAF để giảm rủi ro trong lúc triển khai. Nếu doanh nghiệp cần tư vấn giải pháp bảo vệ website và hệ thống Web/App/API trước các lỗ hổng mới, đội ngũ chuyên gia VNETWORK sẵn sàng hỗ trợ.

FAQ - Câu hỏi thường gặp về lỗ hổng PHP2Shell

1. Website WordPress có bị ảnh hưởng bởi lỗ hổng PHP2Shell không?

Có, nếu máy chủ chạy WordPress đang dùng PHP ở phiên bản chưa vá. Lỗ hổng nằm trong lõi trình thông dịch PHP chứ không nằm trong WordPress, nên việc cập nhật WordPress, theme hay plugin không khắc phục được. Doanh nghiệp cần nâng cấp chính phần mềm PHP trên máy chủ.

2. Website không có chức năng tải tệp lên có an toàn trước lỗ hổng PHP2Shell không?

Không. Lỗ hổng bị kích hoạt khi PHP phân tích request POST dạng multipart/form-data, trước khi mã ứng dụng được thực thi. Chỉ cần SAPI của PHP chấp nhận loại request này, website đã nằm trong diện bị đe dọa, kể cả khi không có tính năng tải tệp lên.

3. Vì sao đã cập nhật gói PHP mà máy chủ vẫn có thể bị khai thác?

Việc cập nhật gói RPM/DEB không tự động dừng các tiến trình PHP worker đang chạy. Tệp nhị phân cũ vẫn nằm trong bộ nhớ cho đến khi dịch vụ php-fpm hoặc Apache được khởi động lại, nên lỗ hổng vẫn tồn tại nếu bỏ qua bước này.

4. Đang dùng PHP 7.4 hoặc 8.1 thì nên xử lý lỗ hổng PHP2Shell thế nào?

Các nhánh PHP 7.x, 8.0 và 8.1 đã hết hỗ trợ và không có bản vá chính thức, nên doanh nghiệp cần chuyển sang PHP 8.2 trở lên. Trong thời gian chuẩn bị nâng cấp, có thể dùng bản sửa mã nguồn do nhóm bảo mật PHP cung cấp hoặc gói cập nhật từ nhà cung cấp hỗ trợ dài hạn, kết hợp các biện pháp giảm thiểu tạm thời và WAF.

5. WAF có thay thế được việc vá lỗ hổng PHP không?

Không. WAF giúp chặn các request khai thác đã biết và giảm đáng kể khả năng bị tấn công, nhưng vẫn có thể bị vượt qua bởi các biến thể khai thác mới. Nâng cấp PHP lên phiên bản đã vá vẫn là cách duy nhất để khắc phục triệt để.