Lỗ hổng PHP2Shell: chủ website WordPress cần kiểm tra và vá thế nào

Nếu website hoặc shop của bạn chạy WordPress, WooCommerce hay bất kỳ mã nguồn nào viết bằng PHP, đây là việc nên làm ngay hôm nay. Ngày 21/10/2026, dự án PHP phát hành bản vá cho hai lỗ hổng nghiêm trọng, được giới bảo mật gọi chung là lỗ hổng PHP2Shell, cho phép kẻ tấn công chạy mã trên máy chủ mà không cần đăng nhập [S1][S2].

Bài viết tóm tắt chuyện gì đã xảy ra, rồi đi thẳng vào phần thực hành: cách kiểm tra phiên bản PHP, cách vá, cách tạm gỡ website đúng chuẩn Google nếu chưa vá kịp, và những gì cần xem trong Search Console sau đó.

Lỗ hổng PHP2Shell là gì

Hai lỗ hổng có mã CVE-2026-109618 và CVE-2026-109619 [S1]. Lỗi thứ nhất liên quan đến cách PHP xử lý khi một request chạm giới hạn bộ nhớ (memory_limit), lỗi thứ hai liên quan đến trạng thái nội bộ còn sót lại từ request trước [S1][S2]. Cả hai đều có thể dẫn tới thực thi mã từ xa (remote code execution, RCE) mà không cần xác thực [S1].

Theo thông báo trên php.net, mọi bản cài PHP đang phục vụ web đều có rủi ro, gồm PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed [S1]. Rủi ro cao nhất là mod_php, nơi đã có bản khai thác cho thấy một request không cần đăng nhập có thể kích hoạt lỗi trước khi bất kỳ dòng mã ứng dụng nào chạy [S1]. Theo hồ sơ CVE chính thức, các phiên bản bị ảnh hưởng là nhánh 8.2 trước 8.2.35, 8.3 trước 8.3.36, 8.4 trước 8.4.27 và 8.5 trước 8.5.12 [S10]. Các nhánh cũ hơn (8.1 trở xuống) đã hết hỗ trợ nên không có bản vá chính thức; nếu website còn chạy các bản này, nên nâng lên nhánh còn được hỗ trợ [S1].

Các bản đã vá là PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35 [S1][S2][S3].

Ảnh: The PHP Foundation (bài viết ngày 21/10/2026)

Cả CVE-2026-109618 và CVE-2026-109619 có điểm CVSS v4.0 9.2, mức Critical (nghiêm trọng), vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N [S1][S10]. Con số 10/10 lan truyền trên mạng trước đó là sai; The PHP Foundation xác nhận điểm thực tế là 9.2 [S2]. Vì mã CVE bị lộ sớm, dự án PHP đã dời ngày phát hành lên sớm một ngày, sang 21/10 lúc 14:00 UTC, tức 21:00 giờ Việt Nam [S2].

Vì sao chủ website Việt cần xử lý ngay

Cơ quan An ninh mạng và Hạ tầng Hoa Kỳ (CISA) khuyến nghị các tổ chức vá ngay lập tức [S3]. CISA cho biết tại thời điểm đăng cảnh báo, họ chưa ghi nhận việc khai thác thực tế, nhưng lỗ hổng vẫn là rủi ro nếu không vá [S3]. Bài của The PHP Foundation cũng cho biết sau khi thông tin bị lộ, các bản khai thác thử nghiệm (PoC) được phát triển nhanh hơn [S2].

Ảnh: CISA (cảnh báo ngày 21/10/2026)

Trạng thái khai thác (kiểm tra ngày 23/10/2026, giờ Việt Nam): hai mã CVE-2026-109618 và CVE-2026-109619 chưa có trong danh mục Lỗ hổng đã bị khai thác (KEV) của CISA, bản danh mục 2026.10.21 [S11]. Điều này có nghĩa là CISA chưa xác nhận vụ khai thác thật nào, không có nghĩa là an toàn để chờ; hãy vá càng sớm càng tốt.

Với người Việt, nhóm cần chú ý nhất là:

• Shop và blog chạy WordPress, WooCommerce trên shared hosting hoặc VPS tự quản.
• Website công ty do agency làm từ vài năm trước, chạy PHP cũ và không còn ai bảo trì.
• Công cụ phụ chạy PHP mà bạn ít để ý: phpMyAdmin, landing page cũ, trang quản trị nội bộ.

Kiểm tra phiên bản PHP và vá PHP2Shell

Cách kiểm tra phiên bản PHP website đang chạy

CISA lưu ý PHP thường nằm bên trong phần mềm khác nên không phải lúc nào cũng dễ thấy [S3]. Có ba cách kiểm tra phổ biến:

