Sự cố eMudhra và PHP2Shell: cập nhật WordPress thôi chưa đủ

Hai cảnh báo bảo mật đang đặt quản trị viên website trước những công việc khác nhau: eMudhra liên quan đến việc ứng dụng tin chứng chỉ nào, còn PHP2Shell liên quan đến phần mềm chạy mã trên máy chủ. Với website dùng WordPress tại Việt Nam, chỉ thấy trang vẫn vào được bằng Chrome hoặc bảng điều khiển báo WordPress đã cập nhật là chưa đủ để kết luận hệ thống đã an toàn.

Trình duyệt đã chặn chứng chỉ xấu, ứng dụng khác chưa chắc đã được bảo vệ

Điểm nguy hiểm của sự cố eMudhra nằm ở khả năng giả danh máy chủ bằng chứng chỉ có vẻ hợp lệ. Google xác nhận khóa riêng tư của tám CA trung gian được tạo với độ ngẫu nhiên không đủ, khiến kẻ tấn công có thể giả mạo chứng chỉ HTTPS trước những phần mềm vẫn còn tin các CA đó.

CA trung gian có quyền ký chứng chỉ trong một chuỗi tin cậy. Khi khóa ký có thể bị tìm ra dễ dàng, lớp xác thực mất chỗ dựa: phần mềm có nguy cơ chấp nhận một máy chủ giả là nơi mình định kết nối. Đây không phải bằng chứng thuật toán mã hóa TLS đã bị phá, cũng không đồng nghĩa toàn bộ dữ liệu HTTPS trên Internet có thể bị giải mã.

Google cho biết Chrome Root Program nhận báo cáo ngày 17/10/2026 và triển khai CRLSet chặn mã băm khóa công khai SPKI của các CA bị ảnh hưởng. Cách chặn theo khóa giúp bao phủ những chứng chỉ dùng chung khóa đó, không buộc người dùng Chrome phải chờ một bản cập nhật trình duyệt hay khởi động lại mới nhận được biện pháp bảo vệ này.

Nhưng một máy tính có thể chạy nhiều cơ chế kiểm tra chứng chỉ khác nhau. Trình duyệt, ứng dụng VPN và dịch vụ chạy nền có thể dùng các kho chứng chỉ hoặc thư viện xác thực riêng; kết quả kiểm tra trong Chrome vì thế không đại diện cho mọi kết nối từ thiết bị. Với hệ thống doanh nghiệp, kiểm tra phải đi theo đúng đường kết nối của ứng dụng thực tế.

Cloudflare đã cập nhật các dịch vụ của mình và phát hành bản sửa cho ứng dụng WARP cùng Cloudflare Tunnel. Hãng yêu cầu người dùng cloudflared nâng lên phiên bản 2026.10.2; với triển khai bằng container, cần cập nhật rồi triển khai lại ảnh container đã sửa. Cài gói mới mà tiến trình vẫn dùng thư viện hoặc kho tin cậy cũ trong bộ nhớ có thể khiến việc khắc phục chưa có hiệu lực.

Một mốc khác cần để ý là ngày 27/10/2026, theo giờ Thái Bình Dương của Mỹ: Google dự kiến đưa thay đổi loại emSign ECC Root CA – G3 tới các thiết bị sử dụng Chrome Root Store. Website có chuỗi chứng chỉ dẫn về root này cần chuyển sang chứng chỉ thuộc một hệ thống chứng thực khác được Chrome tin cậy, nếu không có thể gặp lỗi truy cập ngay cả khi chứng chỉ hiện tại vốn được cấp hợp lệ.

PHP2Shell cần vá PHP, không chỉ cập nhật mã nguồn website

WordPress mới nhất vẫn cần một môi trường PHP được duy trì, bởi cập nhật ứng dụng và cập nhật bộ thực thi PHP là hai việc khác nhau. Nếu bản sửa nằm trong PHP, thao tác nâng cấp WordPress hoặc plugin không tự thay thế bộ PHP đang chạy trên hosting.

