PHP2Shell: Bảo vệ website với Cloudflare WAF

Cuối tháng 10/2026, người vận hành website phải chạy đua với lỗ hổng PHP2Shell trong lõi PHP. Đội kỹ thuật phải vá, cập nhật và kiểm tra, trong khi kẻ tấn công đã ra tay từ trước khi bản vá ra đời.

Bài viết này tóm tắt những gì đã xảy ra với PHP2Shell, lý do chỉ vá thôi là chưa đủ nhanh, và một cách tiếp cận bổ sung: đặt một cổng bảo vệ ở lối vào website bằng Cloudflare, song song với việc vá.

1. Chuyện gì đã xảy ra với PHP2Shell?

Ngày 21/10/2026, PHP công bố hai lỗ hổng nghiêm trọng là CVE-2026-109618 và CVE-2026-109619, gọi chung là PHP2Shell. Cả hai đều được chấm 9.2/10 theo thang CVSS v4.0 và nằm trong PHP, nền tảng đang chạy khoảng 70% số website trên thế giới theo W3Techs.

Điểm đáng chú ý: thông tin đã bị rò rỉ và tấn công thật đã diễn ra trước khi bản vá được phát hành.

2. PHP2Shell nguy hiểm đến mức nào?

PHP2Shell cho phép kẻ tấn công chạy mã từ xa mà không cần đăng nhập, đọc dữ liệu nhạy cảm trong bộ nhớ, hoặc làm sập dịch vụ. Lỗi nằm trong chính lõi PHP, nên ảnh hưởng mọi web server chạy PHP 5.4 trở lên.

Cơ chế: hai lỗi quản lý bộ nhớ

Cả hai lỗi xảy ra khi PHP đang xử lý một request HTTP thì bị gián đoạn giữa chừng:

CVE-2026-109618: khi hết bộ nhớ, PHP dừng lúc dữ liệu nội bộ của request mới được khởi tạo một nửa. Bước dọn dẹp sau đó lại dùng dữ liệu dở dang này như dữ liệu hợp lệ.
CVE-2026-109619: sau một lỗi nghiêm trọng (fatal error), trạng thái nội bộ vẫn trỏ tới vùng nhớ đã được giải phóng. Request tiếp theo trên cùng tiến trình có thể dùng lại trạng thái cũ này.

Kẻ tấn công kích hoạt các tình huống trên bằng request được chế tạo đặc biệt. Tính năng theo dõi tiến trình upload của PHP (session upload progress) là một trong các đường khai thác đã được xác nhận.

Ai bị ảnh hưởng?

PHP cho biết mọi cách triển khai phục vụ web đều có rủi ro: PHP-FPM, Apache với mod_php, php-cgi, FrankenPHP và LiteSpeed. Rủi ro cao nhất là mod_php, nơi một request không cần xác thực có thể kích hoạt tấn công trước cả khi code ứng dụng chạy.

Một trong các nhóm nghiên cứu công bố lỗ hổng đã thử nghiệm trên WordPress, Drupal và Joomla, và xác nhận có thể chạy mã từ xa không cần đăng nhập, cũng như đọc được mật khẩu, token xác thực và API key từ bộ nhớ PHP.

Với doanh nghiệp, điều này có nghĩa là gì?

Mất quyền kiểm soát máy chủ: kẻ tấn công có thể cài mã độc hoặc sửa nội dung website.
Lộ dữ liệu: thông tin khách hàng, mật khẩu cơ sở dữ liệu, API key có thể bị đọc trộm.
Gián đoạn kinh doanh: website có thể bị làm sập, ảnh hưởng bán hàng và chăm sóc khách hàng.

Cập nhật WordPress hay plugin không sửa được lỗi này. Phải cập nhật chính phần mềm PHP đang chạy trên máy chủ.

3. Vì sao chỉ vá thôi là chưa đủ nhanh?

Vá PHP là giải pháp duy nhất sửa tận gốc PHP2Shell. Nhưng câu chuyện PHP2Shell cho thấy luôn có một khoảng trống giữa lúc kẻ tấn công ra tay và lúc máy chủ được vá xong. Khoảng trống đó đến từ bốn lý do:

