Bản vá cho PHP2Shell đã được phát hành, nhưng phần lớn website cần bản vá này chẳng có nút nào để bấm. Các lỗ hổng nằm ngay trong PHP — bộ máy vận hành mọi trang WordPress, Joomla và Drupal — bên dưới CMS, các plugin và màn hình đăng nhập. Cập nhật WordPress không giải quyết được vấn đề. Bản PHP đã vá phải được cung cấp bởi đơn vị vận hành máy chủ: công ty hosting, gói phần mềm của bản phân phối Linux hoặc ảnh container. Chừng nào việc đó chưa xảy ra, website vẫn phải chờ, bất kể chủ sở hữu làm gì.

Đây là phần câu chuyện bị những tiêu đề kiểu “vá ngay” bỏ qua. Nhóm PHP đã hoàn thành nhiệm vụ. Đưa thành quả của họ lên một máy chủ cụ thể phụ thuộc vào cả một chuỗi cung ứng, với tốc độ chỉ bằng mắt xích chậm nhất; ngày đầu tiên đã cho thấy khoảng cách giữa các mắt xích lớn đến mức nào. Chủ website không biết PHP của mình đến từ đâu thì cũng không thể xác định họ vẫn còn đối mặt với rủi ro ra sao.

Vì sao cập nhật WordPress không khắc phục được lỗi

Vì lỗi nằm trong trình thông dịch, thông báo bảo mật của PHP áp dụng cho mọi hệ thống cài đặt có xử lý yêu cầu web, từ PHP-FPM và mod_php của Apache đến php-cgi, FrankenPHP và LiteSpeed. The Hacker News lưu ý rằng ngay cả một trang “Hello World” đơn giản chạy trên phiên bản dễ bị tấn công cũng có thể trở thành mục tiêu. Trường hợp nghiêm trọng nhất là mod_php: chỉ một yêu cầu từ người không có tài khoản cũng có thể kích hoạt cuộc tấn công trước khi bất kỳ đoạn mã ứng dụng nào chạy, nghĩa là plugin bảo mật hay màn hình đăng nhập đều không thể phát hiện.

Wordfence, nhà cung cấp dịch vụ bảo mật WordPress, cho biết với các chủ website — theo thông tin The Verge đưa tin — rằng bản sửa lỗi không thể được cài qua cập nhật tự động, và họ cần tìm hiểu ai chịu trách nhiệm về PHP trên máy chủ của mình. Laravel Forge cũng gửi thông tin tương tự cho khách hàng về các máy chủ của dịch vụ: những bản cập nhật bảo mật tự động của họ không vá PHP, còn tính năng nâng cấp tự động không giám sát của Ubuntu chỉ tải bản cập nhật từ kho phần mềm của Ubuntu, chứ không lấy từ các gói bên thứ ba mà Forge cài PHP từ đó.

Các nguồn cung cấp gói phần mềm này không cập nhật đồng loạt. Trong ngày phát hành, dịch vụ quản lý website mySites.guru cho biết EasyApache 4 của cPanel đã có các bản dựng được vá chỉ vài phút sau khi thông báo được đưa ra, trong khi PPA của Ondřej Surý — nguồn gói Ubuntu mà Laravel Forge dựa vào — và kho phần mềm của Remi vẫn chưa có bản nào. InMotion Hosting cho biết các máy chủ hosting dùng chung và WordPress của họ đang chờ bản dựng từ CloudLinux. Trong số các website đang hoạt động mà mySites.guru theo dõi, chỉ 0,08% báo cáo đã dùng phiên bản PHP được vá vào lúc 13:52 UTC.

Số phiên bản có thể khiến bạn hiểu nhầm

Việc kiểm tra không đơn giản chỉ là nhìn vào một con số. Ubuntu, Debian và Red Hat đưa các bản sửa bảo mật ngược về phiên bản cũ mà không đổi số phiên bản gốc, vì vậy một máy chủ Ubuntu 24.04 đã được vá vẫn báo gói 8.3.6. The Hacker News, dẫn thông tin từ Debian, khuyên nên tìm CVE trong nhật ký thay đổi của gói phần mềm thay vì tin vào chuỗi phiên bản. mySites.guru nêu thêm một điểm dễ gây nhầm lẫn: tệp nhị phân PHP trả kết quả khi chạy php -v trên dòng lệnh thường không phải phiên bản đang phục vụ các trang web, vì vậy hãy kiểm tra phiên bản mà chính website báo cáo.

Sau đó, bản vá còn phải được nạp vào hệ thống. Thông báo của PHP và Forge đều nhấn mạnh cần khởi động lại Apache, PHP-FPM và mọi tiến trình chạy liên tục. Các worker xử lý hàng đợi và những tiến trình nền tương tự vẫn tiếp tục chạy trình thông dịch cũ cho đến khi được khởi động lại, dù các tệp đã vá nằm sẵn trên ổ đĩa.

Những ai không nhận được bản sửa lỗi chính thức

