PHP2Shell bị nhắm khai thác trước bản vá: cập nhật PHP thôi chưa đủ

Mốc phát hiện sớm quan trọng vì nó thay đổi phạm vi điều tra, nhưng không phải bằng chứng rằng mọi máy chủ bị nhắm tới đều đã mất quyền kiểm soát. MadPot là mạng honeypot, tức các hệ thống bẫy được dùng để quan sát hoạt động tấn công. Amazon Threat Intelligence ghi nhận yêu cầu khai thác từ một địa chỉ IP thuộc mạng dịch vụ ẩn danh thương mại ngày 17/10; cách đối tượng có được thông tin trước công bố vẫn chưa rõ.

Đến ngày 21/10, dữ liệu Amazon tiếp tục ghi nhận các mã chứng minh khả năng khai thác từ khoảng 02:00 UTC và những nỗ lực nhắm vào MadPot trong khoảng 02:00–08:00 UTC, trước thời điểm công bố 14:00 UTC. Tuy vậy, báo cáo lưu ý việc phân tích còn tiếp diễn và chưa rõ các nỗ lực trước công bố có thành công trên hệ thống thực tế hay không. Sau khi bản vá xuất hiện, Amazon ghi nhận thêm mã khai thác được sử dụng nhanh chóng chống lại các cảm biến.

Vì thế, cách phản ứng hợp lý là mở rộng cửa sổ kiểm tra về ít nhất ngày 17/10, chứ không kết luận sẵn rằng website đã bị chiếm. Cũng không nên chờ có bằng chứng xâm nhập mới vá: khả năng thực thi mã từ xa của lỗi đã được chứng minh trong quá trình nghiên cứu, dù kết quả của từng cuộc tấn công quan sát được vẫn cần xác minh riêng.

Rủi ro đáng ngại nhất là một số đường tấn công có thể xảy ra trước khi ứng dụng kịp chạy cơ chế bảo vệ của nó. Cảnh báo PHP.net xếp Apache dùng mod_php vào nhóm nguy cơ cao nhất, với khai thác đã được chứng minh từ yêu cầu không cần xác thực trước khi bất kỳ mã ứng dụng nào chạy. PHP-FPM, php-cgi, FrankenPHP và LiteSpeed cũng nằm trong phạm vi các triển khai phục vụ yêu cầu web cần cập nhật.

Với CVE-2026-109618, việc chạm giới hạn bộ nhớ ở thời điểm không phù hợp có thể ngắt quá trình khởi tạo dữ liệu nội bộ của yêu cầu. Đến lúc dọn dẹp, PHP có thể coi phần dữ liệu chưa hoàn chỉnh ấy là hợp lệ, dẫn tới hỏng bộ nhớ. Điều này khác lỗi thiếu RAM thông thường: hậu quả tiềm tàng không dừng ở việc một yêu cầu bị hủy.

CVE-2026-109619 liên quan đến trạng thái nội bộ còn sót lại sau khi vùng nhớ phục vụ yêu cầu đã được giải phóng. Một yêu cầu tiếp theo do cùng worker xử lý có thể sử dụng trạng thái cũ trước khi nó được khởi tạo lại. Worker ở đây là tiến trình xử lý yêu cầu; việc tái sử dụng tiến trình giúp phục vụ website, nhưng cũng khiến dữ liệu lỗi từ yêu cầu trước có thể ảnh hưởng yêu cầu sau.

Đối với website WordPress, chỉ cập nhật plugin hoặc mã website không thay thế được vá PHP, vì lỗi nằm ở tầng thực thi bên dưới ứng dụng. Tương tự, chuyển từ mod_php sang PHP-FPM không phải lời xác nhận an toàn: The PHP Foundation cũng xác nhận khả năng thực thi mã từ xa qua các đường mã ứng dụng trên PHP-FPM.

Khó khăn của vụ này nằm ở việc sửa một cơ chế được rất nhiều yêu cầu chạm tới mà vẫn giữ ứng dụng và phần mở rộng hoạt động bình thường. Những dấu hiệu đầu tiên của vấn đề hết bộ nhớ được phát hiện từ đợt kiểm toán năm 2024. Khi đó đã có giả thuyết khai thác, nhưng chưa tìm được đường tấn công cụ thể; không nên diễn giải thành việc đội phát triển đã biết đầy đủ một cách chiếm máy chủ suốt thời gian ấy.

Các hướng sửa khi đó có những đánh đổi khác nhau: phá tương thích ngược, tạo nguy cơ từ chối dịch vụ mới hoặc buộc nhiều phần mở rộng bên thứ ba cùng thay đổi. Cơ chế ra quyết định dựa trên đồng thuận và số người am hiểu sâu bộ máy PHP quá ít khiến công việc nhiều lần đình trệ. The PHP Foundation thừa nhận đây là thất bại về tổ chức và nguồn lực, đồng thời đang thay đổi quy trình để có thể quyết định theo đa số.

