Lỗ hổng PHP2Shell (CVE-2026-109618, CVE-2026-109619): website chạy PHP cần vá ngay — Net Solutions đã nâng cấp hệ thống khách hàng

Lỗ hổng PHP2Shell nằm trong chính PHP, nên mọi website PHP đang nhận truy cập — WordPress, WooCommerce, Joomla, Laravel — đều nằm trong vùng nguy cơ bị chiếm quyền máy chủ từ xa mà kẻ tấn công không cần mật khẩu. Ngày 21/10/2026, PHP phát hành bản vá 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Bài này giải thích lỗi, cách tự kiểm tra trong vài phút và những gì Net Solutions đã làm trên hệ thống khách hàng ngày 22/10.

1. PHP2Shell là gì và vì sao nguy hiểm hơn một lỗi plugin?

PHP2Shell là tên nhóm nghiên cứu Wiz Research đặt cho hai lỗ hổng trong lõi PHP, do họ phát hiện cùng Calif và OpenAI rồi báo cho PHP từ tháng 8/2026. Ngày 20/10, PHP báo trước một bản phát hành bảo mật khẩn; tối 21/10 theo giờ Việt Nam, bản vá chính thức ra đời kèm lời khuyên cập nhật ngay lập tức.

Nguồn: thông báo bảo mật của PHP và khuyến cáo 2026-018 của CERT-EU, ngày 21/10/2026.

Điều làm PHP2Shell khác một lỗi plugin thông thường: lỗi nằm ở tầng ngôn ngữ, chạy trước cả mã nguồn của trang. PHP đánh giá rủi ro cao nhất với cấu hình Apache mod_php, nơi chỉ một yêu cầu không cần đăng nhập đã đủ kích hoạt tấn công trước khi bất kỳ dòng mã ứng dụng nào chạy. Nhóm phát hiện đã trình diễn chiếm quyền không cần đăng nhập trên WordPress, Drupal và Joomla. Một trong các đường khai thác đi qua tính năng theo dõi tiến trình tải tệp (session upload progress) — tính năng bật sẵn mặc định từ PHP 5.4.

Chỉ cập nhật mới là giải pháp trọn vẹn. Các biện pháp tạm chỉ giảm bớt một số đường tấn công, không làm hệ thống trở nên an toàn.

— Thông báo bảo mật của PHP, 21/10/2026 (lược dịch)

Ngay trong ngày phát hành đã có nhiều mã khai thác thử nghiệm (PoC) xuất hiện công khai. Cloudflare cho biết đã thấy các đợt tấn công sớm nhắm vào lỗ hổng và triển khai luật tường lửa web để chặn; CERT-EU nhận định việc mã khai thác lan truyền làm tăng khả năng kẻ xấu đã bắt đầu khai thác. Quy mô khai thác thành công đến nay chưa được công bố đầy đủ — nhưng với một lỗi 9.2 điểm không cần đăng nhập, chờ thêm bằng chứng là đánh cược bằng chính máy chủ của mình.

2. Website nào bị ảnh hưởng?

Mọi bản cài PHP đang phục vụ yêu cầu web đều nằm trong vùng ảnh hưởng, bất kể chạy kiểu nào: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP hay LiteSpeed. Website làm bằng WordPress, WooCommerce, Joomla, Drupal, OpenCart, Magento, Laravel hay mã tự viết đều chạy trên PHP.

Nguồn: thông báo bảo mật và nhật ký thay đổi trên php.net, đọc ngày 23/10/2026.

Nhánh cũ là chỗ đáng lo nhất. PHP đã ngừng hỗ trợ 8.1 trở xuống; vì mức nghiêm trọng, đội bảo mật PHP có công bố bản vá ngược tối thiểu dạng mã nguồn cho 7.4, 8.0 và 8.1, nhưng đó là thứ dành cho người tự biên dịch PHP, không phải một nút bấm trong trang quản trị hosting. Theo một lượt quét Internet được giới bảo mật dẫn lại trong đợt này, khoảng 79% dịch vụ PHP để lộ số phiên bản đang chạy nhánh đã hết hỗ trợ.