Các bản phát hành đã sửa lỗi gồm PHP 8.5.12, 8.4.27, 8.3.36 và 8.2.35, khắc phục CVE-2026-109618 và CVE-2026-109619, cả hai đều được chấm 9,2 theo CVSS v4.0. Với PHP 8.1 trở về trước, dự án PHP không cung cấp gì ngoài các bản vá ngược tối thiểu cho mã nguồn của phiên bản 7.4, 8.0 và 8.1, dành cho những người tự biên dịch PHP. Một số nhà cung cấp tự lấp khoảng trống này: InMotion cho biết cPanel đã đưa các bản vá ngược vào những gói từ 7.4 đến 8.1, còn CloudLinux đang vá mọi phiên bản họ phân phối; trong khi đó, CentOS 7 hoàn toàn không có bản sửa lỗi.

Nhóm phiên bản cũ này không hề nhỏ. Một ngày trước khi bản vá được phát hành, 22,7% website Joomla và WordPress đang hoạt động mà mySites.guru theo dõi vẫn chạy PHP 8.1 trở về trước, còn 16,6% vẫn dùng PHP 7 hoặc phiên bản cũ hơn. Công ty cho rằng một phần nguyên nhân đến từ chính WordPress: nền tảng này khuyến nghị PHP 8.3 nhưng vẫn liệt kê phiên bản 7.4 đã ngừng hỗ trợ từ lâu là tương thích. PHP 8.2 đã nhận được bản vá này, nhưng thời hạn hỗ trợ bảo mật của phiên bản sẽ kết thúc vào ngày 31 tháng 12 năm 2026.

Thiết lập tạm thời có thể chặn được những gì

Biện pháp khắc phục tạm thời lan truyền trước khi bản vá được phát hành — đặt session.upload_progress.enabled=0 — là có tác dụng nhưng chỉ giải quyết được một phần. PHP cho biết thiết lập này chặn các đường khai thác qua session đã được xác nhận đối với CVE-2026-109619, chứ không ngăn được những biến thể khác; đồng thời, phải đặt cấu hình trong php.ini hoặc cấu hình máy chủ hay pool, rồi khởi động lại mọi worker. Trên PHP 8.5, thiết lập fatal_error_backtraces=0 sẽ đóng thêm một đường khai thác đã được xác nhận. Cả hai đều không xử lý CVE-2026-109618; với lỗi này, PHP đề xuất dùng memory_limit=-1 — cấu hình không thể bị ghi đè — đặt post_max_size ở mức thấp, đồng thời giới hạn kích thước yêu cầu tại máy chủ web hoặc proxy. Theo chính cách diễn đạt của PHP, hiện không có biện pháp giảm thiểu nào hoàn chỉnh. InMotion lưu ý rằng WordPress, Joomla, Drupal, Magento và PrestaShop không sử dụng tính năng theo dõi tiến trình tải lên, nên tắt tính năng này không làm ảnh hưởng đến chúng.

Cloudflare đã bật các quy tắc tường lửa cho tất cả các gói dịch vụ; giám đốc công nghệ Dane Knecht gọi đây là biện pháp tình thế. Như mySites.guru chỉ ra, các quy tắc này chỉ có ích nếu máy chủ phía sau từ chối lưu lượng truy cập đi vòng qua Cloudflare và kết nối thẳng đến địa chỉ IP của máy chủ.

Các cuộc tấn công cho đến nay

watchTowr cho biết các honeypot của họ đã ghi nhận nỗ lực khai thác cả hai lỗ hổng trong ngày phát hành, còn Cloudflare phát hiện kẻ tấn công thay đổi payload để vượt qua các quy tắc của họ. Chưa có nguồn tin nào xác nhận một máy chủ cụ thể đã bị xâm nhập thành công. Một số đơn vị chọn cách không mạo hiểm: The Hacker News đưa tin BambooHR đã tạm ngừng dịch vụ, còn một số dịch vụ công của Hà Lan, trong đó có DigiD, cũng ngừng hoạt động để đề phòng. CERT của EU và Trung tâm An ninh mạng Quốc gia Anh khuyến cáo các tổ chức chưa thể vá lỗi hãy cô lập những ứng dụng bị phơi nhiễm hoặc đưa chúng ngoại tuyến.

Các lỗ hổng được phát hiện bởi Wiz Research, Calif và nhóm Codex Security của OpenAI. Theo PHP Foundation, dấu hiệu của lỗi bộ nhớ đã xuất hiện trong một cuộc kiểm toán năm 2024, nhưng việc sửa lỗi bị đình trệ suốt nhiều tháng — sự chậm trễ mà tổ chức gọi là “một thất bại mang tính cấu trúc”. Các nhà nghiên cứu cho biết những mô hình AI đã giúp biến các lỗi tồn tại suốt một thập kỷ thành những mã khai thác hoạt động được chỉ trong khoảng một tuần.

PHP phải trải qua một cuộc kiểm toán, nhiều tháng bế tắc và cả một vụ rò rỉ mới phát hành được bản vá này. Với một website dùng hosting chia sẻ, bước cuối cùng là gửi yêu cầu hỗ trợ.

Thẻ: Cloudflare, lỗ hổng bảo mật, PHP, PHP2Shell, WordPress