Nội dung bài viết
WordPress vừa vá một lỗ hổng XSS phản xạ (reflected XSS) ngay tại trang đăng nhập, ảnh hưởng mọi phiên bản của hệ quản trị nội dung này. Lỗ hổng mang mã CVE-2026-64638, điểm CVSS 8.9 (mức cao) và không yêu cầu kẻ tấn công có bất kỳ quyền nào.
Công ty bảo mật pwn.ai - đơn vị phát hiện lỗi - đã trình diễn cách ghép lỗ hổng này thành chuỗi tấn công đặt tên XSS2Shell, kết thúc bằng việc chạy mã PHP trên máy chủ khi một quản trị viên đang đăng nhập tương tác với trang do kẻ tấn công kiểm soát. Trong bản demo, tương tác đó chỉ là một cú click bình thường.
Phạm vi ảnh hưởng và bản vá
- Bản vá phát hành ngày 6/8/2026 ở WordPress 7.0.3, đưa ngược về tới nhánh 4.7.
- Website hỗ trợ cập nhật nền tự động sẽ tự nhận bản vá.
- Các phiên bản cũ hơn 4.7 vẫn bị ảnh hưởng nhưng nằm ngoài phạm vi hỗ trợ.
- Theo pwn.ai, tấn công hoạt động trên cài đặt WordPress mặc định, không cần cấu hình hosting đặc biệt.
WordPress có đánh giá thận trọng hơn: việc leo thang lên RCE phụ thuộc các điều kiện ngoài tầm kiểm soát của kẻ tấn công, cần lừa đảo (social engineering) thành công và nạn nhân phải chủ động tương tác. Tuy vậy, cả hai bên đều thống nhất: cập nhật là bắt buộc, các biện pháp gia cố WordPress thông thường không thay thế được bản vá.
Cách lỗi hoạt động (tóm tắt)
Bước 1 - XSS ở trang đăng nhập thất bại. Tên đăng nhập người dùng nhập vào đi qua sanitize_user() và wp_strip_all_tags() (dựa trên strip_tags() của PHP). Một chuỗi trông giống thẻ HTML nhưng có khoảng trắng ngay sau dấu < có thể lọt qua bộ lọc này dưới dạng văn bản. Sau đó, giá trị được đưa qua wp_kses_post() - một bộ phân tích khác lại hiểu chính chuỗi đó là HTML hợp lệ. Kết quả: kẻ tấn công chèn được phần tử DOM vào trang báo lỗi đăng nhập.
Bước 2 - Lợi dụng chính JavaScript của WordPress. Trang đăng nhập có nạp user-profile.js (do trang này xử lý cả đặt lại mật khẩu). Vì thiếu một số phần tử mà script mong đợi, kẻ tấn công có thể "ghi đè" biến ajaxurl bằng phần tử DOM tự chèn, điều hướng script gửi một request REST cùng nguồn (same-origin) theo ý mình. Tận dụng hỗ trợ JSONP của REST API, request đó được biến thành JavaScript chạy trong origin của website. Nhóm nghiên cứu cho biết Content Security Policy dạng nonce với strict-dynamic cũng không chặn được đường đi này.
Bước 3 - Từ XSS tới PHP. Dựa trên kỹ thuật SOME (Same Origin Method Execution) của Paulos Yibelo công bố năm 2022, một biến thể của chuỗi tấn công kích hoạt nút phê duyệt Application Password trong phiên của quản trị viên. WordPress tạo một thông tin xác thực API và gửi về địa chỉ do kẻ tấn công chọn. Với thông tin này, kẻ tấn công đăng một trang chứa JavaScript; khi quản trị viên mở trang đó, script lấy nonce tải plugin lên và upload một file ZIP. Mã PHP trong plugin có thể được gọi trực tiếp mà không cần kích hoạt plugin.
Hậu quả nếu bị khai thác
Khi chạy được PHP, kẻ tấn công có thể:
- đọc thông tin kết nối database trong
wp-config.php; - tạo tài khoản quản trị tồn tại lâu dài, thay đổi nội dung;
- đọc file và bí mật mà tiến trình PHP truy cập được;
- chạy lệnh hệ điều hành với quyền của tiến trình PHP.
Phát hiện bằng hệ thống AI
Điểm đáng chú ý: pwn.ai cho biết hệ thống tự động của họ đã tự tìm ra và tái hiện chuỗi lỗ hổng sau khi được cung cấp nghiên cứu SOME năm 2022 làm điểm xuất phát. Quá trình mất gần bốn ngày, dùng các mô hình mã nguồn mở và quy trình đa tác tử (multi-agent). Chuỗi được tái hiện ngày 26/7 và báo cho WordPress ngày hôm sau.
Toàn bộ chuỗi tới thực thi PHP chỉ được trình diễn trên một bản WordPress 7.0.2 sạch ở môi trường cục bộ. Đến ngày 7/8, thông báo của WordPress chưa ghi nhận việc lỗ hổng bị khai thác ngoài thực tế.
Nguồn tham khảo: The Hacker News, pwn.ai và thông báo bảo mật của WordPress.
