Một lỗ hổng CVE nghiêm trọng, cho phép remote code execution (RCE) tiền xác thực với tên gọi “wp2shell”, đã được công bố trong WordPress Core. Chuỗi lỗ hổng này đe dọa hơn 500 triệu trang web, cho phép kẻ tấn công không cần xác thực chiếm toàn quyền kiểm soát hệ thống.
wp2shell là sự kết hợp của hai lỗ hổng riêng biệt. Chúng bao gồm lỗi nhầm lẫn định tuyến API REST (CVE-2026-63030) và một lỗ hổng SQL injection trong tham số author__not_in của WP_Query (CVE-2026-60137).
Khi được kết hợp, các lỗ hổng này cho phép xâm nhập hoàn toàn máy chủ trên một cài đặt WordPress tiêu chuẩn, ngay cả khi không có plugin nào được cài đặt.
Chi tiết Lỗ Hổng CVE-2026-63030: Lỗi Nhầm Lẫn Định Tuyến API REST
Lỗ hổng này nằm trong điểm cuối batch API REST của WordPress (/wp-json/batch/v1), một tính năng được giới thiệu từ WordPress 5.6 vào năm 2020. Tính năng này cho phép gộp nhiều yêu cầu API ảo vào một lệnh gọi duy nhất.
Trong hoạt động bình thường, mỗi yêu cầu REST riêng lẻ trải qua quy trình bốn bước: xác thực tham số, làm sạch tham số, gọi lại quyền và cuối cùng là gọi lại thực thi của điểm cuối.
Tuy nhiên, điểm cuối batch phá vỡ mô hình này bằng cách chạy xác thực và thực thi thành hai vòng lặp riêng biệt thay vì xử lý tuần tự từng yêu cầu.
Nếu một yêu cầu trong batch bị lỗi định dạng, mảng xác thực sẽ ghi lại lỗi. Tuy nhiên, mảng tương ứng của các trình xử lý được giải quyết lại không được cập nhật đồng bộ.
Điều này là do một câu lệnh continue bỏ qua việc chèn mảng ở một bên nhưng không ở bên kia. Hậu quả là làm mất đồng bộ hóa chỉ mục giữa hai mảng.
Khi quá trình thực thi diễn ra, các tham số đã được xác thực của yêu cầu N có thể được áp dụng cho trình xử lý thực tế của yêu cầu N+1. Điều này bỏ qua hoàn toàn việc làm sạch tham số dự kiến.
Lỗi mất đồng bộ này được phân loại theo CWE-436 (xung đột diễn giải) và có điểm CVSS v3.1 cơ bản là 7.5 (Cao).
Cơ chế Vượt Qua Xác Thực Tham Số
Lỗi mất đồng bộ cho phép kẻ tấn công vượt qua các cơ chế xác thực và làm sạch tham số thông thường. Điều này tạo ra một cửa ngõ để chèn dữ liệu độc hại.
Bản thân lỗi này không trực tiếp gây hại nếu không có một sink dễ bị tổn thương để khai thác. Sink đó chính là tham số author__not_in của WP_Query.
Chi tiết Lỗ Hổng CVE-2026-60137: SQL Injection trong WP_Query
Tham số author__not_in của WP_Query là lớp cốt lõi của WordPress để xây dựng các truy vấn cơ sở dữ liệu. Khi tham số này được gửi dưới dạng một mảng, WordPress sẽ làm sạch từng giá trị bằng cách sử dụng absint().
Tuy nhiên, nếu tham số được gửi dưới dạng một chuỗi vô hướng thô, bước làm sạch sẽ bị bỏ qua hoàn toàn. Giá trị sẽ được nội suy trực tiếp vào một mệnh đề SQL NOT IN thô.
Thông thường, đường dẫn này không thể truy cập được. Lý do là tham số author_exclude hướng ra công chúng được xác thực là một mảng số nguyên trước khi đến author__not_in.
Khai thác SQL Injection thông qua Lỗi Desync
Lỗi mất đồng bộ định tuyến batch sẽ bỏ qua quá trình xác thực đó, cho phép một payload SQL vô hướng lọt qua mà không bị chạm tới.
Vì điểm cuối cơ bản chỉ hỗ trợ các yêu cầu GET (mà batch API không cho phép tự nhiên), khai thác này sử dụng một lệnh gọi batch lồng nhau, đệ quy. Điều này nhằm để đưa yêu cầu GET qua cơ chế desync lần thứ hai.
Lỗ hổng này được phân loại theo CWE-89 (SQL injection) và được đánh giá 9.1 (Nghiêm trọng) trên thang điểm CVSS v3.1.
Chuỗi Khai thác Remote Code Execution (RCE)
Bản thân lỗi SQL injection chỉ là một lỗi rò rỉ dữ liệu “SELECT-only”, không thể trực tiếp lấy các thông tin đăng nhập dạng văn bản rõ ràng, vì WordPress mã hóa mật khẩu trong cơ sở dữ liệu.
Đường dẫn leo thang được mô hình AI phát triển đã khai thác một chuỗi các hành vi phụ của WordPress để đạt được quyền remote code execution.
Với một tài khoản quản trị viên giả mạo trong tay, kẻ tấn công đăng nhập bình thường. Sau đó, chúng tải lên một tệp ZIP plugin độc hại, từ đó đạt được remote code execution toàn diện trên máy chủ.
Phát hiện Lỗ hổng CVE bằng Trí tuệ Nhân tạo
Điều làm cho wp2shell khác biệt so với các vấn đề bảo mật WordPress thông thường là nó không yêu cầu bất kỳ điều kiện tiên quyết nào. Không cần tài khoản hợp lệ, không cần plugin dễ bị tổn thương, không cần cấu hình đặc biệt và không cần tương tác của người dùng.
Bất kỳ kẻ tấn công ẩn danh nào có khả năng tiếp cận một phiên bản WordPress dễ bị tổn thương qua mạng đều có thể xâm nhập nó ngay lập tức.
Lỗ hổng nghiêm trọng này được phát hiện bởi nhà nghiên cứu bảo mật Adam Kues của nhóm nghiên cứu Assetnote thuộc Searchlight Cyber. Ông đã sử dụng một phương pháp độc đáo: một dự án nghiên cứu lỗ hổng do AI điều khiển, được hỗ trợ bởi mô hình GPT-5.6 Sol Ultra của OpenAI.
Quá trình Nghiên cứu và Khai thác
Kues đã điều chỉnh một câu lệnh ban đầu được OpenAI xuất bản, từng được sử dụng để giúp mô hình giải quyết giả thuyết toán học “Cycle Double Cover”. Ông đã hướng nó vào cơ sở mã nguồn WordPress Core.
Ông đã hướng dẫn mô hình tìm kiếm một chuỗi pre-authentication-to-RCE, sử dụng tối đa bốn tác nhân nghiên cứu song song trong ít nhất sáu giờ. Kues yêu cầu mô hình không tham khảo nhật ký thay đổi, lịch sử git, hoặc internet để so sánh với các phiên bản đã được vá, buộc nó phải khám phá lỗi hoàn toàn thông qua phân tích mã từ nguyên tắc đầu tiên.
Mô hình cũng được cho phép sao chép và kiểm toán các phụ thuộc của bên thứ ba nếu một chuỗi hoàn chỉnh yêu cầu lỗi trong các thư viện cơ bản như PHP hoặc MySQL.
Kết quả: Sol đã xác định một SQL injection tiền xác thực hoàn chỉnh trong cơ sở mã. Ban đầu Kues nghi ngờ điều này vì WordPress có lịch sử mười năm không có các lỗ hổng tiền xác thực lớn.
Sau khi xác thực SQLi trên một phiên bản thử nghiệm trực tiếp bằng cách trích xuất địa chỉ email của quản trị viên, Kues đã hỏi mô hình liệu nó có thể leo thang lỗi thành RCE hoàn chỉnh hay không.
Khoảng bốn giờ sau, mô hình đã trả lời khẳng định với một chuỗi leo thang hoạt động. Tổng chi phí tính toán cho toàn bộ quá trình khám phá là khoảng 25 USD, dựa trên chi phí đăng ký 200 USD mỗi tháng.
Kues lưu ý rằng việc hiểu và ghi lại chuỗi khai thác do AI tạo ra đã tốn của ông nhiều thời gian hơn so với thời gian mô hình phát triển nó, gọi kỹ thuật hậu khai thác này là “hoàn toàn phi lý” về mức độ phức tạp.
Các phiên bản WordPress bị ảnh hưởng và Cập nhật Bản vá
Nhánh 6.8.x chỉ chứa thành phần SQL injection và không bị ảnh hưởng bởi chuỗi RCE không xác thực hoàn chỉnh. Điều này là do lỗi nhầm lẫn định tuyến batch (CVE-2026-63030) chỉ được giới thiệu trong WordPress 6.9.
Các phiên bản WordPress đã được vá lỗi bao gồm WordPress 6.8.6, 6.9.5 và 7.0.2, cùng với 7.1 Beta 2 cho nhánh phát hành trước.
WordPress đã phát hành các bản cập nhật bản vá bảo mật khẩn cấp vào ngày 17 tháng 7 năm 2026, giải quyết đồng thời cả hai lỗ hổng. Với mức độ nghiêm trọng, nhóm bảo mật WordPress.org đã thực hiện bước hiếm hoi là bật tính năng tự động cập nhật bắt buộc.
Cơ chế này được áp dụng cho tất cả các cài đặt được hỗ trợ đang chạy các phiên bản bị ảnh hưởng, một cơ chế thường chỉ dành cho các tình huống cấp độ khủng hoảng. Các quản trị viên vẫn được khuyến khích xác minh thủ công rằng quá trình cập nhật bản vá đã hoàn tất.
Lý do là cài đặt tự động cập nhật, triển khai tùy chỉnh hoặc cấu hình hosting được quản lý có thể ngăn chặn quá trình áp dụng bản vá. CVE-2026-60137 cũng được báo cáo độc lập cho nhóm bảo mật WordPress bởi các nhà nghiên cứu TF1T, dtro và haongo, và đã được vá trong cùng một chu kỳ phát hành với chuỗi RCE do Kues phát hiện.
Khai thác trong Thực tế và IOC
Searchlight Cyber ban đầu giữ lại các chi tiết khai thác kỹ thuật đầy đủ để cung cấp thời gian cho chủ sở hữu trang web vá lỗi sau khi công bố, chỉ phát hành một trình quét công khai miễn phí, không xâm nhập tại wp2shell[.]com để quản trị viên có thể kiểm tra mức độ tiếp xúc của họ.
Mặc dù nhà nghiên cứu trì hoãn công bố, các khai thác proof-of-concept (PoC) công khai đã bắt đầu lan truyền trên GitHub trong vòng khoảng 24 giờ. Searchlight Cyber lưu ý rằng trong thời gian giữ lại thông tin, hai nhóm khác là Calif và Hacktron đã độc lập tái tạo chuỗi khai thác hoàn chỉnh trước khi các PoC bổ sung xuất hiện công khai.
Nhiều nhà cung cấp bảo mật đã xác nhận các nỗ lực khai thác trong thế giới thực sớm. Giám đốc điều hành watchTowr, Benjamin Harris, nói với các phóng viên rằng công ty đã “thấy các khai thác PoC đang lưu hành” với “những dấu hiệu khai thác đầu tiên trong thực tế”.
Maurice Fielenback, người đứng đầu Cyber Threat Intelligence của Hexastrike, tuyên bố rằng công ty tiếp tục thấy “các nỗ lực và khai thác wp2shell thành công” và đã “xử lý một số sự cố đã xác nhận và nghi ngờ” sau khi gắn cờ các nỗ lực khai thác ban đầu vào Chủ nhật trước đó.
Một số biến thể khai thác được phát hành công khai chứng minh việc trích xuất các hàm băm mật khẩu quản trị viên thông qua thành phần SQL injection và brute-force thông tin đăng nhập ngoại tuyến, trong khi những biến thể khác tái tạo chuỗi RCE tiền xác thực hoàn chỉnh của nhà nghiên cứu mà không cần phải phá bất kỳ mật khẩu nào.
Các biện pháp giảm thiểu tạm thời
Cloudflare đã báo cáo rằng đường dẫn mã dễ bị tổn thương đặc biệt có thể truy cập được khi không sử dụng persistent object cache trên máy chủ đích. Công ty đã triển khai các biện pháp bảo vệ WAF chống lại cả hai lỗ hổng CVE trên tất cả các gói dịch vụ khách hàng, bao gồm cả gói miễn phí của họ, cho các miền được proxy.
Các nhà cung cấp bảo mật nhấn mạnh rằng việc chặn ở cấp độ WAF và các plugin hạn chế API REST chỉ là các biện pháp tạm thời. Chúng có thể làm gián đoạn chức năng hợp lệ của trang web. Nâng cấp phiên bản Core vẫn là biện pháp khắc phục bền vững duy nhất cho lỗ hổng CVE này.
Khuyến nghị Bảo mật và Cập nhật Bản vá
Nâng cấp WordPress Core lên phiên bản đã được vá được mô tả bởi mọi nhà cung cấp lớn là cách khắc phục hoàn toàn duy nhất cho lỗ hổng CVE này.
Các bước khắc phục được khuyến nghị bao gồm:
- Xác minh rằng tất cả các cài đặt WordPress đang chạy các phiên bản bị ảnh hưởng đã được cập nhật bản vá lên 6.8.6, 6.9.5, 7.0.2 hoặc 7.1 Beta 2.
- Kiểm tra nhật ký hệ thống và nhật ký truy cập để tìm bất kỳ dấu hiệu khai thác nào, đặc biệt là các yêu cầu bất thường đến
/wp-json/batch/v1. - Đảm bảo hệ thống sử dụng một giải pháp WAF mạnh mẽ có thể giúp chặn các nỗ lực khai thác đã biết, mặc dù đây không phải là giải pháp lâu dài.
- Thực hiện quét bảo mật định kỳ để phát hiện các dấu hiệu xâm nhập hoặc cài đặt trái phép.
Tầm quan trọng của AI trong Nghiên cứu Bảo mật
Việc công bố wp2shell đáng chú ý không chỉ vì mức độ nghiêm trọng về mặt kỹ thuật mà còn vì cách nó được tìm thấy. Tài khoản của Kues báo hiệu một sự thay đổi trong kinh tế nghiên cứu lỗ hổng.
Chi phí tính toán AI 25 USD đã phát hiện ra một loại lỗi mà theo Searchlight Cyber, các nhà môi giới khai thác đã từng trả tới 500.000 USD để có được.
Kues lập luận rằng các kỹ thuật khai thác được mô hình kết hợp, bao gồm lạm dụng lệnh gọi batch đệ quy, các tiện ích mất đồng bộ bộ nhớ cache và leo thang đặc quyền phát lại hook, phản ánh lý luận sáng tạo mà ông trước đây cho rằng chỉ dành riêng cho các nhà nghiên cứu con người có kinh nghiệm.
Ông gợi ý rằng khi các mô hình AI đảm nhận nhiều khối lượng công việc phát triển khai thác kỹ thuật hơn, vai trò của các nhà nghiên cứu bảo mật con người có thể chuyển sang hướng cấp cao hơn: chọn mục tiêu, tạo ra các câu lệnh nghiên cứu và định hướng chiến lược điều tra thay vì kiểm toán mã thủ công.
