WordPress đã khắc phục một lỗ hổng pre-authentication reflected cross-site scripting (XSS) trong màn hình đăng nhập, ảnh hưởng đến mọi phiên bản của hệ quản trị nội dung này. Trong một số điều kiện bổ sung, lỗi này có thể được kết hợp (chaining) để thực thi mã PHP trên máy chủ.
Được theo dõi dưới mã CVE-2026-64638 (điểm CVSS: 8.9), lỗ hổng mức độ nghiêm trọng High này không yêu cầu quyền hạn của kẻ tấn công. Theo pwn.ai, đơn vị đã phát hiện và chia sẻ chi tiết kỹ thuật với The Hacker News, lỗ hổng XSS trên trang đăng nhập có thể thực thi mà không cần tài khoản hoặc tương tác bổ sung từ nạn nhân sau khi yêu cầu được tạo sẵn được gửi đi.
Lộ trình thực thi mã (code-execution) khó khăn hơn: chuỗi tấn công được trình diễn yêu cầu nạn nhân phải đang đăng nhập với quyền Administrator của một trang web đơn lẻ, thực hiện một cú nhấp chuột thông thường trên trang do kẻ tấn công kiểm soát, cùng với việc một số tính năng và điều kiện triển khai của WordPress phải trùng khớp.
Vấn đề đã được vá vào ngày 6 tháng 8 trong phiên bản WordPress 7.0.3, với các bản vá được hỗ trợ ngược về đến nhánh 4.7. WordPress khuyến nghị cập nhật ngay lập tức; các trang web hỗ trợ cập nhật nền tự động sẽ nhận được bản phát hành bảo mật một cách tự động. 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ợ hiện tại của dự án. Theo W3Techs, WordPress hiện đang vận hành 41,2% tổng số website trên thế giới.
pwn.ai, đơn vị gọi chuỗi tấn công này là XSS2Shell, cho biết hệ thống tự động của họ đã phát hiện và tái hiện chuỗi lỗ hổng sau khi lấy nghiên cứu Same Origin Method Execution (SOME) năm 2022 của Paulos Yibelo làm điểm bắt đầu.
Công ty cho biết công việc này mất gần bốn ngày bằng cách sử dụng các mô hình mã nguồn mở và quy trình làm việc đa tác nhân (multi-agent workflow). Chuỗi tấn công đã được tái hiện vào ngày 26 tháng 7 và được báo cáo cho WordPress ngay ngày hôm sau.
Cơ chế hoạt động của lỗ hổng
Lỗi bắt nguồn từ cách WordPress xử lý tên người dùng sau một lần đăng nhập thất bại. Theo các nhà nghiên cứu, giá trị này đi qua hàm sanitize_user() và wp_strip_all_tags(), vốn dựa trên hàm strip_tags() của PHP. Một chuỗi giống như thẻ (tag-like string) chứa khoảng trắng sau dấu mở < có thể vượt qua bộ phân tích đó dưới dạng văn bản. Sau đó, WordPress chuyển giá trị này qua wp_kses_post(), bộ phân tích riêng biệt của hàm này lại diễn giải cùng một đầu vào đó là HTML được phép. Kết quả là các phần tử DOM trực tiếp do kẻ tấn công kiểm soát xuất hiện trên trang đăng nhập thất bại.
Các phần tử đó sau đó tương tác với user-profile.js của WordPress, một tập lệnh quản lý hồ sơ cũng được tải trên trang đăng nhập vì trang này xử lý việc đặt lại mật khẩu.
Một số phần tử hồ sơ mà tập lệnh mong đợi không xuất hiện ở đó: hai đầu vào bị thiếu đều trả về giá trị undefined, cho phép kiểm tra bằng nhau (equality check) vượt qua, trong khi biến ajaxurl vốn không được xác định có thể bị ghi đè bằng một phần tử DOM được chèn vào. Điều này hướng JavaScript của chính WordPress thực hiện một yêu cầu REST cùng nguồn gốc (same-origin) do kẻ tấn công lựa chọn.
Các nhà nghiên cứu sử dụng hỗ trợ REST JSONP của WordPress để chuyển yêu cầu đó thành mã JavaScript thực thi trong nguồn gốc (origin) của trang web. Đối với các hệ thống triển khai nơi các yêu cầu REST ẩn danh trả về lỗi HTTP 401, tham số _envelope=1 có thể bọc nội dung từ chối trong một phản hồi HTTP 200 bên ngoài, cho phép jQuery tiếp tục xử lý phản hồi đó dưới dạng tập lệnh.
Các nhà nghiên cứu cũng phát hiện trong thử nghiệm của họ rằng chính sách bảo mật nội dung (Content Security Policy) dựa trên nonce sử dụng strict-dynamic không chặn được lộ trình đã trình diễn.
Từ XSS đến thực thi mã PHP
Lộ trình từ XSS đến thực thi mã PHP được xây dựng dựa trên kỹ thuật SOME trước đó của Yibelo, sử dụng chuỗi thuộc tính JSONP được phép để gọi một phương thức trong một cửa sổ trình duyệt khác.
Trong bản trình diễn của pwn.ai, lỗi XSS từ nguồn gốc WordPress đã gọi tính năng phê duyệt Application Password gốc bên trong phiên làm việc của một Administrator đang đăng nhập. WordPress sau đó tạo một thông tin xác thực API và chuyển hướng nó đến một success_url qua HTTPS do kẻ tấn công chọn.
Application Passwords là các thông tin xác thực có thể thu hồi được dành cho việc truy cập API, vì vậy chuỗi tấn công không cần phải đánh cắp mật khẩu chính của quản trị viên.
Các nhà nghiên cứu đã sử dụng thông tin xác thực đó để truy cập REST có xác thực nhằm xuất bản một trang WordPress chứa mã JavaScript cùng nguồn gốc. Khi phiên làm việc của quản trị viên mở trang đó, tập lệnh của nó đã lấy được nonce tải lên plugin của WordPress và tải lên một tệp ZIP do kẻ tấn công cung cấp. Sau đó, mã PHP có thể được thực thi trực tiếp từ plugin đã giải nén. Plugin này thậm chí không cần phải được kích hoạt.
Phạm vi ảnh hưởng và khuyến nghị
Phạm vi ảnh hưởng đến mọi phiên bản áp dụng cho lỗ hổng XSS cơ bản, không nhất thiết là cho lộ trình thực thi mã PHP cụ thể này. Việc leo thang đặc quyền yêu cầu tính năng Application Passwords (được giới thiệu từ WordPress 5.6) và thường được sử dụng qua HTTPS. Nó cũng yêu cầu quản trị viên có các quyền unfiltered_html, upload_plugins thông thường và bộ lưu trữ plugin có quyền ghi.
Hệ thống triển khai cũng phải thiếu các biện pháp bảo mật (hardening) nhằm ngăn chặn việc sửa đổi tệp hoặc thực thi PHP trực tiếp từ các thư mục plugin không hoạt động. Việc vô hiệu hóa Application Passwords sẽ bẻ gãy lộ trình leo thang cụ thể này, nhưng không khắc phục được lỗ hổng XSS tiềm ẩn.
Các nhà nghiên cứu cho biết việc thực thi PHP thành công sẽ làm lộ thông tin xác thực cơ sở dữ liệu WordPress trong tệp wp-config.php, cho phép tạo quản trị viên vĩnh viễn và thay đổi nội dung, lộ các tệp và bí mật mà tiến trình PHP có thể đọc được, đồng thời cho phép thực thi các lệnh hệ điều hành với quyền của tiến trình đó.
WordPress đã ghi nhận đội ngũ pwn.ai vì đã phát hiện và báo cáo lỗ hổng một cách có trách nhiệm. Tính đến ngày 7 tháng 8, thông báo của dự án chưa ghi nhận trường hợp khai thác nào trong thực tế.
