PHP2Shell: lỗ hổng PHP khiến cả chính phủ tự tắt website, vá thế nào?

Sáng thứ Tư, bạn gõ địa chỉ trang web quen thuộc để tra một thủ tục hành chính, và màn hình chỉ hiện một dòng trơ trọi: "Trang web tạm thời không truy cập được". Không bảo trì định kỳ, không báo trước. Bạn thử trang khác, rồi trang khác nữa, đều im lặng như nhau.

Đó là cảnh tượng có thật ở nhiều nước vào ngày 21/10/2026. Thủ phạm không phải hacker đã đột nhập, mà là nỗi lo về một cặp lỗ hổng mang tên PHP2Shell nằm ngay trong PHP, ngôn ngữ đứng sau phần lớn website trên thế giới. Bài này giải thích chuyện gì đã xảy ra, vì sao lỗi này nghiêm trọng đến mức các cơ quan chính phủ chọn tự tắt web, và quan trọng nhất: làm sao biết máy chủ của bạn đã an toàn chưa.

48 giờ hỗn loạn bắt đầu từ đâu?

Thông thường, một lỗ hổng lớn được xử lý theo kiểu "vá trong im lặng": nhà phát triển nhận báo cáo, âm thầm sửa, phát hành bản vá, rồi mới công bố chi tiết. PHP cũng định làm đúng như vậy. Nhưng kế hoạch đổ vỡ.

Diễn biến diễn ra rất nhanh:

• Thứ Ba 20/10: một bài đăng trên Hacker News thông báo sẽ có người công bố hai lỗi chưa vá của PHP vào ngày 22/10, trong khi bản vá chưa sẵn sàng. Bài bị gỡ, nhưng ảnh chụp màn hình đã lan đi, trong đó có ảnh một công cụ khai thác tên PHP2Shell.
• Cùng lúc: công ty bảo mật watchTowr xem xét những gì bị rò rỉ và xác nhận các lỗi là thật, cho phép Remote Code Execution (thực thi mã từ xa).
• Đội PHP buộc phải lên lịch phát hành khẩn cấp, kèm lời nhắn có thể phát hành sớm hơn nếu xuất hiện tấn công.
• Sáng thứ Tư 21/10: Cloudflare ghi nhận những đợt tấn công đầu tiên nhắm vào các trang PHP và tung ra luật tường lửa để chặn bớt.
• Chiều 21/10: bản vá ra mắt, sớm hơn một chút so với mốc 14:00 UTC (21:00 giờ Việt Nam) đã hẹn.

Hãy hình dung bạn là thợ khoá vừa phát hiện ổ khoá phổ biến nhất thành phố có thể mở bằng một chiếc kẹp tóc. Bạn định lặng lẽ thay lõi cho từng nhà, nhưng trước khi kịp làm thì hướng dẫn mở khoá đã bị dán khắp các cột điện. Đó chính là tình thế của đội PHP.

Vì sao cả chính phủ chọn tự "tắt đèn"?

Mức độ nghiêm trọng thể hiện rõ nhất qua những trang web biến mất. Ở Hà Lan, trang digid.nl, cổng đăng nhập chính của chính phủ, chỉ còn một trang trắng báo tạm ngừng hoạt động. MijnOverheid sập theo, cùng với website của quốc hội và của NCSC, cơ quan an ninh mạng quốc gia, tức chính những người có nhiệm vụ cảnh báo công chúng. Việc đăng nhập bằng DigiD trên các dịch vụ khác vẫn chạy, nhưng bản thân trang của nó thì không. Hai trang công nghệ nổi tiếng của nước này là Tweakers và Security.NL cũng ngừng hoạt động.

Làn sóng lan xa hơn một quốc gia:

• Theo Reuters, nhiều website chính phủ ở châu Âu và nơi khác ngừng hoạt động hôm thứ Tư, trong đó có các cơ quan ở Phần Lan tự gỡ trang để phòng ngừa.
• Các cơ quan an ninh mạng ở châu Âu, Úc, Nhật Bản và Anh yêu cầu người dùng PHP cập nhật ngay, hoặc tắt trang cho tới khi cập nhật được.
• CERT-EU khuyên tương tự: vá ngay khi có bản sửa, và nếu chưa vá được thì cân nhắc ngắt các ứng dụng hướng ra Internet khỏi mạng công cộng.

Ở Đức, Đại học Freiburg tắt các website trung tâm lúc 10:39 sáng, kèm mạng nội bộ, nền tảng học tập ILIAS và webmail sinh viên, đồng thời yêu cầu các khoa tự tắt hệ thống PHP của mình.