Lỗ hổng cũng không dừng ở trang web. PHP còn chạy trong công cụ quản trị cơ sở dữ liệu dạng web, hộp thư webmail, bảng điều khiển hosting và cả thiết bị mạng có giao diện quản trị — những thứ hay bị bỏ sót khi rà soát.

3. Kiểm tra website của bạn trong 5 phút

1. Xác định website có chạy PHP không. WordPress, WooCommerce, Joomla, Drupal, OpenCart, Magento và Laravel đều chạy trên PHP. Không chắc thì hỏi đơn vị làm web cho bạn.
2. Xem phiên bản PHP đang phục vụ web. Với WordPress: vào Công cụ → Tình trạng trang web (Tools → Site Health), mở tab Thông tin (Info), mục Máy chủ (Server), xem dòng phiên bản PHP. Với hosting dùng cPanel: mở mục chọn phiên bản PHP của tên miền.
3. Đối chiếu với bảng ở mục 2. Thấp hơn bản tối thiểu của nhánh, hoặc thuộc nhánh 8.1 trở xuống, là cần xử lý ngay.
4. Hỏi nhà cung cấp hosting theo mã CVE nếu máy chủ dùng gói PHP của bản phân phối Linux hoặc bạn không vào được trang quản trị.

Bốn câu nên hỏi nguyên văn — câu nào nhận về câu trả lời mơ hồ thì đó là chỗ cần làm rõ:

• Phiên bản PHP: PHP đang phục vụ website của tôi (PHP-FPM hoặc module của web server, không phải bản dòng lệnh) là bản nào?
• Bản vá: máy chủ đã vá CVE-2026-109618 và CVE-2026-109619 chưa, vào ngày nào?
• Biện pháp tạm: nếu chưa vá, đã áp những biện pháp giảm thiểu nào, và bao giờ nâng?
• Máy chủ gốc: website đi qua Cloudflare hay tường lửa web thì máy chủ gốc có chặn truy cập trực tiếp không qua lớp đó không?

Câu đầu có lý do riêng: trên cùng một máy chủ, lệnh php -v ở dòng lệnh có thể trả về một số, còn tiến trình PHP-FPM đang phục vụ trang lại là bản khác. Khi kiểm kê hệ thống của mình, chúng tôi đo cả hai.

4. Net Solutions đã làm gì trong ngày 22/10?

Net Solutions vận hành nền tảng WebCloud cho website khách hàng và các ứng dụng của chính mình, nên PHP2Shell chạm thẳng vào hệ thống chúng tôi đang chịu trách nhiệm. Dưới đây là những việc đã làm — kèm cả phần chưa xong.

1. Kiểm kê toàn bộ dịch vụ PHP đang phục vụ web trên các máy chủ của chúng tôi chiều tối 22/10, đo phiên bản của tiến trình PHP-FPM chứ không chỉ bản dòng lệnh. Lượt kiểm kê mất khoảng 17 phút.
2. Áp biện pháp giảm thiểu tạm trên gần như toàn bộ dịch vụ PHP trong khoảng 40 phút: tắt session.upload_progress, hạ post_max_size và upload_max_filesize về 32M, nạp lại tiến trình PHP rồi đọc lại cấu hình thật để chắc nó có hiệu lực.
3. Tạm đóng các công cụ quản trị cơ sở dữ liệu dạng web đang mở ra Internet, đồng thời bật thêm ghi nhật ký truy cập để giám sát.
4. Nâng PHP cho các ứng dụng do Net Solutions vận hành: hệ thống quản trị lên 8.5.12, nền tảng quảng cáo NS Ads Xperts lên 8.4.27; đo lại phiên bản và kiểm trang chạy bình thường sau khi nâng.
5. Phát hành WebCloud 4.3.3 chạy PHP 8.3.36 cho các website WordPress trên nền tảng: thử trước trên 2 site, theo dõi 15 phút, rồi chia 6 đợt; site không có lớp CDN che chắn được nâng trước. Theo kết quả đợt triển khai, 83 site đã lên bản mới trong tối 22/10 và không site nào phải hoàn tác.

