Ngày 21 tháng 10 năm 2026, dự án PHP công bố hai khuyến cáo bảo mật nghiêm trọng mà cộng đồng đã gọi chung là ‘PHP2Shell’. Đến cuối ngày 22 tháng 10, cả ba máy chủ web trong hệ thống được quản lý đã đánh giá của ViWeb, cùng mọi nhánh PHP runtime cài đặt trên đó, đều đã được vá và xác minh. Các công việc tiếp theo, bao gồm quét mã độc trên diện rộng hơn, vẫn đang chạy trong ngày 23 tháng 10. Dưới đây là những gì chúng tôi đã hoàn thành, những gì chúng tôi không khẳng định, và những câu hỏi bạn nên đặt ra cho bất kỳ nhà cung cấp nào đang lưu trữ website PHP cho bạn.
Điều gì đã được công bố
Thông báo ngày 21 tháng 10 của PHP (php.net) đề cập đến CVE-2026-109618, lỗi hỏng bộ nhớ trong điều kiện hết bộ nhớ (GHSA-w8hw-w9fx-j79w), và CVE-2026-109619, lỗi trạng thái toàn cục cũ (stale global state) và use-after-free (GHSA-6wmf-4rv5-p3rp). Cả hai được xếp mức nghiêm trọng vì, trong các cấu hình bị ảnh hưởng, chúng có thể cho phép thực thi mã mà không cần xác thực. Không phải website nào cũng có thể bị khai thác trong mọi cấu hình, nhưng hướng dẫn của PHP là cập nhật ngay. Tường lửa, plugin và các biện pháp giảm nhẹ tạm thời không thể thay thế hoàn toàn. Các bản phát hành đã sửa lỗi là 8.2.35, 8.3.36, 8.4.27 và 8.5.12. Các nhánh cũ hơn đã hết vòng đời hỗ trợ. Với các nhánh cũ trong hệ thống của mình, ViWeb đã xác minh backport qua changelog nêu rõ cả hai bản sửa; chuỗi phiên bản gốc không thay đổi chưa phải bằng chứng đầy đủ.
Cảnh báo ngày 21 tháng 10, cập nhật ngày 22 tháng 10, của Cơ quan An ninh mạng Singapore ghi nhận các nỗ lực khai thác trong thực tế (CSA AL-2026-151). Chúng tôi không có bằng chứng nào cho thấy khách hàng của ViWeb bị khai thác qua các CVE này, và chúng tôi không quy kết bất kỳ sự cố nào trước đó cho chúng. Cảnh báo này chỉ đơn giản xác nhận rằng bản vá này không thể chờ đến đợt bảo trì theo lịch.
Vì sao chủ doanh nghiệp cần quan tâm
Một website WordPress hoặc PHP được quản lý chạy trên một runtime mà chủ sở hữu không bao giờ nhìn thấy. Nếu runtime đó cho phép thực thi mã không cần xác thực, kẻ tấn công không cần mật khẩu, không cần lỗi plugin và không cần email lừa đảo. Cách khắc phục không hào nhoáng: cập nhật runtime ở mọi nơi nó thực sự chạy, rồi chứng minh điều đó.
Những gì chúng tôi đã hoàn thành ngày 22 tháng 10
Kiểm kê trước tiên. Chúng tôi liệt kê các nhánh PHP, bộ extension và runtime được đóng gói riêng của bảng điều khiển trên cả ba máy chủ được quản lý. Một máy chủ có thể chứa nhiều bản cài đặt PHP, và chỉ cập nhật tệp thực thi dòng lệnh sẽ không cho thấy các tiến trình web worker hay bảng điều khiển đã được vá.
Kiểm tra sao lưu trước khi vá. Chúng tôi xác minh chỉ mục các kho lưu trữ sao lưu cục bộ và tính toàn vẹn của payload lồng bên trong, xác nhận phạm vi bao phủ cho toàn bộ tệp website, cấu hình và cơ sở dữ liệu đã cấu hình, đồng thời đối chiếu các manifest sao lưu ngoại vi hàng tuần mới nhất với kích thước đối tượng từ xa và phạm vi tài khoản. Đây là kiểm tra phạm vi bao phủ và tính toàn vẹn, không phải diễn tập khôi phục đầy đủ và cũng không phải tính lại checksum mới cho mọi đối tượng từ xa. Hướng dẫn chiến lược sao lưu của chúng tôi giải thích vì sao sự khác biệt đó quan trọng.
Cập nhật PHP của website từ kho nhà cung cấp đã xác minh. Các nhánh hiện hành nhận bản phát hành bảo mật từ kho nhà cung cấp đã được cấu hình sẵn trên từng máy chủ. Với các nhánh cũ vẫn đang sử dụng, chúng tôi dùng bản dựng của nhà cung cấp có changelog nêu rõ cả hai bản sửa CVE, kiểm tra changelog thay vì tin vào số phiên bản. Các nhánh, extension và cấu hình ứng dụng hiện có được giữ nguyên, nên không website nào phải kiểm thử lại với phiên bản PHP lớn mới giữa lúc khẩn cấp. Tiếp tục dùng nhánh cũ không phải là khuyến nghị lâu dài; các website đó vẫn cần kế hoạch nâng cấp.
Runtime riêng của bảng điều khiển. Bảng điều khiển Hestia của chúng tôi đóng gói PHP riêng, tách biệt với runtime của website, và ngày 22 tháng 10 kho của bảng điều khiển vẫn chỉ cung cấp phiên bản 8.5.9 có lỗ hổng. Thay vì để một tiến trình đã biết có lỗ hổng trên máy chủ kết nối internet, chúng tôi dựng cục bộ một gói PHP 8.5.12 khẩn cấp từ mã nguồn PHP chính thức, đối chiếu với SHA256 đã công bố, với cùng cờ biên dịch, module và tiền tố cài đặt như gói hiện có, bên trong một container build cô lập và giới hạn tài nguyên. Gói này được đánh giá độc lập, và tính tương đồng về cấu hình và module được xác minh trước khi cài đặt. Đây là bản dựng khẩn cấp cục bộ được ghi nhãn rõ ràng, không phải bản phát hành Hestia của nhà cung cấp và không phải bảo đảm về chuỗi cung ứng. Thay thế nó bằng gói nhà cung cấp đã xác minh là hạng mục theo dõi còn mở.
Xác minh, rồi khởi động lại theo giai đoạn. Chúng tôi kiểm tra các tệp thực thi FPM và bảng điều khiển đang chạy, tìm các tiến trình cũ vẫn ánh xạ tới thư viện cũ, xác nhận lại cấu hình và tình trạng dịch vụ, và xác nhận các trang, mã trạng thái và dấu hiệu nội dung như mong đợi. Sau đó, các lần khởi động lại được ủy quyền được thực hiện lần lượt từng máy chủ một. Mỗi máy chủ phải khôi phục và vượt qua bước kiểm tra vận hành trước khi chúng tôi chuyển sang máy tiếp theo. Chúng tôi không khẳng định không có thời gian gián đoạn, và các luồng cần xác thực như thanh toán và biểu mẫu chưa được kiểm thử đầy đủ trong đợt này.
Kiểm tra tại origin và kiểm tra công khai được tách riêng. Một số kiểm tra công khai gặp thử thách của Cloudflare, và việc vượt qua kiểm tra tại origin không bao giờ được tính là bằng chứng trang công khai hiển thị đúng. Ở những origin có hạn chế TLS đã biết, chúng tôi dùng yêu cầu HTTP được ghi nhãn qua kênh SSH tin cậy thay vì bỏ qua xác minh chứng chỉ.
Vẫn đang tiến hành trong ngày 23 tháng 10
Vá lỗi đóng các lỗ hổng đã biết. Nó không chứng minh rằng không có gì xảy ra trước đó. Chúng tôi lưu giữ bằng chứng khôi phục, xem xét riêng các tệp từng bị nghi ngờ trước đây, và đưa vào các đợt quét chỉ báo cáo hàng ngày và hàng tuần trên toàn bộ danh mục website được quản lý. Quét hàng ngày băm mọi tệp và quét mẫu những tệp đã thay đổi. Quét hàng tuần băm lại và quét lại toàn bộ tệp với bộ quy tắc khai thác hẹp hơn theo cấu hình giới hạn tài nguyên, nên không mạnh hơn đợt quét hàng ngày. Các script trên 1 MiB bị giới hạn, và không có phạm vi bao phủ cho cơ sở dữ liệu, tệp nén hay tra cứu uy tín tệp từ dịch vụ bên ngoài. Không có gì bị xóa hay cách ly tự động. Các phát hiện được lưu để xem xét; việc xử lý cần được phê duyệt riêng. Các đợt quét đầy đủ ban đầu trên diện rộng vẫn đang chạy, nên chúng tôi không khẳng định toàn hệ thống đã sạch mã độc.
Điều này không có nghĩa là gì
Nó không bao phủ mọi khách hàng ở mọi nơi, chỉ ba máy chủ được quản lý đã đánh giá tính đến ngày 22 tháng 10. Đây là bằng chứng có ghi ngày, không phải bảo đảm vĩnh viễn. Nó không thay thế việc cập nhật plugin WordPress, tường lửa ứng dụng web, thông tin đăng nhập quản trị mạnh hay vá lỗi ở cấp ứng dụng. Đó là những trách nhiệm riêng biệt, và đó là lý do dịch vụ bảo trì WordPress và giám sát web của chúng tôi vận hành như công việc liên tục chứ không phải làm một lần.
Những câu hỏi nên đặt ra cho nhà cung cấp của bạn
- Máy chủ của tôi chạy những nhánh PHP nào, và tiến trình nào thực sự sử dụng chúng?
- Sao lưu có được xác minh về phạm vi bao phủ và tính toàn vẹn trước khi vá không, và lần kiểm thử khôi phục gần nhất là khi nào?
- Với các nhánh cũ, changelog nào của nhà cung cấp nêu rõ cả hai bản sửa CVE?
- Bảng điều khiển có chạy PHP riêng không, và nó đã được vá chưa?
- Các tiến trình đã vá được xác minh như thế nào, và việc khởi động lại có được thực hiện theo giai đoạn không?
- Sau khi vá có chạy quét gì, và ai xem xét các phát hiện?
Nếu câu trả lời không rõ ràng, hoặc bạn nghi ngờ website đã bị xâm nhập trước khi vá, dịch vụ khôi phục website của chúng tôi có thể đánh giá và giúp bạn lên kế hoạch cho bước tiếp theo.
Câu hỏi thường gặp
Các máy chủ được quản lý của ViWeb đã được vá chống PHP2Shell chưa?
Rồi. Cả ba máy chủ web thuộc phạm vi kiểm tra và mọi nhánh PHP cài đặt trên đó đều đã được vá và xác minh tính đến ngày 22 tháng 10 năm 2026. Đây là bằng chứng có ghi ngày, không phải bảo đảm vĩnh viễn.
Vá lỗi có nghĩa là website của tôi không còn mã độc không?
Không. Vá lỗi đóng các lỗ hổng đã biết. Các đợt quét chỉ báo cáo trên danh mục website được quản lý vẫn đang chạy trong ngày 23 tháng 10, các phát hiện được lưu để xem xét, và việc xử lý cần được phê duyệt riêng.
Phiên bản PHP cũ hơn có mặc nhiên bị lỗ hổng không?
Một phiên bản gốc cũ có thể đã được nhà cung cấp vá bằng backport. ViWeb đã kiểm tra changelog cho cả hai bản sửa; chỉ nhìn phiên bản gốc là chưa đủ. Các nhánh cũ vẫn cần được nâng cấp theo kế hoạch.