PHP nằm ở đâu mà một lỗi kéo sập được cả mạng Internet?

Để hiểu vì sao chính phủ thà "tắt đèn", bạn cần biết PHP đứng ở đâu. Nó là phần back end (phía máy chủ) của phần lớn website. Theo W3Techs, PHP chiếm 69,3% số trang web mà họ xác định được ngôn ngữ phía máy chủ. Riêng WordPress, nền tảng chạy gần 40% tổng số website, cũng được viết bằng PHP.

Danh sách phần mềm chạy trên PHP còn dài:

Điều đáng sợ là không ứng dụng nào trong số đó chứa lỗi. Lỗi nằm ở tầng PHP bên dưới. Giống như một toà nhà xây chuẩn từng viên gạch nhưng phần móng có vết nứt: kiến trúc sư phía trên làm tốt đến đâu thì toà nhà vẫn chịu chung rủi ro. Bạn có thể viết website hoàn hảo mà vẫn bị phơi ra.

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

Bản vá xử lý hai vấn đề riêng biệt. Cả hai đều xoay quanh cách PHP quản lý bộ nhớ.

CVE-2026-109618: bẫy "hết bộ nhớ"

Khi một request dùng quá nhiều bộ nhớ, PHP sẽ "nhảy thoát" khỏi việc đang làm để đóng request đó cho gọn. Vấn đề là đôi khi vùng nhớ của request đã truy cập được trước khi nó được thiết lập xong. Nếu việc cấp phát thất bại đúng thời điểm đó, PHP không tính đến cú thoát sớm này. Bước dọn dẹp sau đó làm việc trên dữ liệu chưa từng hợp lệ, và một request được chế tác cẩn thận có thể biến sự lộn xộn ấy thành việc chạy mã của kẻ tấn công trên máy chủ.

Phần nguy hiểm là ép PHP hết bộ nhớ lại dễ đến bất ngờ. PHP đọc phần thân của form upload (kiểu multipart/form-data, thứ trình duyệt gửi đi khi bạn đính kèm file) trước cả khi code ứng dụng của bạn chạy. Kẻ tấn công tận dụng hai kẽ hở:

• Request không khai báo độ dài hợp lệ có thể lách qua giới hạn post_max_size vốn dùng để chặn upload quá lớn.
• Các trường file rỗng không bị tính vào giới hạn max_file_uploads, nhưng PHP vẫn dựng đầy đủ bản ghi nội bộ cho từng trường.

Gộp đủ nhiều thứ như vậy, bộ nhớ cạn theo lệnh, và cạn đúng ở chỗ lỗi thứ nhất đang nằm chờ.

CVE-2026-109619: dùng lại vùng nhớ đã trả

Mỗi worker (tiến trình xử lý) của PHP giữ một ít trạng thái trong bộ nhớ giữa các request, như dữ liệu lỗi và session. Lẽ ra PHP phải xoá sạch trạng thái đó trước khi trả vùng nhớ. Nhưng một lỗi nghiêm trọng, kể cả lỗi do chính chiêu "hết bộ nhớ" ở trên gây ra, có thể khiến bước dọn dẹp bị bỏ qua. PHP giải phóng vùng nhớ trong khi worker vẫn còn trỏ vào đó, và request kế tiếp đọc phải một con trỏ tới vùng nhớ không còn thuộc về nó.

Đây là lỗi Use-After-Free (dùng sau khi giải phóng). Hãy tưởng tượng bạn trả phòng khách sạn nhưng vẫn giữ thẻ từ, và khách tiếp theo nhận phòng mà không ai đổi khoá. Với cách sắp xếp bộ nhớ phù hợp, lỗi này cũng dẫn tới việc chạy mã với quyền của chính máy chủ web.

Điểm yếu đã tồn tại hơn 20 năm

Lỗ hổng này không mới:

• Năm 2004: nhà nghiên cứu Stefan Esser tìm ra lỗi từ xa đầu tiên trong cách PHP xử lý giới hạn bộ nhớ.
• Năm 2020: một báo cáo lỗi chỉ ra đúng hành vi hết bộ nhớ quanh việc upload file.
• Năm 2024: đợt kiểm định bảo mật của OSTIF và Quarkslab phát hiện một vấn đề bộ nhớ liên quan, nhưng khi đó chưa chứng minh được là khai thác được.

Hai lỗi vừa vá chính là lúc điểm yếu kéo dài ấy cuối cùng trở thành một cuộc tấn công chạy được.

9.2 điểm có đáng lo bằng 10 điểm không?