Tấn công đến trước bản vá. Thông tin bị rò rỉ trước ngày công bố, và Cloudflare đã thấy lưu lượng tấn công nhắm vào khách hàng trước khi bản vá phát hành.
Vá không phải lúc nào cũng làm ngay được. Nhiều website chạy trên hosting do nhà cung cấp quản lý PHP. Khi đó doanh nghiệp phải chờ nhà cung cấp cập nhật.
Phiên bản cũ không còn được vá. PHP 8.1 trở xuống không còn nhận bản cập nhật từ dự án PHP. PHP 8.2 cũng sẽ hết hỗ trợ vào ngày 31/12/2026.
Vá xong vẫn có thể còn biến thể. Hai ngày sau, PHP công bố CVE-2026-115560, ảnh hưởng cả các bản đã vá như 8.5.12 trong một số cấu hình hiếm gặp. Biến thể này sẽ được sửa trong bản phát hành định kỳ tiếp theo.

Đây chính là bài toán "vá mãi không kịp" của người vận hành. Câu hỏi đặt ra: làm sao để giảm rủi ro trong lúc chờ vá?

4. Giải pháp bổ sung: đặt một cổng bảo vệ ở lối vào website

Thay vì chỉ trông vào việc vá từng máy chủ, có thể thêm một lớp nữa: mọi lưu lượng vào website phải đi qua một cổng kiểm soát trước. Cổng này lọc bớt request độc hại trước khi chúng tới máy chủ thật. Cloudflare là một dịch vụ hoạt động theo cách này: đứng trước máy chủ, kiểm tra lưu lượng và chặn những request có dấu hiệu tấn công.

Cloudflare là ai?

Cloudflare là công ty hạ tầng Internet, cung cấp các dịch vụ như mạng phân phối nội dung (CDN), tường lửa ứng dụng web (WAF) và chống tấn công từ chối dịch vụ (DDoS). Cloudflare ít khi hiện diện trước mắt người dùng, nhưng khoảng 20% website trên thế giới đang dùng dịch vụ này.

Vì đứng trước rất nhiều website, Cloudflare quan sát được các đợt tấn công mới trên toàn mạng lưới và cập nhật luật cho mọi khách hàng. Vì vậy, lớp bảo vệ này hiệu quả đến đâu phụ thuộc vào việc luật được cập nhật nhanh đến mức nào.

Cổng bảo vệ hoạt động thế nào?

Khi bản ghi DNS của website được bật proxy, người truy cập kết nối tới Cloudflare thay vì tới máy chủ thật. Cloudflare kiểm tra request, rồi mới chuyển request hợp lệ về máy chủ gốc. Địa chỉ IP thật của máy chủ cũng được ẩn đi.

Request hợp lệ đi qua Cloudflare tới máy chủ gốc. Đường gọi thẳng vào IP gốc chỉ bị chặn khi máy chủ được cấu hình như phần ngay dưới đây.

Điều kiện để máy chủ thật thật sự được che chắn

Ẩn IP thôi chưa đủ. Nếu kẻ tấn công tìm ra IP gốc, chúng có thể gọi thẳng vào máy chủ và đi vòng qua Cloudflare. Cloudflare khuyến nghị:

Chỉ cho phép kết nối từ dải IP của Cloudflare vào máy chủ gốc, chặn mọi nguồn khác.
Rà soát các bản ghi DNS không qua proxy (SPF, TXT…) để chắc chúng không lộ IP máy chủ.
Không đặt dịch vụ email trên cùng máy chủ với website, vì email có thể làm lộ IP.
Đổi IP máy chủ sau khi chuyển sang Cloudflare, vì lịch sử DNS cũ vẫn còn lưu IP cũ.
Hoặc dùng Cloudflare Tunnel: máy chủ tự mở một đường kết nối riêng (tunnel) ra Cloudflare, nên không cần IP công khai hay mở cổng nào, kẻ tấn công không có đường gọi thẳng vào.

5. Cloudflare đã chặn PHP2Shell như thế nào?

Cloudflare bật luật chặn PHP2Shell từ trước khi lỗ hổng được công bố chính thức, và khách hàng dùng WAF của Cloudflare, cả gói Free lẫn trả phí, được bảo vệ mặc định.

Gói Free và gói trả phí khác nhau ra sao?