Ngay đêm 21 rạng sáng 22/10 — vài giờ sau khi PHP phát hành bản vá — nhật ký của chúng tôi đã ghi nhận các yêu cầu dò quét nhắm vào PHP; các yêu cầu đó đều bị từ chối. Đến thời điểm viết bài, chúng tôi chưa phát hiện dấu hiệu khai thác thành công trong các nhật ký đang có.

Hai điều chúng tôi nói thẳng. Thứ nhất, chúng tôi viết “chưa phát hiện”, không viết “không bị khai thác”: trước đợt này, một lớp proxy trên hạ tầng đang để tắt ghi nhật ký truy cập, nên có một khoảng thời gian chúng tôi không đủ dữ liệu để khẳng định. Nhật ký đã được bật lại. Bài học giống đợt xử lý lỗ hổng WordPress WP2Shell: thứ bị tắt âm thầm trên hạ tầng — khi đó là cơ chế kiểm tra bản cập nhật, lần này là nhật ký — chỉ lộ ra đúng lúc cần đến nó.

Thứ hai, giảm thiểu tạm không phải bản vá. Một số ít dịch vụ đặc thù — ứng dụng dựng riêng, ứng dụng còn chạy nhánh PHP cũ, hoặc phần mềm của bên thứ ba đang chờ nhà sản xuất phát hành bản vá — hiện vẫn được giữ bằng các lớp giảm thiểu và đang được xử lý riêng từng trường hợp. Chúng tôi không gọi việc đó là xong khi nó chưa xong.

Website của bạn do Net Solutions vận hành trên WordPress? Bạn có thể tự xem phiên bản PHP theo bước 2 ở mục 3. Thấy số thấp hơn bảng ở mục 2, gọi 0906.207.001 để được xử lý ngay.

5. Chưa nâng được PHP ngay thì làm gì?

Đơn vị kỹ thuật của bạn cần vài ngày để nâng PHP, ví dụ vì phải thử tương thích plugin? Hướng dẫn chính thức của PHP cho giai đoạn chờ gồm:

• Tắt theo dõi tiến trình tải tệp: đặt session.upload_progress.enabled=0 trong php.ini hoặc cấu hình pool PHP-FPM, rồi khởi động lại mọi tiến trình. Không dựa vào ini_set() hay tệp .user.ini.
• Giới hạn kích thước gửi lên: post_max_size 8M nếu trang không cần tải tệp, 32M nếu cần; giữ upload_max_filesize nhỏ hơn post_max_size.
• Xử lý giới hạn bộ nhớ đúng cách: PHP khuyên đặt memory_limit=-1 ở mức ứng dụng không ghi đè được và dùng giới hạn của container hoặc cgroup làm ranh giới; không thay bằng RLIMIT_AS hay RLIMIT_DATA vì chính chúng có thể kích hoạt lỗi.
• Với PHP 8.5: đặt thêm fatal_error_backtraces=0 và khởi động lại tiến trình.
• Ở web server hoặc proxy: giới hạn kích thước yêu cầu, số trường dữ liệu, số phần multipart và số header.

Một đoạn cấu hình tạm theo hướng dẫn trên, đặt trong tệp ini được nạp sau cùng rồi nạp lại PHP-FPM:

; Giảm thiểu tạm PHP2Shell — không thay được bản vá
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 30M

Có Cloudflare hay tường lửa web chưa phải là đã vá. Luật tường lửa chặn các mẫu tấn công đã biết, còn PHP bên dưới vẫn dính. Nếu máy chủ gốc vẫn nhận truy cập trực tiếp, kẻ biết địa chỉ gốc đi vòng qua lớp bảo vệ. Với hệ thống quan trọng chưa vá được, CERT-EU khuyên cân nhắc tách ứng dụng khỏi Internet cho tới khi bản vá được áp và kiểm chứng.