PHP chấm cả hai lỗi 9.2/10, mức nghiêm trọng nhưng không tuyệt đối. Con số này phản ánh việc tấn công không đơn giản: cần độ phức tạp cao và đúng điều kiện. Một số bản tin sớm từng nói tới 10.0, nhưng điểm chính thức là 9.2.

Dù vậy, bản chất vẫn là kẻ tấn công không cần đăng nhập, ngồi ở đâu đó trên Internet, và kết thúc bằng việc chạy mã trên máy chủ của bạn. Khi mã khai thác mẫu (proof-of-concept) đã công khai, khoảng cách giữa 9.2 và 10 gần như không còn ý nghĩa.

Với người quản trị máy chủ, chi tiết đáng chú ý nhất là cách PHP được chạy:

Phiên bản PHP nào mới an toàn?

Bản sửa nằm ở lõi PHP. Đội phát triển gỡ bỏ bước "nhảy thoát khi thiếu bộ nhớ" đầy rủi ro ở gốc lỗi thứ nhất, và buộc worker dọn sạch trạng thái còn sót để đóng lỗi thứ hai. Các phiên bản đã vá:

Mọi bản thấp hơn đều có lỗ hổng. Vấn đề lớn nằm ở các nhánh cũ:

• PHP 8.1 trở xuống không còn được dự án PHP hỗ trợ. Một đợt quét ngày 20/10 tìm thấy khoảng 884.000 máy chủ hướng ra Internet vẫn chạy 8.1 hoặc cũ hơn.
• Đội PHP có đưa ra bản backport tối giản cho 7.4, 8.0 và 8.1, nhưng chỉ dành cho người tự biên dịch PHP từ mã nguồn. Cũ hơn nữa thì không có gì.
• Tại Ấn Độ, một đợt quét đếm được 19.847 máy chủ chạy phiên bản không còn nhận bản vá bảo mật.
• PHP 8.2, nhánh cũ nhất còn được hỗ trợ, sẽ hết vòng đời vào 31/12/2026. Nếu đang dùng 8.2, bạn nên vá ngay và lên kế hoạch chuyển lên bản mới.

Về quy mô, mỗi công cụ quét cho một con số khác nhau nhưng cùng một hướng: VirusTotal nhận diện khoảng 5,1 triệu địa chỉ hướng ra Internet chạy PHP, còn Palo Alto đánh dấu hơn 22,6 triệu bản cài đặt có khả năng bị ảnh hưởng. Theo các quan chức an ninh mạng, một máy chủ bị chiếm có thể bị đánh cắp dữ liệu, phá hỏng cơ chế đăng nhập và bị gỡ nội dung.

Vì sao cập nhật WordPress không cứu được bạn?

Đây là chỗ nhiều người bị hụt hẫng. Nếu bạn chạy WordPress, việc cập nhật WordPress hay các plugin không hề đóng lỗ hổng này, vì bản sửa nằm ở PHP, thứ chạy trên máy chủ bên dưới chúng. Điều tương tự đúng với mọi ứng dụng PHP khác. Thứ duy nhất quyết định là phiên bản PHP mà máy chủ của bạn đang chạy, và nhà cung cấp hosting đã cập nhật nó hay chưa.

Giống như bạn sơn lại cửa và thay tay nắm thật đẹp, nhưng ổ khoá bị lỗi nằm trong khung cửa thuộc về chủ nhà. Muốn thay ổ khoá, bạn phải gọi chủ nhà.

Kiểm tra máy chủ của bạn trong một phút như thế nào?

Nếu tự quản lý máy chủ, bạn có thể hỏi thẳng PHP phiên bản của nó:

php -v

Cẩn thận một điểm: lệnh này cho biết phiên bản PHP dòng lệnh, không phải lúc nào cũng trùng với phiên bản website đang dùng. Hãy kiểm tra thứ mà chính trang web báo về, ví dụ:

php-fpm8.3 -v

hoặc dùng một trang phpinfo. Nếu kết quả thấp hơn 8.2.35, 8.3.36, 8.4.27 hay 8.5.12, máy chủ đang bị phơi ra và cần vá.

Số phiên bản có thể đánh lừa bạn

Các bản phân phối Linux thường vá bằng cách backport (đưa bản sửa vào gói cũ), nên gói đã vá vẫn có thể hiện số phiên bản thấp hơn. Cách chắc chắn hơn là đọc changelog của gói:

# Debian / Ubuntu
apt changelog php8.3-cli

# Red Hat và các bản tương tự
rpm -q --changelog php

