💡 Theo đánh giá của RetroLab, đây là một trong những lỗ hổng WordPress nguy hiểm nhất thời gian gần đây vì không yêu cầu điều kiện tiên quyết và có thể khai thác trên cài đặt mặc định. Cộng đồng bảo mật cần nhanh chóng áp dụng bản vá trước khi bị khai thác hàng loạt.
Một lỗ hổng bảo mật nghiêm trọng vừa được phát hiện trong lõi WordPress, có biệt danh là wp2shell, cho phép kẻ tấn công chưa xác thực thực thi mã tùy ý trên trang web chỉ bằng một yêu cầu HTTP ẩn danh. Điều đáng nói là lỗ hổng này tồn tại ngay trong core, nghĩa là một trang WordPress hoàn toàn trần trụi, không cài bất kỳ plugin nào, vẫn có thể bị khai thác.
WordPress đã phát hành các bản vá khẩn cấp 6.9.5 và 7.0.2 vào thứ Sáu vừa qua, đồng thời kích hoạt cơ chế cập nhật cưỡng bức (forced update) thông qua hệ thống tự động. Tuy nhiên, vẫn chưa rõ liệu bản vá này có đến được với những trang đã tắt tính năng tự động cập nhật hay không.
Hai lỗ hổng, một chuỗi khai thác chết người
wp2shell thực chất là hai lỗ hổng riêng biệt, mỗi lỗ đã có mã CVE riêng:
- CVE-2026-63030: Lỗ hổng nhầm lẫn batch route trong REST API.
- CVE-2026-60137: Lỗ hổng SQL injection trong lõi WordPress.
Khi kết hợp, hai lỗ hổng này tạo thành một chuỗi khai thác hoàn chỉnh, đưa một yêu cầu ẩn danh từ đầu đến cuối để thực thi mã trên máy chủ.
Adam Kues từ Assetnote (bộ phận quản lý bề mặt tấn công của Searchlight Cyber) đã phát hiện lỗi batch route và báo cáo qua chương trình HackerOne của WordPress. Lỗi SQL injection được báo cáo riêng bởi TF1T, dtro và haongo.
Bài viết kỹ thuật của Searchlight, được công bố dưới tên wp2shell, mô tả cuộc tấn công “không có điều kiện tiên quyết và có thể bị khai thác bởi người dùng ẩn danh.”
Phiên bản nào bị ảnh hưởng?
Hai lỗ hổng không cùng tồn tại trên tất cả các phiên bản. SQL injection có từ bản 6.8, trong khi lỗi batch route chỉ xuất hiện từ bản 6.9. Do đó, phạm vi ảnh hưởng được chia làm ba nhóm:
- WordPress 6.8.0 – 6.8.5: Chỉ có SQL injection, được vá trong bản 6.8.6.
- WordPress 6.9.0 – 6.9.4: Chuỗi RCE hoàn chỉnh, được vá trong bản 6.9.5.
- WordPress 7.0.0 – 7.0.1: Chuỗi RCE hoàn chỉnh, được vá trong bản 7.0.2.
Phiên bản 7.1 beta2 đã bao gồm cả hai bản sửa lỗi. Các trang dùng bản 6.8 không thể bị khai thác RCE qua chuỗi này, đó là lý do bản 6.8.6 chỉ vá riêng SQL injection.
Cơ chế hoạt động của chuỗi khai thác
Lỗi SQL injection nằm ở tham số author__not_in của lớp WP_Query. Khi truyền một chuỗi thay vì mảng, WordPress bỏ qua kiểm tra và đưa giá trị thô trực tiếp vào câu truy vấn.
Để truy cập tham số đó mà không cần đăng nhập, kẻ tấn công lợi dụng endpoint /wp-json/batch/v1. Endpoint này cho phép thực thi nhiều yêu cầu con trong một lần gọi và theo dõi chúng bằng hai mảng song song. Nếu một yêu cầu con gặp lỗi, hai mảng bị lệch nhau, khiến yêu cầu tiếp theo chạy dưới handler của yêu cầu khác. Sự nhầm lẫn này vượt qua danh sách trắng của endpoint và đưa input của kẻ tấn công vào truy vấn dễ bị tấn công.
Endpoint batch đã có từ WordPress 5.6 (năm 2020), nhưng lỗi nhầm lẫn mới chỉ xuất hiện từ bản 6.9.
Điểm số CVE và mức độ nguy hiểm
WordPress tự đánh giá chuỗi RCE này ở mức Critical trong advisory của mình. Tuy nhiên, bản ghi CVE lại chỉ cho điểm 7.5 (High), với các chỉ số tác động chỉ đề cập đến khả năng truy cập dữ liệu, không phải mất mát toàn vẹn hay khả dụng như mong đợi từ một lỗi thực thi mã. Trong khi đó, lỗi SQL injection có điểm trên 9.1 (Critical).
Điều này có nghĩa là lỗ hổng được mọi người gọi là “RCE nghiêm trọng” thực ra lại có điểm số thấp hơn, vì hệ thống tính điểm ưu tiên khả năng truy cập trực tiếp vào cơ sở dữ liệu của SQL injection, còn lỗi batch route bị coi là lỗi phân tích cú pháp đơn thuần. Hãy theo dõi cả hai CVE, đừng chỉ nhìn vào nhãn mác.
Một yếu tố thu hẹp phạm vi
Chuỗi thực thi mã chỉ hoạt động khi trang web không sử dụng bộ đệm đối tượng liên tục (persistent object cache) như Redis hay Memcached. Theo Cloudflare, một cài đặt mặc định của WordPress không có bộ đệm này, nên hầu hết các trang mặc định vẫn nằm trong diện nguy hiểm. Tuy nhiên, việc có bộ đệm chỉ là tác dụng phụ, không phải bản vá, và nó cũng không che chắn được lỗi SQL injection.
Giải pháp tạm thời nếu chưa thể cập nhật
Searchlight đưa ra một số biện pháp giảm thiểu, nhưng tất cả đều là giải pháp tạm thời và có thể làm hỏng các tích hợp hợp pháp:
- Chặn cả hai đường dẫn /wp-json/batch/v1 và rest_route=/batch/v1 trên WAF. Cloudflare cho biết WAF được quản lý của họ đã chặn chuỗi này cho các trang đứng sau.
- Vô hiệu hóa WP REST API hoàn toàn bằng plugin như Disable WP REST API.
- Sử dụng một plugin drop-in ngắn do Searchlight công bố, từ chối các yêu cầu ẩn danh tới /batch/v1 tại rest_pre_dispatch.
Cuộc đua giữa bản vá và khai thác
WordPress core là mã nguồn mở, và bản phát hành đã nêu rõ các tệp được thay đổi. Điều đó đồng nghĩa với việc phát hành bản vá cũng đồng thời tiết lộ bản đồ dẫn đến lỗ hổng. Searchlight đã giữ lại bài viết kỹ thuật của mình, nhưng chỉ trong vòng một ngày, các nhà nghiên cứu khác đã đọc bản vá, công bố cơ chế và đưa mã khai thác lên GitHub.
Hiện tại, mã khai thác đã công khai và bản vá vẫn đang được triển khai. Thống kê phiên bản WordPress sẽ cho thấy bao nhiêu trang đã cập nhật; lưu lượng quét /batch/v1 sẽ cho thấy bao nhiêu kẻ tấn công đang tìm kiếm. Đường cong nào dốc hơn sẽ quyết định cách lịch sử ghi nhớ sự kiện này.
Mass exploitation của WordPress đã trở thành một ngành công nghiệp. Trước khi máy chủ của chúng bị lộ hồi tháng Sáu, một lỗ hổng plugin caching đơn lẻ đã giúp nhóm WP-SHELLSTORM xâm nhập hơn 17.000 trang web, dù lỗi đó chỉ hoạt động trên cài đặt không mặc định và đã được vá. Lần này, lỗ hổng hoạt động trên cài đặt mặc định, đã được vá, và đã công khai.
Nguồn: The Hacker News - https://thehackernews.com/2026/07/new-wp2shell-wordpress-core-flaw-lets.html