1. Trong WordPress: vào Tools > Site Health > Info (Công cụ > Tình trạng website > Thông tin), mở mục Server để xem phiên bản PHP [S6].
2. Trong trang quản lý hosting: cPanel, DirectAdmin hay các bảng điều khiển của nhà cung cấp Việt Nam thường có mục chọn phiên bản PHP cho từng website. Nếu không thấy, hỏi bộ phận hỗ trợ của hosting.
3. Trên VPS: chạy lệnh dưới đây.

php -v                 # phiên bản PHP dòng lệnh (CLI)
php-fpm8.3 -v          # phiên bản PHP-FPM, đổi 8.3 theo bản bạn cài
curl -sI https://ten-mien-cua-ban.vn | grep -i x-powered-by

Lưu ý: bản PHP ở dòng lệnh có thể khác bản PHP mà web server dùng, nên hãy kiểm tra đúng bản đang chạy website. Ngoài ra, php.net cho biết các bản phân phối Linux và nhà cung cấp hỗ trợ dài hạn (LTS) đã nhận bản vá từ trước [S1]. Gói PHP của Ubuntu hay Debian có thể đã được vá dù số phiên bản không giống hệt 8.3.36, nên hãy đọc thông báo bảo mật của bản phân phối bạn dùng.

Các bước vá PHP2Shell cho WordPress và shop

1. Sao lưu mã nguồn và cơ sở dữ liệu trước khi đổi gì.
2. Cập nhật lên bản đã vá của nhánh đang dùng: 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35 [S1]. Trên VPS dùng gói của bản phân phối, ví dụ sudo apt update && sudo apt upgrade, rồi khởi động lại PHP-FPM hoặc Apache. Trên shared hosting, chọn bản mới trong bảng điều khiển hoặc nhờ hosting cập nhật.
3. Nếu đang chạy PHP 8.1 trở xuống: dự án PHP không còn phát hành bản cập nhật cho các nhánh này [S1]. Hãy nâng lên nhánh được hỗ trợ, hoặc hỏi nhà cung cấp có bản vá chuyển ngược (backport) hay không [S1]. Trước khi nâng, kiểm tra theme và plugin có tương thích với bản PHP mới, theo hướng dẫn nâng cấp PHP của WordPress [S7].
4. Rà dấu hiệu bất thường: CISA khuyên theo dõi các tiến trình PHP tự mở shell hoặc tải công cụ về máy chủ [S3].

Nếu chưa vá ngay được, php.net có liệt kê một số thiết lập giúp giảm bớt rủi ro, như hạ post_max_size hay tắt session.upload_progress.enabled, nhưng nói rõ chúng không làm bản cài an toàn; chỉ có cập nhật mới là giải pháp đầy đủ [S1]. CISA cho biết tường lửa ứng dụng web (WAF) có thể bảo vệ một phần trong lúc chờ vá, còn hệ thống không cập nhật được ngay hoặc chạy PHP 8.1 trở xuống thì nên tạm đưa offline [S3].

Tạm gỡ website đúng cách để không mất thứ hạng

Nếu buộc phải tạm gỡ website, John Mueller của Google khuyên trên Bluesky ngày 21/10: dùng mã HTTP 503, đừng để request bị timeout hoặc trả 404, 500, và có thể làm việc này bên ngoài PHP, bằng cách trỏ DNS sang chỗ khác hoặc qua CDN [S5].

Tài liệu "Tạm dừng hoặc vô hiệu hóa website" của Google Search Central nói thêm [S4]:

• Chỉ nên trả 503 cho cả website khi gỡ gấp trong 1–2 ngày. Lâu hơn thì nên có một trang chủ tạm trả mã 200 cho người dùng tìm thấy.
• Thêm header Retry-After, dùng trang HTML tĩnh, nhẹ.
• Không trả 503 cho robots.txt, vì như vậy sẽ chặn toàn bộ việc thu thập dữ liệu.
• Không dùng 403, 404, 410, noindex hay công cụ xóa URL tạm thời trong Search Console, vì sẽ làm URL rơi khỏi Google.

Ảnh: PNTech tự thiết kế, theo php.net, CISA và Google Search Central

Vì mod_php có thể bị khai thác trước khi mã ứng dụng chạy [S1], trang bảo trì nên được trả từ web server, CDN hoặc một máy chủ khác, không đi qua PHP. Chế độ bảo trì có sẵn của WordPress (file .maintenance) vẫn trả 503 kèm Retry-After, nhưng nó chạy bằng chính PHP, nên không thay được việc chặn ở tầng ngoài.

Ví dụ với Nginx, đặt file bao-tri.html tĩnh trong /var/www/bao-tri và giữ robots.txt thật trong thư mục đó, rồi tạm thay khối server của website:

server {
    listen 443 ssl;
    server_name ten-mien-cua-ban.vn;
    # giữ nguyên các dòng ssl_certificate hiện có
    root /var/www/bao-tri;
    error_page 503 /bao-tri.html;
    location = /robots.txt { try_files $uri =404; }
    location = /bao-tri.html { internal; add_header Retry-After 7200 always; }
    location / { return 503; }
}

Với Apache (cần bật mod_rewrite và mod_headers):

ErrorDocument 503 /bao-tri.html
Header always set Retry-After "7200"
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/(bao-tri\.html|robots\.txt)$
RewriteRule ^ - [R=503,L]

Nếu dùng mod_php, an toàn hơn là tắt hẳn module PHP trong thời gian bảo trì hoặc chặn ngay ở CDN. Sau khi cấu hình, kiểm tra bằng curl như Google gợi ý [S4]:

curl -I https://ten-mien-cua-ban.vn/            # mong đợi: 503 và Retry-After
curl -I https://ten-mien-cua-ban.vn/robots.txt  # mong đợi: 200

Muốn hiểu kỹ hơn về các mã lỗi này, xem bài mã lỗi HTTP trong SEO: 404 mềm, 500 và 503 và bài tệp robots.txt trên PNTech.

Kiểm tra Search Console sau khi vá

Khi đã vá xong, bỏ trang 503 càng sớm càng tốt. Google cho biết trong lúc website trả 503, hệ thống không thể làm mới tiêu đề, mô tả hay dữ liệu có cấu trúc của trang [S4]. Sau đó, kiểm tra theo thứ tự:

1. Mã trả về: dùng curl kiểm tra trang chủ và vài trang sản phẩm đã trả 200, robots.txt trả 200.
2. Crawl stats (Thống kê thu thập dữ liệu) trong Search Console: xem số phản hồi 5xx và trạng thái host trong những ngày bảo trì [S8].
3. Báo cáo Pages: theo dõi vài ngày xem số trang bị loại khỏi chỉ mục có tăng không.
4. URL Inspection: chạy Test live URL cho trang chủ, danh mục và sản phẩm bán chạy [S9].

Ảnh: PNTech tự thiết kế

Nếu website của bạn chạy Next.js thay vì PHP thì không bị ảnh hưởng bởi lỗ hổng này, nhưng vẫn nên rà các bản vá riêng, như trong bài bản vá bảo mật Next.js tháng 10/2026. Danh sách công cụ PNTech đang dùng để quản lý website có ở trang Tool khuyên dùng.

Kết luận

Với lỗ hổng PHP2Shell, thứ tự ưu tiên khá rõ: xác định mọi nơi đang chạy PHP, cập nhật lên 8.5.12, 8.4.27, 8.3.36 hoặc 8.2.35, và rà dấu hiệu bất thường [S1][S3]. Chỉ tạm gỡ website khi thật sự chưa vá được, và khi gỡ thì trả 503 từ bên ngoài PHP, có Retry-After, giữ robots.txt hoạt động, trong thời gian càng ngắn càng tốt [S4][S5].

Làm đúng các bước này, bạn vừa giảm rủi ro bị chiếm máy chủ, vừa hạn chế ảnh hưởng tới thứ hạng trên Google.

Nguồn tham khảo

• [S1] PHP.net, "Security advisory: Critical remote code execution vulnerabilities, update now" (21/10/2026): https://www.php.net/archive/2026.php#2026-10-21-5
• [S2] The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security" (21/10/2026): https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
• [S3] CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" (21/10/2026): https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• [S4] Google Search Central, "Temporarily pause or disable a website": https://developers.google.com/search/docs/crawling-indexing/pause-online-business
• [S5] Search Engine Roundtable, Barry Schwartz, "Google On Taking Sites Down When Fixing The Emergency PHP Exploit - PHP2Shell" (21/10/2026): https://www.seroundtable.com/google-php2shell-42353.html
• [S6] WordPress Documentation, "Site Health screen": https://wordpress.org/documentation/article/site-health-screen/
• [S7] WordPress Developer Resources, "Upgrading PHP": https://developer.wordpress.org/advanced-administration/upgrade/php/
• [S8] Search Console Help, "Crawl Stats report": https://support.google.com/webmasters/answer/9679690
• [S9] Search Console Help, "URL Inspection tool": https://support.google.com/webmasters/answer/9012289
• [S10] CVE.org, CVE-2026-109618 và CVE-2026-109619: https://www.cve.org/CVERecord?id=CVE-2026-109618 , https://www.cve.org/CVERecord?id=CVE-2026-109619
• [S11] CISA, Known Exploited Vulnerabilities Catalog (bản 2026.10.21, kiểm tra 23/10/2026): https://www.cisa.gov/known-exploited-vulnerabilities-catalog