Gói Free: luật mới nằm trong Cloudflare Managed Free Ruleset, được bật tự động, không cần làm gì thêm.
Gói Pro, Business, Enterprise: luật nằm trong Cloudflare Managed Ruleset. Quản trị viên nên kiểm tra bộ luật này đang được triển khai ở chế độ Block (chặn).

Vì sao cần một tính năng mới: Full Transaction Detection

Cloudflare cho biết chỉ nhìn vào request thì không phải lúc nào cũng phân biệt được khai thác với truy cập bình thường. Vì vậy họ phát triển Full Transaction Detection, một tính năng WAF mới xét cả request lẫn phản hồi từ máy chủ gốc trong cùng một giao dịch HTTP.

Cách tính năng này bảo vệ gồm hai lớp:

Request có dấu hiệu khai thác rõ ràng bị chặn ngay ở Cloudflare.
Nếu request lọt qua, Cloudflare vẫn có thể chặn phản hồi của máy chủ gốc trước khi nó về tới kẻ tấn công. Nhờ vậy dữ liệu bị lộ không ra được bên ngoài.

Các luật chặn PHP2Shell là những luật đầu tiên Cloudflare phát hành dùng khả năng này. Tính năng được bật tự động cho mọi gói, kể cả Free.

Một cuộc đua liên tục

Cloudflare ghi nhận kẻ tấn công liên tục biến đổi payload để né luật, và đội phân tích của họ cập nhật luật theo.

Với biến thể CVE-2026-115560 công bố ngày 23/10, Cloudflare cho biết luật hiện có vẫn bảo vệ, với điều kiện website giữ nguyên tên mặc định của trường session.upload_progress.name.

6. Lợi ích ngoài bảo mật: nhanh hơn, nhẹ tải hơn, chi phí thấp

Đặt Cloudflare ở lối vào không chỉ để chặn tấn công. Cùng một lớp đó còn mang lại ba lợi ích vận hành.

Website tải nhanh hơn. Cloudflare lưu bản sao nội dung (cache) tại các trung tâm dữ liệu trên khắp thế giới, gần người dùng hơn.
Máy chủ đỡ tải. Nội dung được phục vụ từ cache nên số request phải đi tới máy chủ gốc giảm xuống. Cloudflare cũng tích hợp chống tấn công DDoS cùng với CDN.
Chi phí khởi đầu thấp. Gói Free đã có bộ luật WAF miễn phí (Free Managed Ruleset), bao gồm luật chặn PHP2Shell, được bật tự động. Bộ luật đầy đủ có từ gói Pro, giá 20 USD/tháng khi trả theo năm.

(Các nhà cung cấp cloud như AWS và Azure cũng có dịch vụ WAF tương tự, với cách tính phí và cấu hình mặc định khác nhau.)

Triển khai có phức tạp không?

Trong nhiều trường hợp, doanh nghiệp không phải viết lại hệ thống. Bước chính là chuyển quản lý DNS của tên miền sang Cloudflare và bật proxy cho các bản ghi DNS của website.

Tuy vậy, để máy chủ thật không bị gọi thẳng, vẫn cần cấu hình thêm phía máy chủ như ở mục 4. Phần này nên do đội kỹ thuật thực hiện.

7. Cloudflare không phải liều thuốc vạn năng

Cloudflare giảm rủi ro trong lúc chờ vá, nhưng không thay được việc vá PHP. Chính Cloudflare khuyến nghị khách hàng vá PHP, và coi WAF là một lớp phòng thủ bổ sung. Có sáu giới hạn cần biết:

Chỉ chặn được những gì đã có luật. WAF nhận diện tấn công dựa trên luật do nhà cung cấp phát hành. Khi chưa có luật cho một lỗ hổng mới, website phía sau vẫn có thể bị khai thác. Với PHP2Shell, Cloudflare bật luật trước ngày công bố, nhưng không có gì bảo đảm lần sau cũng như vậy.
Không hoàn tác được những gì đã chạy. Chặn phản hồi giúp dữ liệu không lọt ra ngoài, nhưng không đảo ngược được mã đã chạy trên máy chủ gốc.
Luật có thể bị né. Kẻ tấn công liên tục biến đổi payload để vượt WAF.
Chỉ bảo vệ lưu lượng đi qua Cloudflare. Request gọi thẳng vào IP máy chủ gốc sẽ không bị kiểm tra.
Phụ thuộc cấu hình. Gói trả phí phải bật đúng chế độ Block. Website đã đổi session.upload_progress.name không được luật WAF bảo vệ trước biến thể CVE-2026-115560.
Thêm một điểm phụ thuộc. Khi Cloudflare gặp sự cố, các website dùng Cloudflare cũng bị ảnh hưởng.

