
| Tên plugin | Vé Sự Kiện |
|---|---|
| Loại lỗ hổng | Bỏ qua kiểm soát truy cập |
| Số CVE | CVE-2026-42662 |
| Tính cấp bách | Cao |
| Ngày xuất bản CVE | 2026-05-04 |
| URL nguồn | CVE-2026-42662 |
Thông báo bảo mật khẩn cấp: Lỗ hổng vượt qua trong plugin Event Tickets (CVE-2026-42662)
Vào ngày 2 tháng 5 năm 2026, một lỗ hổng vượt qua ảnh hưởng đến plugin Event Tickets phổ biến (các phiên bản lên đến và bao gồm 5.27.5) đã được công bố và gán CVE-2026-42662. Lỗ hổng này được phân loại là vấn đề ưu tiên cao (CVSS 6.5) và có thể bị khai thác bởi các kẻ tấn công không xác thực. Nhà phát triển plugin đã phát hành phiên bản đã vá (5.27.6.1). Nếu trang web của bạn sử dụng Event Tickets, hãy coi đây là một nhiệm vụ bảo mật hoạt động khẩn cấp.
Trong bài viết này, được viết từ góc độ của các kỹ sư bảo mật WordPress tại WP‑Firewall, chúng tôi giải thích ý nghĩa của lỗ hổng, cách các kẻ tấn công có thể cố gắng khai thác nó, cách phát hiện dấu hiệu khai thác, và các bước khắc phục và giảm thiểu rõ ràng, thực tiễn mà bạn có thể áp dụng ngay lập tức — bao gồm vá ảo với tường lửa ứng dụng web (WAF), tăng cường thủ công, truy vấn phát hiện, và danh sách kiểm tra phản ứng sự cố.
Quan trọng: Nếu bạn lưu trữ các trang web của khách hàng hoặc quản lý nhiều cài đặt WordPress, hãy ưu tiên các bước này ngay lập tức. Lỗ hổng này là loại thường xuyên được khai thác trong các chiến dịch khai thác hàng loạt và các công cụ quét tự động.
Tóm tắt điều hành
- Một lỗ hổng vượt qua tồn tại trong các phiên bản plugin Event Tickets <= 5.27.5 (CVE-2026-42662).
- Các kẻ tấn công có thể kích hoạt một lỗ hổng vượt qua mà không cần xác thực, cho phép thực hiện các hành động mà plugin nên hạn chế.
- Bản vá có sẵn: cập nhật lên Event Tickets 5.27.6.1 hoặc phiên bản mới hơn.
- Giảm thiểu ngay lập tức nếu bạn không thể cập nhật: áp dụng vá ảo (quy tắc WAF), hạn chế truy cập vào các điểm cuối của plugin, và tăng cường giám sát và ghi log.
- WP‑Firewall cung cấp quy tắc WAF được quản lý và khả năng vá ảo để chặn các nỗ lực khai thác trong khi bạn lên lịch cập nhật.
“Lỗ hổng vượt qua” có nghĩa là gì trong bối cảnh này?
Một lỗ hổng vượt qua có nghĩa là một kẻ tấn công có thể vượt qua một hoặc nhiều hạn chế dự kiến trong phần mềm. Trong bối cảnh plugin WordPress, điều này thường bao gồm:
- Vượt qua kiểm tra xác thực hoặc khả năng (cho phép người dùng không xác thực thực hiện các hành động đặc quyền).
- Vượt qua xác thực đầu vào hoặc logic kinh doanh (khiến một plugin chấp nhận hoặc xử lý các yêu cầu mà lẽ ra nên bị từ chối).
- Bỏ qua kiểm tra nonce hoặc quyền trong các điểm cuối REST API, các trình xử lý AJAX, hoặc các chức năng xử lý biểu mẫu.
Đối với Event Tickets, thông báo đã công bố xác định vấn đề là một lỗ hổng vượt qua không xác thực, có nghĩa là một kẻ tấn công không cần phiên người dùng hợp lệ để kích hoạt hành vi gây vấn đề. Trong khi thông báo không công khai mã khai thác, các lỗ hổng vượt qua ở mức độ nghiêm trọng này thường được tích hợp vào các công cụ tấn công tự động quét web và cố gắng khai thác hàng nghìn trang web một cách nhanh chóng.
Các sự thật đã biết (những gì chúng tôi biết) biết)
- Phần mềm bị ảnh hưởng: plugin Event Tickets cho WordPress.
- Phiên bản dễ bị tổn thương: <= 5.27.5
- Đã được vá trong: 5.27.6.1
- ID CVE: CVE-2026-42662
- CVSS: 6.5 (Cao)
- Quyền hạn yêu cầu: Không xác thực (kẻ tấn công không cần đăng nhập)
- Phân loại: Bỏ qua / Thiết kế không an toàn (Danh mục OWASP A4)
- Ngày công bố: 2 tháng 5 năm 2026
Cách mà kẻ tấn công có thể khai thác lỗ hổng này
Trong khi chi tiết khai thác chính xác thường được công bố cho các nhà bảo vệ và nhà cung cấp trước, các vectơ khai thác sau đây là phổ biến cho các lỗ hổng bỏ qua trong các plugin WordPress:
- Các yêu cầu HTTP độc hại (GET/POST) được tạo ra cho các điểm cuối API REST của plugin hoặc các hành động admin-ajax mà bỏ qua các kiểm tra quyền hạn dự kiến.
- Các bot quét tự động tìm kiếm các mẫu URL cụ thể, tải trọng JSON, hoặc các tổ hợp tham số kích hoạt việc bỏ qua.
- Khai thác hàng loạt: một khi một nguyên tắc khai thác được biết đến, các kẻ tấn công sử dụng quét phân tán để tấn công các nhóm mục tiêu lớn.
- Chuyển tiếp: sau khi bỏ qua một hạn chế của plugin, các kẻ tấn công có thể tạo hoặc thao tác nội dung, nâng cao đến thực thi mã thông qua các lỗ hổng liên kết, hoặc thao tác dữ liệu liên quan đến thương mại (đơn hàng/ vé) để lừa đảo chủ sở hữu trang web.
Bởi vì lỗ hổng này có thể bị khai thác mà không cần thông tin xác thực, cửa sổ rủi ro là lớn. Các trang web phơi bày các điểm cuối REST và có Event Tickets hoạt động nên giả định bị phơi bày cho đến khi họ vá hoặc áp dụng các biện pháp giảm thiểu.
Hành động ngay lập tức (theo thứ tự)
- Xác minh phiên bản plugin ngay bây giờ.
Quản trị viên WordPress: Plugins > Plugins đã cài đặt > Event Tickets — kiểm tra phiên bản.
WP‑CLI (được khuyến nghị cho tự động hóa):wp plugin list --format=csv | grep -i event-tickets
- Nếu có thể, hãy cập nhật Event Tickets lên 5.27.6.1 hoặc phiên bản mới hơn ngay lập tức.
WP Admin: Plugins > Cập nhật có sẵn.
WP-CLI:wp plugin update event-tickets --version=5.27.6.1
Kiểm tra trang web trên môi trường staging trước khi triển khai hàng loạt nếu bạn quản lý nhiều trang web.
- 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 ảo. (Quy tắc WAF / chặn máy chủ web) — xem ví dụ quy tắc WAF bên dưới.
- Tăng cường ghi nhật ký và giám sát (bật ghi nhật ký yêu cầu, xem xét nhật ký truy cập và kiểm tra nhật ký cụ thể của plugin).
- Quét trang web để tìm các chỉ số của sự xâm phạm (IoCs) và dấu hiệu của hoạt động sau khai thác.
- Nếu bạn phát hiện sự xâm phạm đang hoạt động, hãy làm theo kế hoạch phản ứng sự cố của bạn. (được chứa trong bài viết này sau).
Vá ảo với WAF — cách nó giúp ích.
Nếu bạn không thể cập nhật ngay lập tức mọi trang bị ảnh hưởng, vá ảo là giải pháp tạm thời tốt nhất của bạn. Một bản vá ảo là một quy tắc WAF hoặc tương đương chặn các nỗ lực khai thác ở lớp web trước khi chúng đến mã PHP dễ bị tổn thương.
Những lợi ích:
- Bảo vệ ngay lập tức mà không cần sửa đổi plugin hoặc tệp lõi.
- Chặn các mẫu khai thác và tải trọng đã biết.
- Cho bạn thời gian để lên lịch và kiểm tra các bản cập nhật chính thức.
Những gì cần chặn:
- Các yêu cầu đến các điểm cuối cụ thể của plugin phù hợp với các mẫu khai thác (đường dẫn REST, hành động AJAX).
- Các yêu cầu HTTP với các kết hợp tham số nghi ngờ hoặc không khớp loại nội dung.
- Thăm dò tần suất cao và các tác nhân người dùng nghi ngờ.
Dưới đây là các mẫu quy tắc ví dụ. Điều chỉnh chúng cho sản phẩm WAF của bạn và kiểm tra trên môi trường staging trước khi đưa vào sản xuất.
Ví dụ quy tắc ModSecurity (chung) — chặn lưu lượng khai thác có khả năng xảy ra.
Ví dụ này chỉ mang tính minh họa. Điều chỉnh các mẫu cho nhật ký và môi trường của bạn.
# Chặn các mẫu khai thác sự kiện vé nghi ngờ đã biết (ví dụ)"
Tinh chỉnh các quy tắc để phù hợp với các tên tham số cụ thể hoặc các khóa JSON khi bạn có thêm chi tiết từ các thông báo của nhà cung cấp hoặc nhật ký của bạn.
Ví dụ đoạn mã Nginx (chặn các đường dẫn).
Nếu plugin tiết lộ một đường dẫn REST đã biết mà bạn muốn chặn tạm thời:
location ~* /wp-json/.*/(tickets|event-tickets|tribe).* {
Lưu ý: Chặn các đường dẫn REST có thể gây cản trở cho các plugin hoặc giao diện khác sử dụng hợp pháp các điểm cuối đó. Sử dụng cẩn thận và ghi lại các thay đổi.
Tăng cường tạm thời ở cấp độ WordPress (an toàn, có thể đảo ngược)
Nếu bạn không thể dựa vào WAF hoặc cần kiểm soát cục bộ, hãy sử dụng các hook của WordPress để vô hiệu hóa các điểm cuối REST của plugin hoặc lọc các yêu cầu.
Ví dụ: loại bỏ các điểm cuối REST mà plugin đăng ký (thực hiện điều này trong một mu-plugin hoặc plugin cụ thể cho trang):
<?php;
Ghi chú:
- Điều này loại bỏ các đường dẫn REST phù hợp với mẫu; hãy thận trọng với regex để tránh loại bỏ các đường dẫn không liên quan.
- Kiểm tra trên môi trường staging trước.
- Loại bỏ mã tạm thời này sau khi cập nhật plugin.
Một cách tiếp cận khác: chặn quyền truy cập không xác thực vào admin-ajax nếu bạn phát hiện nó bị lạm dụng bởi plugin. Không vô hiệu hóa admin-ajax toàn cầu vì nhiều plugin (và các tính năng frontend) có thể dựa vào nó.
Phát hiện: cách tìm kiếm dấu hiệu khai thác
Xem xét các nhật ký và thực hiện các kiểm tra có mục tiêu. Tập trung vào những chỉ số này:
- Các yêu cầu POST/GET không mong đợi đến các điểm cuối REST hoặc
admin-ajax.phpnơi yêu cầu là một IP không xác thực. - Vé, đơn hàng hoặc dữ liệu sự kiện mới hoặc đã sửa đổi ngoài giờ làm việc.
- Sự gia tăng đột ngột trong các yêu cầu đến các điểm cuối liên quan đến Vé Sự Kiện.
- Lỗi hoặc dấu vết ngăn xếp trong nhật ký lỗi PHP tham chiếu đến plugin.
- Các tệp mới được tạo trong thư mục uploads hoặc các sự kiện đã lên lịch mới được tạo lập trình.
Tìm kiếm nhật ký truy cập của bạn cho các yêu cầu trong 30 ngày qua phù hợp với các mẫu thăm dò khả thi:
# Ví dụ grep chống lại nhật ký truy cập:
Tìm kiếm các tác nhân người dùng bất thường hoặc các yêu cầu lặp lại từ cùng một dải IP.
Kiểm tra cơ sở dữ liệu:
- So sánh số lượng vé hoặc đơn hàng với các cơ sở lịch sử.
- Kiểm tra các tài khoản mới hoặc thay đổi nơi mà plugin có quyền hành động.
Ví dụ SQL để phát hiện các hàng đã được sửa đổi gần đây (điều chỉnh tên bảng theo sơ đồ của bạn):
SELECT post_id, post_title, post_modified, post_status;
Tệp:
- Sử dụng
tìmđể xác định các tệp đã được sửa đổi:
tìm wp-content/uploads -type f -mtime -7 -ls
Danh sách kiểm tra ứng phó sự cố (từng bước)
Nếu bạn phát hiện hoạt động đáng ngờ hoặc tin rằng một trang web đã bị khai thác, hãy làm theo trình tự này:
- Cách ly trang web:
Đặt trang web ở chế độ bảo trì hoặc hạn chế truy cập từ các IP đã biết.
Nếu là hosting chia sẻ, hãy liên hệ với nhà cung cấp của bạn để biết các tùy chọn cách ly. - Chụp ảnh & bảo tồn bằng chứng:
Tạo bản sao lưu đầy đủ: tệp, bản sao DB.
Bảo tồn nhật ký để phân tích pháp y. - Bao gồm:
Áp dụng bản vá ảo WAF và chặn các IP vi phạm.
Tạm thời vô hiệu hóa plugin dễ bị tổn thương nếu an toàn để làm như vậy. - Khảo sát:
Xem xét nhật ký, người dùng, tác vụ đã lên lịch (wp_cron) và các thay đổi gần đây.
Quét tìm webshell và các tệp không được phép (sử dụng các trình quét đáng tin cậy). - Diệt trừ:
Xóa các tệp độc hại, khôi phục các thay đổi DB không được phép nếu có thể.
Cài đặt lại plugin từ nguồn chính thức sau khi bản cập nhật có sẵn. - Hồi phục:
Khôi phục các bản sao lưu sạch nếu cần.
Thay đổi thông tin xác thực (DB, FTP, quản trị WordPress). - Sau sự cố:
Áp dụng các biện pháp tăng cường bổ sung (2FA, mật khẩu mạnh, quyền tối thiểu).
Ghi lại thời gian và bài học đã học.
Thông báo cho người dùng bị ảnh hưởng nếu tính toàn vẹn hoặc tính bảo mật dữ liệu bị ảnh hưởng.
Nếu trang web đang dưới hợp đồng bảo mật hoặc bảo trì được quản lý, hãy nâng cao theo SLA của bạn.
Củng cố lâu dài hơn để giảm thiểu các rủi ro tương tự
- Giữ cho các plugin và chủ đề được cập nhật kịp thời.
- Đăng ký nhận thông báo về lỗ hổng cho các plugin bạn sử dụng.
- Sử dụng WAF với khả năng vá ảo để giảm thiểu các lỗ hổng zero-day và đã được công bố giữa việc phát hiện và vá.
- Giảm bề mặt tấn công:
- Vô hiệu hóa hoặc xóa các plugin không sử dụng.
- Giới hạn các điểm cuối REST công khai khi có thể.
- Áp dụng nguyên tắc quyền tối thiểu cho các vai trò người dùng.
- Bật giám sát tính toàn vẹn tệp và quét phần mềm độc hại theo lịch trình.
- Triển khai sao lưu tự động với lưu trữ ngoài.
- Sử dụng giới hạn tỷ lệ trên các điểm cuối nhạy cảm và chặn các tác nhân người dùng độc hại phổ biến.
Ví dụ về chữ ký phát hiện WAF và ghi chú điều chỉnh
Khi điều chỉnh quy tắc, cân bằng giữa các dương tính giả và bảo vệ. Bắt đầu với các mẫu phát hiện bảo thủ và lặp lại.
- Chặn các yêu cầu chứa payload JSON không hợp lệ khi một
ticket_idhoặchoạt độngtham số có mặt trong ngữ cảnh không xác thực. - Đánh dấu chuỗi yêu cầu nhanh từ một IP duy nhất đến các điểm cuối liên quan đến vé; áp dụng chặn tạm thời (ví dụ: 5 phút).
- Tạo một chữ ký phát hiện các cuộc thăm dò bao gồm tên chức năng plugin đã biết hoặc tên tham số (từ các thông báo công khai) được sử dụng trong khai thác.
Ghi nhật ký: Đảm bảo rằng nhật ký WAF ghi lại đầy đủ ngữ cảnh yêu cầu (URI, tiêu đề, nội dung) cho các sự kiện khớp để các nhà phân tích có thể phân loại nhanh chóng.
Các bước cập nhật thực tế cho các cơ quan và quản lý trang web
Nếu bạn quản lý nhiều trang web, hãy áp dụng kế hoạch triển khai này:
- Kiểm kê: tạo danh sách các cài đặt có Event Tickets được cài đặt và các phiên bản của chúng.
WP‑CLI trên các máy chủ:wp plugin list --path=/path/to/site | grep 'event-tickets' - Cập nhật môi trường staging có rủi ro thấp trước, sau đó là sản xuất theo từng đợt.
- Bật cập nhật plugin tự động chỉ cho các bản vá bảo mật quan trọng (nếu chính sách quản lý của bạn cho phép).
- Đối với các khách hàng không thể cập nhật ngay lập tức, hãy bật một bộ quy tắc WAF tạm thời cho mỗi trang và lên lịch cập nhật.
Tại sao bạn nên xem xét việc vá lỗi ảo dựa trên WAF như một phần của chiến lược phòng thủ sâu.
- Các bản vá cần thử nghiệm và lên lịch; vá lỗi ảo mua thêm thời gian.
- Kẻ tấn công thường khai thác các lỗ hổng trong vòng vài giờ/ngày sau khi công bố.
- Dịch vụ WAF được quản lý có thể đẩy các biện pháp giảm thiểu tập trung nhanh chóng trên tất cả các trang của bạn.
- Các quy tắc WAF cũng có thể giảm tiếng ồn và quét tự động, cải thiện tỷ lệ tín hiệu trên tiếng ồn trong giám sát.
WP‑Firewall cung cấp các quy tắc WAF được quản lý phù hợp với các thông báo plugin WordPress và tự động hóa việc vá lỗi ảo cho các mẫu khai thác đã biết để bạn có thể tập trung vào việc triển khai bản vá có kiểm soát.
Mẫu thông báo cho khách hàng hoặc các bên liên quan.
Sử dụng một thông điệp ngắn để thông báo cho các bên liên quan về lỗ hổng và các hành động đã thực hiện:
Chủ thể: Thông báo bảo mật — Lỗ hổng plugin Event Tickets (cần hành động).
Thông điệp:
- Một lỗ hổng bảo mật ưu tiên cao (CVE-2026-42662) ảnh hưởng đến Event Tickets <=5.27.5 đã được công bố vào ngày 2 tháng 5 năm 2026. Vấn đề cho phép bỏ qua các hạn chế trong plugin mà không cần xác thực.
- Chúng tôi đã xác minh [danh sách của bạn/trang của bạn] và đã thực hiện các bước sau: áp dụng biện pháp giảm thiểu WAF và lên lịch cập nhật plugin lên 5.27.6.1. Nếu bạn quản lý các trang, vui lòng cập nhật plugin ngay lập tức hoặc liên hệ với chúng tôi để được hỗ trợ.
- Nếu bạn nhận thấy hoạt động bất thường (đơn hàng/ vé, tài khoản mới hoặc lỗi trang), hãy thông báo cho chúng tôi ngay lập tức.
Những câu hỏi thường gặp
H: Nếu tôi cập nhật plugin, tôi có còn cần WAF không?
A: Có. Một plugin được cập nhật giảm bề mặt tấn công, nhưng một WAF thêm một lớp bảo vệ khác chống lại các lỗ hổng plugin khác và các cuộc tấn công web phổ biến (SQLi, XSS, v.v.).
Q: Trang của tôi sử dụng tích hợp tùy chỉnh với Event Tickets — liệu bản vá có làm hỏng nó không?
A: Các bản vá của nhà cung cấp thường duy trì các API công khai, nhưng luôn thử nghiệm trong môi trường staging trước. Nếu bạn có một tích hợp tùy chỉnh, hãy thực hiện kiểm tra chức năng sau khi cập nhật.
Q: Tôi có thể tắt plugin một cách an toàn thay vì cập nhật không?
A: Tắt plugin sẽ loại bỏ bề mặt tấn công nhưng có thể làm hỏng chức năng của trang (sự kiện/bán vé). Nếu bạn không thể cập nhật nhanh chóng và cần các tính năng của plugin, hãy áp dụng vá lỗi ảo WAF cho đến khi bạn có thể cập nhật.
Cách WP‑Firewall bảo vệ các trang WordPress của bạn.
Tại WP‑Firewall, chúng tôi áp dụng cách tiếp cận theo lớp:
- Quy tắc WAF thời gian thực và vá ảo để chặn các nỗ lực khai thác cho các lỗ hổng đã được công bố.
- Quét và loại bỏ phần mềm độc hại cho các tệp bị xâm phạm.
- Giám sát lỗ hổng liên tục và thông tin tình báo về mối đe dọa được ưu tiên để bạn có thể hành động nhanh chóng.
- Các tùy chọn khắc phục tự động và thủ công tùy thuộc vào kế hoạch của bạn.
Chúng tôi cũng cung cấp hướng dẫn và hỗ trợ tùy chỉnh cho việc cập nhật plugin và thực hiện phản ứng sự cố khi có nghi ngờ về khai thác.
Danh sách kiểm tra được khuyến nghị (sao chép-dán cho các nhóm vận hành)
- Kiểm kê các trang WordPress và xác nhận phiên bản Event Tickets cho mỗi trang.
- Vá Event Tickets lên 5.27.6.1 trên môi trường staging và sau đó là production.
- Nếu việc vá ngay lập tức không khả thi, hãy kích hoạt các quy tắc vá ảo WAF cho các trang web.
- Tăng cường ghi lại yêu cầu cho các điểm cuối REST và admin-ajax trong 14 ngày.
- Quét các tệp bị xâm phạm, nội dung vừa được sửa đổi và các thay đổi cơ sở dữ liệu bất thường.
- Thay đổi mật khẩu quản trị và khóa API nếu nghi ngờ bị xâm phạm.
- Tài liệu khắc phục và theo dõi với giao tiếp với các bên liên quan.
Đăng ký WP‑Firewall (miễn phí) — Bảo vệ trang web của bạn ngay lập tức
Tiêu đề: Bảo mật trang WordPress của bạn ngay bây giờ với kế hoạch tường lửa quản lý miễn phí
Nếu bạn chịu trách nhiệm cho một hoặc nhiều trang WordPress và muốn có một lớp bảo vệ ngay lập tức trong khi bạn lên kế hoạch cập nhật, hãy thử kế hoạch WP‑Firewall Basic (Miễn phí). Nó bao gồm bảo vệ tường lửa quản lý thiết yếu, băng thông không giới hạn, tường lửa ứng dụng web (WAF), quét phần mềm độc hại tự động và giảm thiểu các rủi ro OWASP Top 10 — tất cả đều được thiết kế để ngăn chặn các nỗ lực khai thác như việc bỏ qua Event Tickets trong khi bạn cập nhật plugin và áp dụng các biện pháp bảo vệ lâu dài hơn.
Tìm hiểu thêm và đăng ký kế hoạch miễn phí tại đây: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Khuyến nghị cuối cùng — những gì cần làm ngay bây giờ
- Kiểm tra xem Event Tickets có được cài đặt trên bất kỳ trang nào của bạn không.
- Nếu có, hãy cập nhật lên 5.27.6.1 ngay lập tức (hoặc áp dụng các biện pháp giảm thiểu WAF ở trên).
- Lên lịch kiểm tra chức năng sau khi cập nhật cho quy trình làm vé và sự kiện.
- Tăng cường ghi lại và giám sát ít nhất hai tuần sau khi cập nhật để phát hiện bất kỳ kẻ tấn công nào di chuyển muộn.
- Nếu bạn phát hiện bất kỳ điều gì đáng ngờ, hãy làm theo danh sách kiểm tra phản ứng sự cố, bảo tồn chứng cứ và xem xét việc thuê một nhà cung cấp bảo mật để phân tích pháp y sâu hơn.
Nếu bạn cần hỗ trợ đánh giá mức độ tiếp xúc trên nhiều trang web, tạo các quy tắc WAF phù hợp với môi trường của bạn, hoặc thực hiện các bản cập nhật an toàn, đội ngũ WP‑Firewall sẵn sàng giúp đỡ. Bảo mật các trang web của bạn ngay bây giờ — một vài bước phòng ngừa hôm nay có thể tiết kiệm thời gian và chi phí đáng kể từ các trang web bị xâm phạm sau này.
Hãy giữ an toàn,
Nhóm bảo mật WP‑Firewall
