Ngày 17/7/2026, đội ngũ bảo mật WordPress đã phát hành bản vá khẩn cấp cho một chuỗi hai lỗ hổng nghiêm trọng trong lõi (core) của nền tảng, được giới nghiên cứu đặt tên là wp2shell. Đây được đánh giá là một trong những sự cố bảo mật nghiêm trọng nhất trong lịch sử gần đây của WordPress, bởi nó cho phép thực thi mã từ xa (RCE) mà không cần xác thực - tức kẻ tấn công không cần tài khoản, không cần plugin đặc biệt, không cần cấu hình sai, chỉ cần gửi một yêu cầu HTTP tới một website WordPress cài đặt mặc định.
Với WordPress đang vận hành hơn 500 triệu website trên toàn cầu, mức độ ảnh hưởng tiềm tàng là cực lớn.
Chuỗi lỗ hổng: hai mảnh ghép tạo nên thảm họa
wp2shell không phải một lỗ hổng đơn lẻ mà là sự kết hợp của hai điểm yếu:
1. CVE-2026-60137 - Lỗi SQL Injection trong thành phần WP_Query, tồn tại từ phiên bản 6.8 trở lên. Lỗi này cho phép kẻ tấn công thao túng truy vấn cơ sở dữ liệu để đọc hoặc chỉnh sửa dữ liệu mà không cần đăng nhập.
2. CVE-2026-63030 - Lỗi "route confusion" (nhầm lẫn định tuyến) trong REST API, cụ thể tại hàm WP_REST_Server::serve_batch_request_v1(), xuất hiện từ phiên bản 6.9. Theo phân tích của các nhà nghiên cứu Hacktron, lỗi này khiến các mảng chứa sub-request, kết quả xác thực và handler bị xử lý bị lệch nhau, dẫn đến việc WordPress hiểu nhầm rằng mọi request - kể cả những request đáng lẽ phải bị chặn - đều đã được xác thực hợp lệ.
Riêng lẻ, cả hai lỗi đều khó khai thác. Nhưng khi kết hợp: một request dạng batch (gộp nhiều request con), được xây dựng lồng nhau và có cấu trúc dị dạng, có thể lợi dụng lỗi route confusion để vượt qua bước kiểm tra quyền, sau đó kích hoạt lỗi SQL injection - mở đường cho việc thực thi mã tùy ý trên máy chủ.
Phạm vi ảnh hưởng
- WordPress 6.9.0 đến 6.9.4 và 7.0.0 đến 7.0.1: dính cả hai lỗ hổng, tức chịu rủi ro RCE đầy đủ.
- WordPress 6.8.0 đến 6.8.5: chỉ dính lỗi SQL injection (CVE-2026-60137), không có route confusion nên không bị chuỗi tấn công đầy đủ.
- Trước phiên bản 6.8: không bị ảnh hưởng bởi chuỗi lỗi này (nhưng vẫn có thể tồn tại các lỗi bảo mật khác không liên quan).
- WordPress 7.1 Beta 1 cũng bị ảnh hưởng; bản Beta 2 đã khắc phục.
Lỗ hổng được phát hiện bởi nhà nghiên cứu Adam Kues thuộc Assetnote (một nhánh của Searchlight Cyber), và được công bố có trách nhiệm thông qua chương trình HackerOne của WordPress.
Diễn biến: từ vá lỗi đến khai thác thực tế chỉ trong vài giờ
- 17/7/2026: WordPress phát hành các phiên bản vá 6.8.6, 6.9.5 và 7.0.2. Do mức độ nghiêm trọng, đội ngũ bảo mật đã chủ động bật tính năng tự động cập nhật bắt buộc cho các site đang chạy phiên bản bị ảnh hưởng - một biện pháp hiếm khi được áp dụng.
- Chỉ vài giờ sau khi bản vá được công bố, một mã khai thác thử nghiệm (PoC) đã xuất hiện công khai trên GitHub. Các chuyên gia từ Rapid7 Labs từng dự đoán trước điều này, do WordPress là mã nguồn mở và khả năng phân tích mã nguồn mở bằng AI hiện nay đã rút ngắn đáng kể thời gian từ vá lỗi đến khai thác.
- 20/7/2026: Nhiều công ty an ninh mạng như Patchstack, Hexastrike và WatchTowr xác nhận tin tặc đã bắt đầu khai thác lỗ hổng trong thực tế, chiếm quyền kiểm soát các website chưa được vá. Theo ước tính, có tới hàng chục triệu website vẫn đang chạy các phiên bản dễ bị tổn thương.
Đáng chú ý, sự việc này diễn ra gần như song song với một chiến dịch tấn công khác mang tên "WP-SHELLSTORM" nhắm vào một lỗ hổng đã biết trong plugin caching (chỉ khai thác được khi bật một tùy chọn không mặc định), được cho là đã ảnh hưởng hơn 17.000 website. Hai sự cố này không liên quan đến nhau về mặt kỹ thuật, nhưng cùng nhấn mạnh tầm quan trọng của việc cập nhật đầy đủ cả core, plugin lẫn theme.
Vì sao lỗ hổng này đặc biệt nguy hiểm
- Không cần xác thực: kẻ tấn công ẩn danh có thể khai thác trên một bản cài đặt WordPress mặc định, không cần plugin bổ sung.
- Không cần điều kiện tiên quyết đặc biệt: không phụ thuộc cấu hình lạ hay plugin bên thứ ba.
- Hậu quả tối đa: RCE là mức độ nghiêm trọng cao nhất trong phân loại lỗ hổng - kẻ tấn công khai thác thành công có thể toàn quyền kiểm soát máy chủ web.
- Tốc độ khai thác nhanh bất thường: khoảng cách giữa công bố bản vá và xuất hiện mã khai thác công khai chỉ tính bằng giờ, khiến "cửa sổ vá lỗi an toàn" gần như không tồn tại đối với các quản trị viên chậm cập nhật.
Khuyến nghị hành động cho quản trị viên WordPress
- Cập nhật ngay lập tức lên phiên bản 6.8.6, 6.9.5 hoặc 7.0.2 (hoặc mới hơn). Vì WordPress đã bật auto-update bắt buộc cho các phiên bản bị ảnh hưởng, nhiều site có thể đã được vá tự động - nhưng vẫn nên kiểm tra thủ công để chắc chắn.
- Kiểm tra xem site có bị xâm nhập trước khi vá hay chưa, đặc biệt nếu site chạy phiên bản dễ tổn thương trong khoảng thời gian từ 17 - 20/7/2026. Có thể dùng công cụ kiểm tra công khai do Searchlight Cyber phát hành (wp2shell.com) để xác định tình trạng.
- Nếu chưa thể cập nhật ngay, cân nhắc chặn tạm thời endpoint
/wp-json/batch/v1ở tầng WAF (tường lửa ứng dụng web) như một biện pháp tình thế. - Rà soát log truy cập để phát hiện các request bất thường tới REST API batch endpoint trong thời gian gần đây.
- Duy trì thói quen cập nhật core, plugin và theme thường xuyên, vì đây là tuyến phòng thủ cơ bản nhưng hiệu quả nhất trước các lỗ hổng dạng này.
Kết luận
wp2shell là lời nhắc nhở rõ ràng rằng ngay cả một nền tảng được duy trì tích cực và có cộng đồng bảo mật lớn như WordPress vẫn có thể tồn tại những lỗ hổng nghiêm trọng ở tầng lõi. Việc hai lỗi riêng lẻ - vốn "khó khai thác" khi đứng một mình - kết hợp lại tạo thành một chuỗi tấn công RCE hoàn chỉnh cho thấy tầm quan trọng của việc đánh giá bảo mật toàn diện thay vì chỉ nhìn từng lỗ hổng đơn lẻ. Với tốc độ khai thác trong thực tế chỉ tính bằng giờ sau khi bản vá được công bố, các quản trị viên WordPress cần coi việc cập nhật bảo mật khẩn cấp là ưu tiên hàng đầu, không thể trì hoãn.