8. Doanh nghiệp nên làm gì ngay bây giờ?

Việc quan trọng nhất là vá PHP. Các bước còn lại giúp giảm rủi ro trong lúc vá và sau khi vá.

Vá tận gốc

☐ Liệt kê các máy chủ đang chạy PHP và phiên bản của từng máy. Nếu hosting quản lý PHP, yêu cầu nhà cung cấp cập nhật.
☐ Nâng cấp lên 8.2.35, 8.3.36, 8.4.27 hoặc 8.5.12 trở lên, theo nhánh đang dùng.
☐ Với PHP 8.1 trở xuống: liên hệ nhà phân phối hoặc nhà cung cấp hỗ trợ dài hạn (LTS) để lấy bản vá backport, hoặc nâng lên phiên bản còn hỗ trợ.
☐ Lên kế hoạch chuyển khỏi PHP 8.2 trước ngày 31/12/2026.

Giảm rủi ro tạm thời (không thay được việc vá)

☐ Đặt session.upload_progress.enabled=0 trong php.ini, FPM pool hoặc cấu hình máy chủ, rồi khởi động lại mọi worker. Không dùng ini_set() hay .user.ini cho thiết lập này.
☐ Giữ thiết lập trên cho tới bản phát hành định kỳ tiếp theo của PHP, để chặn biến thể CVE-2026-115560.

Cổng bảo vệ Cloudflare

☐ Bật proxy (đám mây cam) cho các bản ghi DNS trỏ tới website.
☐ Chặn truy cập trực tiếp vào máy chủ gốc: cấu hình firewall chỉ nhận IP của Cloudflare, hoặc dùng Cloudflare Tunnel và cập nhật cloudflared thường xuyên.
☐ Gói trả phí: kiểm tra Managed Ruleset đang ở chế độ Block.
☐ Xem Security > Security Analytics > Events trên Cloudflare, lọc theo các luật PHP2Shell để biết website đã bị dò quét hay chưa.

9. Nếu nghi ngờ website đã bị khai thác

Vì PHP2Shell đã bị khai thác trước khi có bản vá, website chưa vá kịp trong khoảng thời gian đó nên được kiểm tra. Nếu thấy dấu hiệu bất thường, xử lý theo thứ tự sau:

Cô lập máy chủ. Ngắt kết nối mạng của máy chủ gốc. Chặn bằng luật trên Cloudflare chỉ có tác dụng với lưu lượng đi qua Cloudflare, không chặn được truy cập thẳng vào máy chủ.
Xem nhật ký. Đối chiếu sự kiện bảo mật trên Cloudflare (lọc theo các luật PHP2Shell) với nhật ký máy chủ web và PHP, để biết request khai thác đến từ đâu và lúc nào.
Vá PHP trước khi mở lại. Khôi phục từ bản sao lưu sạch lên một máy chủ chưa vá thì vẫn có thể bị tấn công lại.
Đổi toàn bộ thông tin bí mật. Đổi mật khẩu cơ sở dữ liệu, API key, token và khóa bí mật của ứng dụng. Lý do: lỗ hổng có thể làm lộ dữ liệu trong bộ nhớ PHP, kể cả các thông tin này.

10. Kết luận: vá ở bên trong, gác ở lối vào

PHP2Shell cho thấy kẻ tấn công có thể ra tay trước cả khi bản vá ra đời. Vá PHP vẫn là việc bắt buộc, nhưng một cổng bảo vệ như Cloudflare giúp doanh nghiệp giảm rủi ro trong khoảng trống trước khi vá xong, với chi phí khởi đầu thấp và thường không phải thay đổi lớn hệ thống.

Cách làm gồm hai lớp: vá phần mềm ở bên trong, và đặt Cloudflare gác ở lối vào. Hai lớp bổ sung cho nhau, không lớp nào thay được lớp còn lại.

PHP2Shell và bài học “vá mãi không kịp”: Đặt cổng bảo vệ Cloudflare trước website