Đã đăng vào Thứ Bảy, 9:19 SA 19 phút đọc

Lỗ hổng bảo mật "wp2shell" trong WordPress Core cho phép thực thi mã từ xa (Pre-Auth RCE): Hướng dẫn khắc phục chi tiết

Vào tháng 7 năm 2026, Adam Kues, một nhà nghiên cứu bảo mật tại công ty an ninh mạng Searchlight Cyber, đã công bố một lỗ hổng bảo mật cực kỳ nghiêm trọng trong mã nguồn cốt lõi (core) của WordPress với tên gọi wp2shell. Đây là một lỗ hổng thực thi mã từ xa trước khi xác thực (Pre-Authentication RCE), đồng nghĩa với việc kẻ tấn công có thể thực hiện các cuộc tấn công từ xa trên một bản cài đặt WordPress gốc (mặc định) mà không cần tài khoản đăng nhập hay bất kỳ plugin nào.

WordPress Vulnerability

Với hơn 500 triệu trang web đang hoạt động bằng nền tảng WordPress trên toàn thế giới, quy mô và mức độ ảnh hưởng của lỗ hổng này là vô cùng lớn.

Tổng quan về lỗ hổng

Điều khiến wp2shell trở nên đặc biệt nguy hiểm là rào cản tấn công cực kỳ thấp [1]. Khác với hầu hết các sự cố bảo mật của WordPress trước đây, lỗi này nằm ngay trong chính phần mã nguồn cốt lõi (WordPress Core) chứ không phải ở các plugin hay giao diện (theme) bên thứ ba [1]. Một người dùng ẩn danh có thể thực thi mã từ xa trên một bản cài đặt WordPress mặc định mà không cần bất kỳ điều kiện tiên quyết nào [1].

Để dành đủ thời gian cho quản trị viên trên toàn thế giới áp dụng các bản vá, Searchlight Cyber hiện chưa công bố chi tiết kỹ thuật chuyên sâu về lỗ hổng này [1]. Tuy nhiên, họ đã phát hành một công cụ kiểm tra trực tuyến để quản trị viên có thể tự xác minh xem trang web của mình có bị ảnh hưởng hay không [1].

Các phiên bản bị ảnh hưởng

Phiên bản WordPress	Trạng thái	Phiên bản đã vá
< 6.9.0	Không bị ảnh hưởng	—
6.9.0 – 6.9.4	Bị ảnh hưởng	6.9.5
7.0.0 – 7.0.1	Bị ảnh hưởng	7.0.2

Nếu trang web của bạn đang chạy phiên bản từ 6.9.0 đến 6.9.4, bạn phải nâng cấp lên phiên bản 6.9.5 [1]. Các trang web chạy phiên bản 7.0.0 hoặc 7.0.1 cần nâng cấp lên 7.0.2 [1]. Các phiên bản dưới 6.9.0 không bị ảnh hưởng bởi lỗ hổng này [1].

Tại sao wp2shell cần được đặc biệt quan tâm?

Trong vài năm qua, các vấn đề bảo mật của WordPress chủ yếu xoay quanh hệ sinh thái plugin — ví dụ như các lỗi SQL Injection hoặc XSS trong các plugin phổ biến có hàng triệu lượt tải xuống, những lỗi mà quản trị viên chỉ cần gỡ bỏ hoặc cập nhật plugin là có thể giải quyết được [1]. Tuy nhiên, wp2shell lại là một câu chuyện hoàn toàn khác [1].

Thứ nhất, lỗ hổng nằm trong WordPress Core. Điều này có nghĩa là bất kể bạn cài đặt plugin hay giao diện nào, mọi trang web chạy phiên bản WordPress nằm trong danh sách bị ảnh hưởng đều có nguy cơ bị tấn công [1].

Thứ hai, đây là lỗ hổng chưa qua xác thực (pre-authentication). Kẻ tấn công không cần tài khoản đăng nhập, cũng không cần sử dụng kỹ thuật xã hội (social engineering) hay lừa đảo (phishing) để chiếm quyền quản trị viên [1]. Chúng có thể nhắm trực tiếp vào trang web mục tiêu [1]. Một khi các phương thức tấn công không cần tương tác này được tự động hóa, việc quét hàng loạt và chiếm quyền kiểm soát website trên quy mô lớn chỉ còn là vấn đề thời gian [1].

Thứ ba, quy mô mục tiêu cực kỳ lớn. WordPress vận hành khoảng 43% thị phần CMS toàn cầu với hàng trăm triệu trang web đang hoạt động [1]. Ngay cả khi chúng ta giả định một cách thận trọng rằng chỉ có 10% số trang web này nằm trong dải phiên bản bị ảnh hưởng, số lượng mục tiêu bị đe dọa vẫn có thể lên tới hàng chục triệu [1].