6. Sau khi vá, kiểm tra dấu hiệu bị xâm nhập thế nào?

Nâng PHP chặn lần tấn công tiếp theo, nhưng không gỡ được cửa hậu đã cài từ trước. Website đã chạy bản dính lỗi trong những ngày qua thì nên rà các điểm sau:

• Tài khoản quản trị: có tài khoản lạ nào bạn không tạo không (WordPress: Người dùng → Tất cả người dùng, lọc vai trò Quản trị viên).
• Tệp PHP lạ: thư mục tải lên như wp-content/uploads không nên chứa tệp .php nào.
• Tệp vừa bị sửa: tệp lõi hoặc giao diện có ngày sửa trong mấy ngày gần đây mà không ai cập nhật.
• Tác vụ định kỳ: cron lạ trên máy chủ hoặc trong WordPress.
• Nội dung lạ: liên kết cờ bạc, hoặc chuyển hướng sang trang khác khi vào từ Google.

Thấy dấu hiệu nào, đổi ngay mật khẩu quản trị, cơ sở dữ liệu và FTP (xem hướng dẫn đổi mật khẩu quản trị website), giữ lại một bản sao để điều tra trước khi dọn, và khôi phục từ bản sao lưu sạch nếu cần. Danh sách đầy đủ hơn cho người quản trị nằm trong checklist bảo mật WordPress 12 việc.

7. Câu hỏi thường gặp

WordPress đã cập nhật bản mới nhất, có cần lo PHP2Shell không?

Có. PHP2Shell là lỗi của PHP — phần mềm chạy bên dưới WordPress trên máy chủ — chứ không phải lỗi của WordPress, theme hay plugin. Cập nhật WordPress không thay đổi phiên bản PHP. Bạn phải kiểm tra và nâng PHP ở phía máy chủ, việc thường do nhà cung cấp hosting hoặc đơn vị vận hành website làm.

Website đã dùng Cloudflare thì an toàn chưa?

Chưa đủ. Cloudflare đã triển khai luật chặn các mẫu tấn công đã biết, giúp giảm rủi ro trong lúc chờ vá. Nhưng luật chỉ bắt được những gì đã biết, và nếu máy chủ gốc nhận truy cập trực tiếp thì kẻ tấn công có thể đi vòng qua Cloudflare. Nâng PHP vẫn là việc phải làm.

Nâng PHP có làm website bị lỗi không?

Nâng trong cùng một nhánh, ví dụ từ 8.3.30 lên 8.3.36, chủ yếu là sửa lỗi nên ít rủi ro. Nhảy nhánh, ví dụ từ 7.4 lên 8.2, có thể làm plugin hay giao diện cũ báo lỗi hoặc trắng trang. Hãy sao lưu trước và thử trên bản sao; gặp trắng trang sau khi cập nhật thì xem cách quay về bản cũ.

Website đang chạy PHP 7.4 thì nên làm gì?

PHP 7.4 đã hết hỗ trợ từ lâu và không có bản vá chính thức cho PHP2Shell. Lối ra bền vững là nâng lên nhánh còn hỗ trợ, từ 8.2 trở lên, sau khi kiểm tương thích. Trong lúc chờ, áp ngay các biện pháp tạm ở mục 5 và đặt trang sau lớp tường lửa web có khoá truy cập trực tiếp vào máy chủ gốc.

Website do Net Solutions vận hành có cần làm gì không?

Không cần thao tác kỹ thuật. Phần lớn website WordPress trên nền tảng WebCloud — 83 website — đã được nâng lên PHP 8.3.36 trong tối 22/10; số ít trang dựng riêng đang được xử lý theo từng trường hợp. Muốn chắc trang của mình thuộc nhóm nào, xem phiên bản PHP như mục 3 hoặc gọi cho chúng tôi.

Tài liệu gốc: thông báo bảo mật của PHP · khuyến cáo 2026-018 của CERT-EU · kho theo dõi của NCSC-NL.

Cập nhật 23/10/2026 bởi Công ty TNHH Net Solutions.