Báo cáo thực thi mã từ xa của Calif ngày 11/8/2026, cùng các phát hiện độc lập và đường tấn công bổ sung sau đó, làm rõ mức độ nghiêm trọng. Từ mốc này, sửa lỗi trở thành ưu tiên cao nhất của đội bảo mật do Foundation tài trợ. Bài học không phải là giữ tương thích bằng mọi giá, mà là cần cơ chế chốt phương án khi mọi lựa chọn đều có chi phí. Một lỗi đã bị nhận diện nhưng không ai có thể quyết định cách sửa vẫn là rủi ro đang tồn tại.

Lịch công bố phối hợp chỉ hữu ích khi các bên còn giữ được khoảng thời gian chuẩn bị bản cập nhật. Theo lịch do The PHP Foundation công bố, ngày phát hành ban đầu là 22/10/2026; sau khi hai mã CVE xuất hiện trên mạng ngày 20/10, đội phát triển chuyển lên ngày 21/10. Điểm CVSS 10,0 lan truyền ban đầu là sai, còn mức chính thức là 9,2.

Ở đợt rò rỉ mã CVE ban đầu, chưa có chi tiết kỹ thuật bị lộ. Sau đó, một video chứng minh khai thác bị công bố nhầm, rồi bản dựng chứa bản sửa lỗi xuất hiện trước giờ công bố phối hợp. Cần tách chuỗi sự kiện này khỏi nỗ lực ngày 17/10: hiện không có đủ bằng chứng để nói đối tượng tấn công sớm đã lấy thông tin từ những vụ lộ diễn ra sau đó.

Việc có bản vá cũng tạo thêm vật liệu để phân tích lỗi. Khoảng trì hoãn mà quản trị viên trông chờ giữa công bố và mã khai thác có thể rất ngắn; với máy chủ tiếp xúc Internet, đợi đợt bảo trì tuần sau là một lựa chọn rủi ro. Tuy nhiên, chưa có căn cứ để khẳng định AI đã được dùng trong chính nỗ lực tấn công sớm này.

Ưu tiên đầu tiên là xác nhận môi trường thực sự phục vụ website đã được vá. PHP.net liệt kê bốn phiên bản sửa lỗi: 8.5.12, 8.4.27, 8.3.36 và 8.2.35. Với gói Linux hoặc dịch vụ hỗ trợ dài hạn, cần kiểm tra thông báo của nhà cung cấp vì bản sửa có thể được đưa ngược vào gói cũ mà không mang nguyên số phiên bản upstream.

Nếu thuê hosting, chủ website nên yêu cầu đơn vị vận hành xác nhận gói PHP đã có bản sửa cho cả hai mã CVE, thay vì chỉ hỏi đã cập nhật WordPress hay chưa. Nếu tự quản trị VPS, cần kiểm tra đúng môi trường web và các worker đang phục vụ yêu cầu, không chỉ một bản PHP khác có sẵn trên máy. Cập nhật tầng ứng dụng vẫn cần thiết, nhưng đó là công việc riêng.

Trong lúc chưa thể nâng cấp, PHP.net nêu biện pháp tắt session.upload_progress.enabled và khởi động lại mọi worker để chặn các đường session đã xác nhận. Thiết lập phải có hiệu lực trước khi phân tích yêu cầu, chẳng hạn trong php.ini hoặc cấu hình pool/server; đặt bằng ini_set() trong ứng dụng là quá muộn. Giới hạn kích thước POST và kiểm soát yêu cầu tải tệp ở tầng máy chủ hoặc proxy cũng chỉ giảm bề mặt tấn công, không khắc phục đầy đủ hai lỗi.

Không nên sao chép một thay đổi cấu hình rồi coi đó là bản vá. Chẳng hạn, bỏ giới hạn bộ nhớ PHP có thể loại một đường kích hoạt hết bộ nhớ có thể kiểm soát, nhưng lỗi cấp phát ở tầng dưới vẫn có thể đi vào nhánh dễ tổn thương; vận hành còn phải tính đến giới hạn tài nguyên để tránh mất dịch vụ. Nếu chưa hiểu ảnh hưởng tới ứng dụng, cần để nhà cung cấp hosting hoặc người quản trị triển khai biện pháp tạm thời phù hợp.

Song song với vá, hãy rà lại yêu cầu POST có chuỗi PHP_SESSION_UPLOAD_PROGRESS, tiến trình thực thi bất thường và tệp bị sửa ngoài dự kiến. Những dấu hiệu này cần điều tra trong ngữ cảnh, không tự động đồng nghĩa có xâm nhập. PHP 8.1 trở xuống đã hết hỗ trợ từ dự án; các bản backport nguồn tối thiểu cho 7.4, 8.0 và 8.1 trong đợt khẩn cấp cũng không có nghĩa những nhánh này được hỗ trợ trở lại.

Một xác nhận hoàn tất có ích phải trả lời được hai câu riêng biệt: máy chủ đã chạy bản sửa lỗi chưa, và có dấu vết bị can thiệp trước khi vá hay không. Nâng cấp đóng lỗ hổng, nhưng không tự chứng minh hệ thống chưa từng bị xâm nhập.

Nguồn tham khảo: PHP.net; The PHP Foundation; Amazon Threat Intelligence; The Verge.