Nếu thấy một trong hai mã CVE-2026-109618 hoặc CVE-2026-109619 trong đó, bản sửa đã có. Nếu không thấy, gói chưa được cập nhật, bất kể số phiên bản nói gì.

Danh sách việc cần làm:

• [ ]Xác định phiên bản PHP mà website thực sự chạy (không chỉ php -v)
• [ ]Cập nhật lên bản vá tương ứng hoặc kiểm tra changelog nếu dùng gói của bản phân phối
• [ ]Khởi động lại PHP-FPM hoặc Apache sau khi cập nhật, vì các worker đang chạy vẫn giữ code cũ cho tới khi restart
• [ ]Nếu đang ở PHP 8.1 trở xuống, lên kế hoạch nâng cấp ngay
• [ ]Nếu dùng hosting chia sẻ, liên hệ nhà cung cấp

Đã có ai bị tấn công thật chưa?

Hiện chưa rõ kẻ tấn công đã dùng lỗi này trên các trang thật hay chưa. Cloudflare và một số công ty hosting ghi nhận các nỗ lực tấn công vào sáng thứ Tư. Nhưng tính đến 21/10:

• Cơ quan an ninh mạng Hà Lan cho biết chưa thấy lạm dụng thực tế.
• Cả hai lỗi chưa xuất hiện trong danh sách lỗ hổng đã bị khai thác của chính phủ Mỹ.
• Unit 42 cho biết họ mới thấy mã khai thác mẫu, chưa thấy vụ xâm nhập thực tế nào.

Bản vá đã ra từ chiều 21/10, nhưng nhiều trang từng tắt vẫn chưa hoạt động lại tới tối. Mã khai thác mẫu giờ đã công khai, và sau một vụ rò rỉ như thế này, các đợt quét hàng loạt thường bắt đầu chỉ trong vài giờ.

Nếu bạn sở hữu bất cứ thứ gì chạy PHP, dù là blog, cửa hàng, diễn đàn hay trang công ty, điều quan trọng lúc này là máy chủ đã được vá trước khi có ai đó tìm tới hay chưa.

Tóm tắt nhanh

• PHP2Shell là tên gọi của hai lỗ hổng PHP (CVE-2026-109618 và CVE-2026-109619), cho phép chạy mã từ xa không cần đăng nhập, điểm 9.2/10.
• Chi tiết bị rò rỉ trước khi có bản vá, khiến nhiều website chính phủ ở Hà Lan, Phần Lan, Đức và nơi khác tự tắt để phòng ngừa.
• Phiên bản an toàn: 8.5.12, 8.4.27, 8.3.36, 8.2.35 trở lên. PHP 8.1 trở xuống không còn được hỗ trợ.
• Cập nhật WordPress hay plugin không sửa được lỗi; phải cập nhật PHP trên máy chủ và khởi động lại PHP-FPM hoặc Apache.
• Cả mod_php lẫn PHP-FPM đều cần vá; mẹo chỉnh cấu hình không thay được bản vá.

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

Website của tôi dùng WordPress bản mới nhất, vậy có an toàn không?

Chưa chắc. Lỗi nằm ở PHP trên máy chủ, không nằm trong WordPress hay plugin. Bạn cần kiểm tra phiên bản PHP mà hosting đang chạy, hoặc hỏi nhà cung cấp đã áp dụng bản vá ngày 21/10 chưa.

php -v báo phiên bản cũ, nghĩa là tôi chắc chắn bị lỗi?

Không hẳn. Lệnh này cho biết PHP dòng lệnh, có thể khác với PHP mà website dùng. Ngoài ra các bản phân phối Linux thường backport bản vá vào gói mang số phiên bản cũ. Hãy kiểm tra changelog của gói (apt changelog hoặc rpm -q --changelog) xem có mã CVE-2026-109618 hay CVE-2026-109619 không.

Dùng PHP-FPM thay cho mod_php có tránh được lỗi không?

Không. Lỗi thứ nhất chưa có bản khai thác hoàn chỉnh trên FPM, nhưng lỗi thứ hai đã chạy được mã trên cả mod_php lẫn FPM. Cả hai cấu hình đều phải vá.

Tôi đang chạy PHP 8.1 hoặc cũ hơn thì phải làm sao?

Nhánh này không còn nhận bản vá chính thức. Đội PHP chỉ phát hành bản backport tối giản cho 7.4, 8.0 và 8.1 dành cho người tự biên dịch từ mã nguồn. Cách bền vững là nâng cấp lên nhánh còn được hỗ trợ, và lưu ý PHP 8.2 cũng hết vòng đời vào 31/12/2026.