
| Tên plugin | WpEvently |
|---|---|
| Loại lỗ hổng | Tấn công xuyên trang web (XSS) |
| Số CVE | CVE-2026-25361 |
| Tính cấp bách | Trung bình |
| Ngày xuất bản CVE | 2026-03-22 |
| URL nguồn | CVE-2026-25361 |
Khẩn cấp: XSS phản chiếu trong WpEvently (≤ 5.1.4) — Những gì chủ sở hữu trang WordPress cần biết và làm hôm nay
Ngày: 20 tháng 3 năm 2026
Từ: Nhóm bảo mật WP‑Firewall
Bản tóm tắt
- Chuyện gì đã xảy ra thế: Một lỗ hổng Cross‑Site Scripting (XSS) phản chiếu đã được công bố trong plugin WordPress WpEvently ảnh hưởng đến các phiên bản ≤ 5.1.4 (CVE‑2026‑25361). Một bản phát hành đã được vá có sẵn trong phiên bản 5.1.5.
- Mức độ rủi ro: Trung bình (CVSS ~7.1). Lỗ hổng này cho phép kẻ tấn công chèn JavaScript vào các phản hồi được phản chiếu đến người dùng hoặc quản trị viên, có thể dẫn đến việc đánh cắp phiên, hành động trái phép hoặc phát tán phần mềm độc hại.
- Hành động ngay lập tức: Cập nhật WpEvently lên phiên bản 5.1.5 hoặc mới hơn. Nếu bạn không thể cập nhật ngay lập tức, hãy áp dụng các biện pháp giảm thiểu tạm thời (vá ảo qua WAF, vô hiệu hóa chức năng bị ảnh hưởng hoặc hạn chế quyền truy cập).
- WP‑Firewall có thể giúp: Chúng tôi cung cấp các quy tắc WAF được quản lý, vá ảo, giám sát liên tục và quét để chặn các nỗ lực khai thác đã biết và giảm thiểu rủi ro trong khi bạn lên lịch cập nhật.
Thông báo này giải thích về lỗ hổng, cho thấy các kịch bản tấn công thực tế, cung cấp hướng dẫn giảm thiểu và phát hiện từng bước, và cung cấp lời khuyên tăng cường thực tiễn cho cả chủ sở hữu trang và nhà phát triển.
XSS phản chiếu là gì và tại sao điều này quan trọng đối với các trang WordPress
Cross‑Site Scripting (XSS) là một loại lỗ hổng mà trong đó một ứng dụng bao gồm đầu vào do người dùng cung cấp trong một trang web mà không có xác thực hoặc mã hóa thích hợp, cho phép kẻ tấn công chèn các tập lệnh phía khách. XSS phản chiếu xảy ra khi tải trọng là một phần của yêu cầu HTTP (ví dụ, trong tham số URL hoặc đầu vào biểu mẫu) và máy chủ phản chiếu lại trong phản hồi.
Trên các trang WordPress, XSS có thể gây hại đặc biệt vì:
- Người dùng quản trị truy cập một URL được tạo hoặc nhấp vào một liên kết độc hại có thể bị đánh cắp phiên hoặc thông tin xác thực bị lộ.
- Kẻ tấn công có thể cài đặt các tập lệnh thực hiện các hành động trái phép thay mặt cho quản trị viên (tạo người dùng, thay đổi tùy chọn, chèn nội dung độc hại).
- Kẻ tấn công có thể sử dụng XSS để phát tán phần mềm độc hại cho khách truy cập hoặc để thiết lập sự tồn tại bằng cách sửa đổi các tệp plugin/theme hoặc tạo tài khoản backdoor.
Các lỗ hổng XSS phản chiếu thường được sử dụng trong các chiến dịch lừa đảo hàng loạt và khai thác tự động vì chúng có thể được kích hoạt thông qua một liên kết được tạo.
Lỗ hổng WpEvently (mức độ cao)
- Phần mềm bị ảnh hưởng: Plugin WpEvently WordPress (plugin quản lý sự kiện)
- Các phiên bản dễ bị tấn công: ≤ 5.1.4
- Đã vá trong: 5.1.5
- Loại lỗ hổng: Tấn công Cross-Site Scripting (XSS) phản chiếu
- CVE: CVE‑2026‑25361
- Quyền yêu cầu: Không xác thực — một kẻ tấn công không xác thực có thể tạo một liên kết để kích hoạt phản chiếu. Việc khai thác thành công thường yêu cầu một người dùng (thường có quyền cao hơn) nhấp vào hoặc truy cập vào liên kết được tạo.
Tóm lại: một kẻ tấn công có thể tạo ra một URL bao gồm một tham số được định dạng đặc biệt. Nếu một quản trị viên hoặc người dùng có quyền truy cập nhấp vào liên kết đó, JavaScript độc hại có thể được thực thi trong ngữ cảnh trình duyệt của họ.
Các kịch bản khai thác điển hình (cách mà kẻ tấn công có thể lạm dụng điều này)
- Lừa đảo hoặc liên kết nhắm mục tiêu: Kẻ tấn công gửi một email hoặc tin nhắn trò chuyện với một URL được tạo đặc biệt đến một quản trị viên. Nếu quản trị viên đã đăng nhập và truy cập URL, kịch bản sẽ chạy trong phiên của quản trị viên.
- Lưu trữ/Chuỗi proxy: Trong các trường hợp mà XSS phản chiếu có thể được chuỗi với các chức năng plugin khác, kẻ tấn công có thể kết hợp nhiều lỗ hổng để đạt được tính bền vững.
- SEO hoặc trang công khai: Nếu điểm cuối dễ bị tổn thương có thể được truy cập bởi những khách truy cập không xác thực, kẻ tấn công có thể phân phối liên kết rộng rãi để lây nhiễm khách truy cập hoặc chuyển hướng họ đến các trang web độc hại.
Tác động tiềm ẩn:
- Đánh cắp cookie phiên (nếu cookie không được đánh dấu HttpOnly)
- Thực hiện các hành động có quyền hạn (tạo người dùng, thay đổi cài đặt trang)
- Tiêm phần mềm độc hại bền vững hoặc làm hỏng
- Chuyển hướng người dùng đến các trang web lừa đảo/phần mềm độc hại
- Chạy JavaScript tùy ý trong ngữ cảnh của khách truy cập trang web của bạn
Cách kiểm tra xem trang web của bạn có bị ảnh hưởng hay không
- Hàng tồn kho: Xác định xem WpEvently có được cài đặt hay không và kiểm tra phiên bản của nó.
- WP Dashboard → Plugins → tìm kiếm WpEvently
- Hoặc từ dòng lệnh:
wp plugin list | grep -i wpevently
- Kiểm tra phiên bản: Nếu phiên bản plugin là ≤ 5.1.4 bạn đang bị tổn thương. Nếu bạn đang ở phiên bản 5.1.5 hoặc mới hơn bạn đã được vá.
- Nhật ký máy chủ: Tìm kiếm các yêu cầu chứa các tham số truy vấn đáng ngờ, các đoạn mã dài, hoặc các tác nhân người dùng bất thường đến các điểm cuối do WpEvently cung cấp. Các chỉ số điển hình:
- Requests with encoded script tags (%3Cscript%3E or variations)
- Yêu cầu đến các điểm cuối liên quan đến sự kiện với các tham số đáng ngờ
- Quét trang: Chạy quét lỗ hổng với một trình quét uy tín hoặc sử dụng trình quét WP‑Firewall của chúng tôi để tìm các chữ ký XSS đã biết.
- Kiểm tra trực quan: Kiểm tra các bài viết gần đây, nội dung sự kiện, trang cài đặt plugin và mẫu plugin để tìm các thay đổi bất ngờ hoặc các script đã được chèn.
Nếu bạn tìm thấy bằng chứng về việc khai thác (người dùng quản trị bất ngờ, tệp đã bị sửa đổi, hoặc kết nối ra ngoài đến các miền không xác định), hãy coi trang web là bị xâm phạm và thực hiện ngay các bước phản ứng sự cố.
Các bước khắc phục ngay lập tức (danh sách kiểm tra cho chủ sở hữu trang web)
- Cập nhật WpEvently lên 5.1.5 hoặc phiên bản mới hơn
Đây là bản sửa lỗi cuối cùng. Sử dụng cập nhật WP admin hoặc chạycập nhật plugin wp wpeventlytừ WP‑CLI. - Nếu bạn không thể cập nhật ngay lập tức:
- Áp dụng một bản vá ảo (quy tắc WAF) để chặn các vector khai thác (xem các chữ ký WAF được đề xuất bên dưới).
- Hạn chế truy cập vào các trang admin của plugin bằng cách sử dụng danh sách cho phép IP hoặc xác thực cơ bản.
- Xóa hoặc chặn bất kỳ điểm cuối công khai nào do plugin cung cấp mà không cần thiết cho chức năng của trang web.
- Buộc xác thực lại cho tất cả các tài khoản quản trị để giảm thiểu rủi ro đánh cắp phiên:
Trong WordPress: Người dùng → Tất cả người dùng → Chỉnh sửa → Phiên → hủy tất cả các phiên (hoặc thay đổi mật khẩu). - Quét để tìm các chỉ số của sự xâm phạm:
- Kiểm tra
wp_người dùngcho các tài khoản bất ngờ. - Kiểm tra các thư mục tải lên, chủ đề và plugin để tìm các tệp đã được sửa đổi gần đây.
- Xem xét các tác vụ đã lên lịch (wp‑crons) và các tùy chọn cơ sở dữ liệu để tìm các mục đáng ngờ.
- Kiểm tra
- Dọn dẹp nếu bị xâm phạm:
- Khôi phục từ một bản sao lưu sạch nếu có sẵn.
- Thay thế các tệp bị xâm phạm bằng các phiên bản sạch và thay đổi tất cả các thông tin xác thực (WP admin, cơ sở dữ liệu, FTP/SFTP).
- Giám sát nhật ký và cảnh báo cho các nỗ lực tấn công vào các điểm cuối WpEvently.
Giải pháp WAF được khuyến nghị (vá ảo) — khái niệm và ví dụ
Nếu bạn không thể vá ngay lập tức, vá ảo thông qua Tường lửa Ứng dụng Web (WAF) là một biện pháp kiểm soát tạm thời hiệu quả. Dưới đây là các khái niệm quy tắc thực tiễn và ví dụ an toàn để triển khai trong WAF của bạn (thích ứng với cú pháp WAF của bạn — ModSecurity, nginx, bảng điều khiển WAF đám mây, v.v.).
Quan trọng: đây là các mẫu phòng thủ, không phải mã khai thác. Chúng nhằm mục đích chặn các nỗ lực khai thác có khả năng xảy ra mà không làm gián đoạn việc sử dụng hợp pháp.
Ví dụ về các khái niệm quy tắc kiểu ModSecurity (khái niệm — thích ứng cho sản phẩm của bạn):
- Chặn các yêu cầu có thẻ script trong các giá trị truy vấn:
- Nếu bất kỳ tham số truy vấn nào chứa “<script” hoặc “javascript:” (không phân biệt chữ hoa chữ thường) thì chặn hoặc thách thức.
- Chặn các tải trọng mã hóa nghi ngờ:
- Nếu các chuỗi mã hóa phần trăm giải mã thành “<script” hoặc “onerror=” hoặc “onload=” thì chặn.
- Chặn các giá trị tham số dài > N byte cho các tham số được mong đợi là ngắn.
- Chặn các tên tham số có vấn đề đã biết được sử dụng bởi plugin nếu chúng phản ánh dữ liệu một cách không an toàn.
Quy tắc khái niệm (mã giả):
nếu REQUEST_URI khớp với "/.*(wpevently|eventpress|event).*/i" thì
Nếu bạn sử dụng dịch vụ WP‑Firewall của chúng tôi, chúng tôi đã phát hành các quy tắc giảm thiểu nhắm mục tiêu cho các mẫu phản chiếu WpEvently để chặn các nỗ lực khai thác trong khi bạn cập nhật.
Ghi chú:
- Kiểm tra các quy tắc ở chế độ chặn/giám sát trước để tránh các cảnh báo sai.
- Sử dụng CAPTCHA/Thách thức thay vì chặn hoàn toàn cho các biểu mẫu công khai nếu cần.
Hướng dẫn cho nhà phát triển: cách sửa lỗi nguồn
Nếu bạn duy trì plugin hoặc là nhà phát triển tùy chỉnh nó, cách sửa lâu dài là đảm bảo mã hóa đầu ra và xác thực đầu vào bất cứ khi nào đầu vào của người dùng được phản ánh.
Các khuyến nghị chính cho nhà phát triển:
- Xác định các điểm cuối dễ bị tổn thương:
- Tìm nơi đầu vào của người dùng được phản hồi/hiển thị vào các phản hồi HTML mà không được thoát.
- Thoát đầu ra dựa trên ngữ cảnh:
- Trong nội dung phần tử HTML: sử dụng
esc_html() - Trong giá trị thuộc tính: sử dụng
esc_attr() - Trong JavaScript: sử dụng
wp_json_encode()để truyền giá trị vào các kịch bản một cách an toàn hoặc sử dụngesc_js()khi cần thiết - Trong URL: sử dụng
esc_url()
- Trong nội dung phần tử HTML: sử dụng
- Xác thực đầu vào phía máy chủ:
- Chấp nhận chỉ các giá trị mong đợi và làm sạch đầu vào sớm:
vệ sinh trường văn bản(),sanitize_email(),intval(), vân vân.
- Chấp nhận chỉ các giá trị mong đợi và làm sạch đầu vào sớm:
- Sử dụng kiểm tra nonce cho các hành động thay đổi trạng thái:
- Đảm bảo các biểu mẫu và hành động quản trị sử dụng
wp_create_nonce()và kiểm tra vớicheck_admin_referer().
- Đảm bảo các biểu mẫu và hành động quản trị sử dụng
- Tránh phản ánh đầu vào thô của người dùng trở lại trong các phản hồi; xem xét việc chuẩn hóa phía máy chủ hoặc các mẫu an toàn.
- Kiểm tra đơn vị và tích hợp:
- Thêm các bài kiểm tra cung cấp các tải trọng kiểu kẻ tấn công cho điểm cuối và xác nhận rằng chúng đã được mã hóa.
- Thư viện làm sạch:
- Khi cho phép HTML hạn chế, sử dụng
wp_kses()với một danh sách trắng an toàn.
- Khi cho phép HTML hạn chế, sử dụng
Một ví dụ cụ thể (mã giả) — hiển thị một tiêu đề do người dùng cung cấp một cách an toàn:
Xấu:
<?php'<h2>'echo '</h2>';
Tốt:
<?php'<h2>' . esc_html( sanitize_text_field( wp_unslash( $_GET['title'] ?? '' ) ) ) . '</h2>';
Luôn xác thực các mong đợi: nếu một tham số nên là ID số, hãy chuyển đổi và xác thực nó như một số nguyên.
Hành động sau khi vá: giám sát và xác minh
- Xác minh bản vá: Xác nhận rằng các tệp plugin đã được cập nhật và điểm cuối dễ bị tổn thương không còn phản ánh đầu vào chưa được thoát.
- Chạy lại quét: Sử dụng quét tự động để đảm bảo không còn tồn tại các vectơ XSS.
- Giám sát nhật ký web cho các nỗ lực khai thác lặp lại: kẻ tấn công thường quét web ngay cả khi các bản vá đã có sẵn.
- Lên lịch kiểm tra an ninh nội bộ: kiểm tra các plugin khác và giao diện cho các vấn đề mã hóa đầu ra tương tự.
Đối với các nhà cung cấp lưu trữ và WordPress được quản lý.
Nếu bạn điều hành dịch vụ lưu trữ hoặc dịch vụ WordPress được quản lý, ưu tiên các điều sau:
- Triển khai các bản vá ảo để chặn các mẫu khai thác đã biết trên toàn bộ hệ thống của bạn ngay lập tức.
- Đẩy cập nhật plugin hoặc thông báo cho khách hàng với hướng dẫn nâng cấp rõ ràng.
- Cung cấp cách ly tạm thời cho các trang web có dấu hiệu bị xâm phạm.
- Đề nghị thay đổi thông tin xác thực và phát hành lại các kiểm tra tăng cường an ninh cho các khách hàng bị ảnh hưởng.
Danh sách kiểm tra ứng phó sự cố (nếu bạn nghi ngờ có sự xâm phạm)
- Cách ly trang web (đưa vào chế độ bảo trì / gỡ bỏ trang khỏi DNS công cộng nếu nghiêm trọng).
- Thu thập nhật ký và bằng chứng (nhật ký truy cập, nhật ký PHP, bản sao cơ sở dữ liệu).
- Thay đổi thông tin xác thực (quản trị viên, FTP, cơ sở dữ liệu, khóa API).
- Quét và làm sạch thư mục gốc — thay thế các tệp plugin và giao diện bằng các bản sao đã biết là tốt.
- Khôi phục từ bản sao lưu sạch nếu có sẵn.
- Xem xét người dùng và các tác vụ đã lên lịch để tìm cửa hậu.
- Nếu cần, thông báo cho các bên liên quan và tuân theo chính sách thông báo vi phạm của bạn.
Chữ ký phát hiện thực tế (những gì cần theo dõi trong nhật ký)
- Các yêu cầu với chuỗi truy vấn chứa các thẻ script đã được mã hóa:
%3Cscript%3E,%3Cimg%20src%3Dx%20onerror%3D, vân vân. - Các yêu cầu đến các điểm cuối plugin với giá trị tham số dài hoặc ký tự không mong đợi.
- Sự gia tăng đột ngột của các yêu cầu đến các điểm cuối sự kiện hoặc lịch từ một IP hoặc một khối nhỏ các IP.
- Các yêu cầu POST chứa các thẻ script dự định hiển thị trên các trang quản trị.
Hãy cẩn thận: kẻ tấn công có thể làm mờ payload (mã hóa hex, mã hóa lồng nhau). Các quy tắc WAF nên giải mã các mã hóa khi đánh giá.
Câu hỏi thường gặp — câu trả lời nhanh
Hỏi: Liệu trang web của tôi có chắc chắn bị xâm phạm nếu tôi đã cài đặt WpEvently ≤ 5.1.4 không?
MỘT: Không nhất thiết. Lỗ hổng là một sự phơi bày — việc khai thác yêu cầu một người dùng (thường là quản trị viên) tương tác với một payload được tạo ra. Tuy nhiên, điều quan trọng là hành động nhanh chóng (cập nhật + quét) vì có các chiến dịch khai thác tự động tồn tại.
Hỏi: Tôi có thể vá qua WP‑CLI hay tôi cần sử dụng bảng điều khiển?
MỘT: Cả hai đều hợp lệ. WP‑CLI thường nhanh hơn và có thể lập trình: cập nhật plugin wp wpevently.
Hỏi: Việc vô hiệu hóa WpEvently có ngăn chặn các cuộc tấn công không?
MỘT: Việc vô hiệu hóa plugin thường sẽ loại bỏ điểm cuối dễ bị tổn thương. Nếu bạn phải, hãy vô hiệu hóa nó cho đến khi bạn có thể cập nhật. Hãy nhớ xem xét bất kỳ mục dư thừa nào mà plugin có thể đã tạo ra (mã ngắn, tùy chọn).
Hỏi: Thế nếu tôi dựa vào chức năng tùy chỉnh trong plugin và lo lắng về việc cập nhật sẽ làm hỏng trang web của tôi thì sao?
MỘT: Hãy thử cập nhật trên môi trường staging trước. Nếu không thể cập nhật ngay lập tức trên môi trường sản xuất, hãy sử dụng các quy tắc WAF và hạn chế truy cập vào các trang quản trị cho đến khi bạn có thể cập nhật một cách an toàn.
WP‑Firewall hỗ trợ bạn trong các sự cố như thế nào
Là đội ngũ WP‑Firewall, dịch vụ của chúng tôi được thiết kế để bảo vệ các trang WordPress trong thời gian công bố lỗ hổng và hoạt động đe dọa đang diễn ra:
- Các quy tắc WAF được quản lý và vá ảo: chặn các payload khai thác đã biết cho các lỗ hổng mới được công bố.
- Giảm thiểu không giám sát: trong khi bạn lên lịch và thử nghiệm cập nhật plugin, các bản vá ảo giảm bề mặt tấn công.
- Quét và loại bỏ phần mềm độc hại (có sẵn trên các gói trả phí): phát hiện và loại bỏ các script hoặc backdoor đã được chèn vào.
- Giám sát và cảnh báo: phát hiện theo thời gian thực các nỗ lực khai thác và hành vi đáng ngờ.
- Hướng dẫn bảo mật và hỗ trợ phản ứng sự cố từ các kỹ sư bảo mật WordPress có kinh nghiệm.
Chúng tôi tập trung vào việc giảm thiểu các cảnh báo sai trong khi đảm bảo bảo vệ nhanh chóng — được thiết kế để an toàn cho nhiều cấu hình WordPress khác nhau.
Bảo mật Trang Web của Bạn — Hãy thử Bảo vệ Miễn Phí của WP‑Firewall Ngày Hôm Nay
Chúng tôi tin rằng thực hành bảo mật tốt nhất là bảo vệ theo lớp: cập nhật kịp thời cộng với các biện pháp phòng ngừa chủ động. Nếu bạn muốn bảo vệ các trang web của mình trong khi cập nhật và củng cố, hãy xem xét gói miễn phí của chúng tôi.
Tại sao nên thử gói Cơ Bản (Miễn Phí) của chúng tôi?
- Bảo vệ thiết yếu: tường lửa quản lý chặn các cuộc tấn công phổ biến và OWASP Top 10.
- Băng thông không giới hạn: không có giới hạn lưu lượng khi bạn được bảo vệ.
- WAF và quét phần mềm độc hại: chặn các tải trọng đã biết và quét các tệp hoặc tiêm nghi ngờ.
Đăng ký gói miễn phí tại đây: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Nếu bạn cần tự động hóa và hỗ trợ thêm, các gói trả phí của chúng tôi thêm vào việc loại bỏ phần mềm độc hại tự động, kiểm soát danh sách đen/danh sách trắng, báo cáo bảo mật hàng tháng, vá ảo tự động và dịch vụ bảo mật chuyên dụng — nhưng gói miễn phí là một hàng rào phòng thủ tuyệt vời để giảm rủi ro ngay lập tức.
Danh sách kiểm tra tăng cường lâu dài cho các trang WordPress
- Giữ cho lõi, plugin và giao diện luôn được cập nhật. Ưu tiên các plugin có rủi ro cao.
- Sử dụng WAF quản lý với khả năng vá ảo.
- Giới hạn quyền truy cập quản trị viên theo IP khi có thể và thực thi xác thực 2 yếu tố mạnh mẽ.
- Sao lưu định kỳ được lưu trữ ngoài site; kiểm tra khôi phục.
- Sử dụng nguyên tắc quyền tối thiểu cho tài khoản người dùng.
- Củng cố quyền truy cập tệp và vô hiệu hóa chỉnh sửa tệp trong wp-admin (
định nghĩa('DISALLOW_FILE_EDIT', đúng);). - Quét bảo mật định kỳ và kiểm tra xâm nhập tập trung vào mã hóa đầu ra và mẫu.
- Đào tạo nhân viên nhận diện kỹ thuật xã hội có mục tiêu (vector phổ biến nhất cho việc khai thác XSS phản chiếu).
Khuyến nghị cuối cùng
- Nếu bạn đang chạy WpEvently, hãy nâng cấp lên 5.1.5 ngay bây giờ. Đây là bước quan trọng nhất.
- Nếu bạn không thể nâng cấp ngay lập tức, hãy bảo vệ trang web của bạn bằng WAF (vá ảo), hạn chế quyền truy cập quản trị viên và thực hiện quét bảo mật.
- Đối xử với XSS phản chiếu như bất kỳ lỗ hổng website nguy hiểm nào khác: kiểm tra nhật ký, thay đổi thông tin xác thực và xác minh tính toàn vẹn của trang web của bạn sau khi vá.
Chúng tôi sẵn sàng giúp bạn đánh giá mức độ tiếp xúc, áp dụng vá ảo và hướng dẫn phục hồi nếu bạn phát hiện dấu hiệu bị xâm phạm. Bảo mật không phải là một hành động — đó là một quá trình liên tục. Nếu bạn muốn được giúp đỡ trong việc triển khai các biện pháp bảo vệ và giám sát liên tục, đội ngũ của chúng tôi tại WP‑Firewall có thể hỗ trợ.
Nếu bạn có câu hỏi về các chi tiết kỹ thuật, cần giúp đỡ trong việc triển khai các biện pháp giảm thiểu WAF, hoặc muốn đội ngũ của chúng tôi quét trang web của bạn cho vấn đề cụ thể này — hãy liên hệ với hỗ trợ WP‑Firewall hoặc đăng ký gói miễn phí của chúng tôi để nhận được bảo vệ cơ bản ngay lập tức: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Hãy giữ an toàn,
Nhóm bảo mật WP‑Firewall