Giải pháp khắc phục và giảm thiểu rủi ro toàn diện

How to Fix wp2shell

Giải pháp 1: Nâng cấp trực tiếp WordPress (Khuyến nghị)

Nâng cấp là cách hiệu quả nhất để giải quyết triệt để vấn đề này [1]. WordPress phiên bản 7.0.2 và 6.9.5 đã tích hợp sẵn các bản vá lỗi để xử lý lỗ hổng wp2shell [1].

Hãy truy cập vào Trang quản trị WordPress của bạn → Bảng tin → Cập nhật, kiểm tra phiên bản hiện tại và tiến hành cập nhật [1]. Nếu trang web của bạn đã bật tính năng tự động cập nhật, bạn vẫn nên đăng nhập để xác nhận xem bản vá đã được áp dụng thành công hay chưa [1].

Giải pháp 2: Cài đặt plugin "Disable WP REST API"

Nếu chưa thể nâng cấp ngay lập tức do cần kiểm tra tính tương thích hoặc các rào cản khác, bạn có thể tạm thời cài đặt plugin "Disable WP REST API" [1]. Plugin này sẽ ngăn chặn những người dùng chưa xác thực truy cập vào WordPress REST API, qua đó chặn đứng đường tấn công của lỗ hổng wp2shell [1].

Lưu ý rằng việc này có thể gây ảnh hưởng đến một số tính năng của trang web phụ thuộc vào REST API (như các framework dựng giao diện frontend, cấu trúc headless WordPress hoặc các tích hợp của bên thứ ba) [1]. Hãy tiến hành kiểm tra lại toàn bộ chức năng sau khi kích hoạt [1].

Giải pháp 3: Chặn các đường dẫn cụ thể bằng WAF (Tường lửa ứng dụng Web)

Nếu trang web của bạn nằm sau một Tường lửa ứng dụng Web (WAF), bạn có thể thiết lập các quy tắc để chặn hai mẫu yêu cầu (request patterns) sau [1]:

Chặn đường dẫn URL:

/wp-json/batch/v1

Chặn tham số truy vấn:

rest_route=/batch/v1

Cả hai quy tắc này phải được cấu hình đồng thời [1]. Chỉ chặn một trong hai là chưa đủ, bởi vì WordPress REST API hỗ trợ truy cập vào cùng một điểm cuối (endpoint) thông qua cả đường dẫn URL lẫn tham số truy vấn [1].

Đối với Nginx, bạn có thể thêm đoạn mã sau vào khối cấu hình server:

# Chặn đường dẫn batch API liên quan đến lỗ hổng wp2shell
location ~* /wp-json/batch/v1 {
    deny all;
    return 403;
}

# Chặn các yêu cầu truy cập batch API qua tham số truy vấn
if ($query_string ~* "rest_route=/batch/v1") {
    return 403;
}

Đối với Apache (đã bật mod_rewrite), bạn có thể thêm đoạn cấu hình này vào tệp .htaccess:

# Chặn các yêu cầu đường dẫn batch API
RewriteEngine On
RewriteRule ^wp-json/batch/v1 - [F,L]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1 [NC]
RewriteRule .* - [F,L]

Giải pháp 4: Triển khai một plugin bảo mật tự tùy biến (Khuyến nghị chính thức)

Searchlight Cyber đã cung cấp một đoạn mã nguồn plugin WordPress ngắn có thể triển khai trực tiếp làm bản vá khẩn cấp [1]. Đoạn mã này sẽ chặn và từ chối tất cả các yêu cầu chưa qua xác thực gửi đến endpoint /batch/v1, trong khi những người dùng đã đăng nhập vẫn hoạt động bình thường [1].

Hãy lưu đoạn mã sau thành tệp disable-batch-api-for-unauth.php, tải lên thư mục wp-content/plugins/ trên trang web WordPress của bạn thông qua SSH hoặc FTP, sau đó kích hoạt nó trong trang quản lý Plugin [1].

<?php
/**
 * Plugin Name: Disable Unauthenticated REST Batch API
 * Description: Requires an authenticated WordPress user for REST batch requests.
 * Version: 1.0.0
 * Requires at least: 5.6
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Reject anonymous requests to the core REST batch endpoint.
 *
 * @param mixed           $result  Pre-calculated dispatch result.
 * @param WP_REST_Server  $server  REST server instance.
 * @param WP_REST_Request $request Current REST request.
 * @return mixed|WP_Error
 */