Theo The Hacker News, nhóm bảo mật PHP đã đánh giá hai lỗ hổng ở mức CVSS v4.0 9,2 và lên lịch phát hành bản bảo mật ngoài chu kỳ vào 14:00 UTC ngày 21/10/2026, tức 21 giờ cùng ngày tại Việt Nam. PHP2Shell là tên gọi do các nhà nghiên cứu sử dụng; tại thời điểm thông báo trước phát hành, chi tiết kỹ thuật và danh sách phiên bản bị ảnh hưởng chưa được công bố đầy đủ.

Thông tin rằng mọi phiên bản từ PHP 5 đều bị ảnh hưởng chưa được xác nhận bằng thông báo chính thức của PHP. Cũng chưa có cơ sở để khẳng định mọi cài đặt WordPress, Drupal hay MediaWiki đều có thể bị chiếm quyền trong cùng điều kiện. Phạm vi phiên bản và cấu hình cần thiết cho một cuộc tấn công phải được đối chiếu khi thông báo kỹ thuật xuất hiện.

Ranh giới hỗ trợ thì rõ hơn: các nhánh có thể nhận bản sửa chính thức là PHP 8.2, 8.3, 8.4 và 8.5. PHP 8.1 trở xuống đã hết vòng đời hỗ trợ của dự án; nếu các lỗ hổng được xác nhận ảnh hưởng tới những nhánh này, người vận hành không thể trông chờ bản vá từ PHP như với nhánh còn được hỗ trợ. Gói vá ngược từ nhà phân phối hoặc nhà cung cấp hosting, nếu có, cần được kiểm tra riêng.

Điều cần làm trước giờ phát hành là kiểm kê phiên bản PHP thực sự phục vụ từng website, chuẩn bị sao lưu và kiểm tra khả năng tương thích khi nâng cấp. Chỉ xem phiên bản PHP của dòng lệnh chưa chắc đã phản ánh đúng bộ thực thi mà dịch vụ web đang dùng, nên quản trị viên cần xác nhận cả cấu hình xử lý yêu cầu của website.

Website thuê hosting cần hỏi nhà cung cấp đúng hai việc

Với một cửa hàng dùng hosting thuê ngoài, việc hữu ích hơn nút cập nhật trong WordPress là yêu cầu nhà cung cấp xác nhận trách nhiệm ở từng lớp. Ai triển khai bản vá PHP cho tài khoản này, và ứng dụng dùng kho chứng chỉ nào khi gọi ra ngoài? Hai câu hỏi đó giúp tránh tình trạng chủ website và bên hosting đều tưởng phần còn lại đã được xử lý.

Ở lớp PHP, cần yêu cầu phiên bản đang chạy, kế hoạch nhận bản vá và thời điểm dịch vụ đã được nạp lại sau cập nhật. Nếu đang ở nhánh hết hỗ trợ, nên chuẩn bị chuyển lên nhánh còn được duy trì thay vì đợi một bản sửa chưa có cam kết. Với hệ thống chưa thể vá ngay, hạn chế truy cập công khai là phương án giảm rủi ro tạm thời, không phải bằng chứng lỗ hổng đã được khắc phục.

Ở lớp TLS, cần rà soát cả kết nối vào website lẫn kết nối từ ứng dụng tới API bên ngoài, đặc biệt khi có kho CA tùy chỉnh hoặc thư viện đóng gói riêng. Nếu sau cập nhật xuất hiện lỗi chứng chỉ, không nên tắt xác minh TLS để làm cho kết nối chạy lại: thao tác đó bỏ đi chính cơ chế xác thực mà bản cập nhật đang cố khôi phục.

Chưa có ghi nhận khai thác PHP2Shell trong các thông tin trước giờ phát hành được công bố, còn Cloudflare cho biết chưa tìm thấy khai thác chủ động sự cố eMudhra trên dịch vụ của mình. Điều đó cho phép chuẩn bị có trật tự, không phải trì hoãn. Mốc tiếp theo với quản trị viên là thông báo PHP chính thức: dùng danh sách phiên bản và điều kiện ảnh hưởng trong đó để quyết định bản vá nào cần triển khai, thay vì dựa vào tin đồn về phạm vi tấn công.

Nguồn tham khảo: Google Security Blog; Cloudflare; The Hacker News; Engadget.