function wporg_require_authentication_for_rest_batch( $result, $server, $request ) {
    $route = untrailingslashit( $request->get_route() );

    if ( '/batch/v1' !== $route || is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error(
        'rest_batch_authentication_required',
        'Authentication is required to use the batch API.',
        array( 'status' => 401 )
    );
}

add_filter( 'rest_pre_dispatch', 'wporg_require_authentication_for_rest_batch', -1000, 3 );

Giải thích chi tiết đoạn mã:

rest_pre_dispatch là một filter hook được thực thi trước khi WordPress REST API điều phối (dispatch) yêu cầu [1]. Việc đặt mức độ ưu tiên của nó là -1000 đảm bảo bước kiểm tra bảo mật này sẽ chạy trước các bộ lọc khác [1].
untrailingslashit() loại bỏ các dấu gạch chéo ngược (/) ở cuối đường dẫn (route), giúp ngăn chặn các hành vi vượt qua bộ lọc do định dạng đường dẫn khác biệt [1].
Nếu route được yêu cầu khớp với /batch/v1 và người dùng chưa đăng nhập, hệ thống sẽ trả về trực tiếp một lỗi WP_Error kèm theo mã trạng thái HTTP là 401 [1].
Các quản trị viên hoặc biên tập viên đã xác thực vẫn có thể tiếp tục sử dụng batch API bình thường mà không gặp bất kỳ gián đoạn nào [1].

Plugin này chỉ đóng vai trò là một giải pháp vá lỗi khẩn cấp tạm thời [1]. Chúng tôi khuyến nghị bạn nên gỡ bỏ nó sau khi đã hoàn tất việc nâng cấp phiên bản WordPress [1].

Tìm hiểu về REST API Batch Endpoint

Được giới thiệu từ phiên bản WordPress 5.6, tính năng REST API batch (nằm tại /batch/v1) cho phép các máy khách gộp nhiều lượt gọi REST API vào trong một yêu cầu HTTP duy nhất [1]. Mục tiêu ban đầu là giảm số lượng kết nối mạng khứ hồi (network round-trips) và tối ưu hóa hiệu suất cho các trình soạn thảo frontend, chẳng hạn như Gutenberg block editor [1].

Mặc dù cơ chế này không tự nó mang lỗi bảo mật, việc xử lý các yêu cầu gộp (batch requests) phức tạp hơn rất nhiều so với việc xử lý các yêu cầu đơn lẻ, bao gồm kiểm tra xác thực, phân tích cú pháp yêu cầu và tổng hợp phản hồi [1]. Lỗ hổng wp2shell đã khai thác một điểm yếu nằm trong chính quy trình xử lý này để thực hiện hành vi thực thi mã từ xa [1].

Đối với những trang web không phụ thuộc vào batch API (chiếm phần lớn các thiết lập WordPress tiêu chuẩn), việc tạm thời vô hiệu hóa endpoint này để giảm thiểu rủi ro hầu như không gây ra bất kỳ sự cố chức năng nào [1].

Bảo mật môi trường phát triển cục bộ: Góc nhìn từ bản vá đến hạ tầng

AI Gateway Security

Sự cố wp2shell đã làm nổi bật một thực tế thường bị bỏ qua: vô số trang web WordPress đang chạy trên môi trường cục bộ (local environment) của các nhà phát triển để thử nghiệm và phân tích, và việc cập nhật bảo mật cho các bản cài đặt cục bộ này cũng quan trọng không kém gì trên môi trường production [1].

Đối với các nhà phát triển sử dụng các môi trường phát triển cục bộ tích hợp sẵn (chẳng hạn như ServBay, một nền tảng quản lý phát triển tích hợp công nghệ AI kết hợp cơ sở dữ liệu, các phiên bản PHP và các công cụ phát triển vào một gói cài đặt duy nhất) [1], việc quản lý phiên bản cài đặt WordPress thường được chuẩn hóa và đồng bộ hóa.

Các công cụ này mang lại lợi thế lớn khi xảy ra sự cố bảo mật: các quản trị viên có thể xem trực quan trạng thái phiên bản PHP và WordPress trên tất cả các trang web cục bộ từ một bảng điều khiển duy nhất và áp dụng cập nhật hàng loạt, thay vì phải đăng nhập thủ công vào từng trang web để nhấn cập nhật [1].

Nhìn rộng hơn, ngày có nhiều nhà phát triển dựa vào các trợ lý lập trình trí tuệ nhân tạo (như Claude Code, Cursor hoặc Codex) để hỗ trợ xây dựng và duy trì các trang web WordPress [1].

Trong quy trình làm việc này, việc bảo mật các khóa API (API keys) trở thành một yếu tố sống còn khác [1]. Các nhà phát triển thường để nhiều API key của dịch vụ AI rải rác trong các tệp cấu hình dự án khác nhau [1]. Nếu một trang web WordPress bị tấn công, kẻ gian xâm nhập vào hệ thống tệp có thể dễ dàng thu thập các khóa bảo mật được lưu dưới dạng văn bản thuần túy (plaintext) này [1].

What is AI Gateway

AI Gateway của ServBay được thiết kế để giải quyết điểm yếu bảo mật này [1]. Hệ thống tập trung và mã hóa tất cả các khóa API dịch vụ AI trong một cổng kết nối cục bộ bảo mật [1]. Các dự án và công cụ riêng lẻ sẽ thực hiện gọi API thông qua điểm truy cập thống nhất này, giúp giữ cho các khóa gốc không xuất hiện trong mã nguồn hoặc tệp cấu hình [1]. Công cụ này cũng cho phép các nhà phát triển tạo ra các khóa ảo (virtual keys) để tăng cường bảo mật [1].

Ngay cả khi một cài đặt WordPress bị xâm nhập, kẻ tấn công cũng không thể lấy được khóa dịch vụ AI gốc [1]. Việc chuyển dịch quản lý thông tin xác thực từ tầng ứng dụng xuống tầng hạ tầng sẽ giúp giảm thiểu tối đa phạm vi ảnh hưởng của bất kỳ vụ rò rỉ dữ liệu nào [1].

How to Use AI Gateway

Danh sách tự kiểm tra an ninh (Self-Audit Checklist)

Sau khi áp dụng giải pháp vá lỗi hoặc giảm thiểu rủi ro, bạn nên tiến hành một quy trình tự kiểm tra bảo mật toàn diện:

Xác minh phiên bản WordPress: Đăng nhập và kiểm tra số phiên bản ở góc dưới cùng bên phải của bảng điều khiển. Đảm bảo bạn đã nâng cấp lên phiên bản 6.9.5, 7.0.2 hoặc cao hơn [1].
Sử dụng công cụ kiểm tra: Truy cập công cụ quét trực tuyến wp2shell do Searchlight Cyber cung cấp để kiểm tra tên miền của bạn [1].
Kiểm tra danh sách người dùng: Truy cập mục Thành viên (Users) trên bảng điều khiển và xác minh xem có tài khoản quản trị viên trái phép nào được tạo ra hay không [1].
Kiểm tra các thay đổi tệp tin: Kiểm tra thư mục wp-content xem có xuất hiện tệp PHP nào mới được tạo hoặc sửa đổi đáng ngờ gần đây hay không [1].
Xem xét các tác vụ hẹn giờ: Kiểm tra hệ thống WP-Cron hoặc cron ở cấp độ máy chủ để phát hiện xem có tác vụ hẹn giờ bất thường hoặc trái phép nào được thêm vào không [1].
Kiểm tra nhật ký REST API: Nếu trang web của bạn có bật lưu lịch sử yêu cầu (logs), hãy kiểm tra kỹ để xem có bất kỳ yêu cầu bất thường nào gửi đến endpoint /batch/v1 hay không [1].

Kết luận

Lỗ hổng wp2shell là một trong những lỗ hổng nghiêm trọng nằm ngay trong phần mã nguồn cốt lõi của WordPress [1]. Nó không cần plugin đi kèm, không yêu cầu quyền xác thực, và phạm vi tấn công bao phủ tất cả các cấu hình cài đặt mặc định đang chạy các phiên bản bị ảnh hưởng [1]. Rất may mắn là đội ngũ cốt lõi của WordPress đã phản hồi nhanh chóng khi phát hành các phiên bản vá lỗi 6.9.5 và 7.0.2 [1].

Đối với quản trị viên trang web, việc nâng cấp ngay lập tức luôn là giải pháp tối ưu hàng đầu [1]. Nếu bạn chưa thể thực hiện cập nhật ngay, việc triển khai các quy tắc WAF hoặc cài đặt đoạn plugin tùy chỉnh được chia sẻ ở trên sẽ giúp ngăn chặn hoàn toàn đường hướng tấn công của kẻ gian [1].

Với các nhà phát triển đang quản lý nhiều bản cài đặt WordPress cục bộ, sự cố lần này là một lời nhắc nhở quan trọng: an toàn thông tin nội bộ không bao giờ được phép xem nhẹ [1]. Việc tin dùng các bộ quản lý môi trường tập trung và áp dụng các chiến lược quản lý thông tin xác thực đồng nhất sẽ cải thiện đáng kể tốc độ ứng phó sự cố và giúp quy trình làm việc của bạn luôn được bảo vệ an toàn [1].