| Tên plugin | Loobek |
|---|---|
| Loại lỗ hổng | Tấn công xuyên trang web (XSS) |
| Số CVE | CVE-2026-25349 |
| Tính cấp bách | Trung bình |
| Ngày xuất bản CVE | 2026-03-22 |
| URL nguồn | CVE-2026-25349 |
Bản tóm tắt
Một lỗ hổng Cross‑Site Scripting (XSS) phản chiếu ảnh hưởng đến giao diện Loobek WordPress trước phiên bản 1.5.2 (CVE‑2026‑25349) đã được công bố. Vấn đề cho phép một kẻ tấn công không xác thực tạo ra một liên kết hoặc một biểu mẫu mà khi người dùng (thường là quản trị viên hoặc người dùng có quyền) nhấp vào, sẽ khiến trình duyệt thực thi JavaScript do kẻ tấn công kiểm soát. Nhà cung cấp đã phát hành v1.5.2 để giải quyết vấn đề này. Bài viết này giải thích về rủi ro, cách khai thác trông như thế nào trong thực tế (mức độ cao), các kỹ thuật phát hiện, các biện pháp giảm thiểu ngay lập tức bao gồm vá ảo thông qua các quy tắc WAF, và hướng dẫn phục hồi / tăng cường lâu dài từ góc độ WP‑Firewall.
Tại sao điều này quan trọng
XSS phản chiếu vẫn là một trong những lỗ hổng web bị lạm dụng phổ biến nhất. Ngay cả khi một trang web hoặc giao diện không nổi bật, các công cụ quét tự động và các chiến dịch lừa đảo hàng loạt có thể biến một XSS phản chiếu thành một vectơ xâm nhập hoàn chỉnh—đặc biệt nếu tải trọng nhắm vào người dùng quản trị (đăng nhập bảng điều khiển) hoặc tận dụng cookie / phiên trình duyệt.
Mặc dù lỗi giao diện Loobek này được phân loại là “phản chiếu” (có nghĩa là tải trọng được phản chiếu trong phản hồi và không được lưu trữ), nhưng hậu quả có thể rất nghiêm trọng:
- Đánh cắp phiên / chiếm đoạt tài khoản cho quản trị viên và người dùng có quyền (nếu cookie / mã thông báo xác thực có thể truy cập).
- Chuỗi chuyển hướng liên tục đến các trang lừa đảo hoặc phân phối phần mềm độc hại.
- Tiêm nội dung không mong muốn có thể làm hỏng SEO và danh tiếng.
- Sử dụng trong các cuộc tấn công chuỗi (XSS → CSRF → leo thang quyền hạn).
Lỗ hổng này được đánh giá với CVSS là 7.1 và được gán CVE‑2026‑25349. Nó ảnh hưởng đến các phiên bản Loobek trước 1.5.2. Nhà cung cấp đã phát hành 1.5.2 để vá vấn đề này.
Một XSS phản chiếu trông như thế nào (mức độ cao, mô tả an toàn)
Trong một XSS phản chiếu, đầu vào của người dùng được cung cấp trong các tham số yêu cầu HTTP được đưa vào phản hồi trang mà không có mã hóa hoặc làm sạch thích hợp. Một kẻ tấn công xây dựng một URL (ví dụ, bao gồm một chuỗi truy vấn được tạo ra) và dụ một nạn nhân nhấp vào nó. Trang sẽ hiển thị JS của kẻ tấn công, thực thi bên 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.
Chúng tôi sẽ không công bố một bằng chứng khái niệm (PoC) hoặc tải trọng khai thác ở đây. Thay vào đó, hãy tập trung vào việc khắc phục và giảm thiểu rủi ro vì việc công bố các khai thác hoạt động có thể tăng tốc độ khai thác hàng loạt có hại.
Ai bị ảnh hưởng?
- Các trang sử dụng giao diện Loobek với các phiên bản cũ hơn 1.5.2.
- Các trang mà người dùng có quyền (quản trị viên, biên tập viên) có thể bị lừa nhấp vào các liên kết — điều này phổ biến đối với các trang được quản lý bởi các nhóm nhỏ hoặc các cơ quan.
- Bất kỳ trang nào mà các điểm cuối giao diện phản hồi dữ liệu yêu cầu mà không có mã hóa thích hợp.
Nếu bạn đang chạy Loobek và không thể cập nhật ngay lập tức (tùy chỉnh, yêu cầu staging, hoặc lo ngại về khả năng tương thích), bạn nên áp dụng các biện pháp giảm thiểu được mô tả bên dưới.
Các hành động ngay lập tức mà mọi chủ sở hữu trang web nên thực hiện
- Cập nhật giao diện lên 1.5.2 hoặc mới hơn càng sớm càng tốt. Đây là cách sửa chữa vĩnh viễn duy nhất. Kiểm tra các bản cập nhật trong môi trường staging nếu cần, sau đó áp dụng trên môi trường sản xuất.
- Nếu bạn không thể cập nhật ngay lập tức:
- Đưa trang web vào chế độ bảo trì trong khi bạn chuẩn bị các bản cập nhật (nếu điều này khả thi).
- Áp dụng WAF / bản vá ảo để chặn các yêu cầu độc hại (các ví dụ bên dưới).
- Giới hạn quyền truy cập quản trị: hạn chế bảng điều khiển chỉ cho các dải IP đáng tin cậy khi có thể.
- Thay đổi thông tin đăng nhập và vô hiệu hóa các phiên hoạt động cho các tài khoản có quyền cao nếu bạn nghi ngờ có hoạt động quản trị đáng ngờ xảy ra.
- Quét trang web để tìm dấu hiệu bị xâm phạm (web shells, mã tiêm, thay đổi nội dung) và xem xét nhật ký máy chủ để tìm các tham số đáng ngờ hoặc bất thường.
Phát hiện và chỉ báo khai thác
Tìm kiếm các tín hiệu sau trong nhật ký và trên trang:
- Các yêu cầu chứa chuỗi truy vấn bất thường với mã hóa hoặc đoạn mã JavaScript không mong đợi.
- Thay đổi đột ngột hoặc bổ sung vào HTML phía trước (ví dụ: mới
7.thẻ hoặc mã inline không do chủ đề/plugin của bạn viết). - Các nỗ lực đăng nhập từ các IP hoặc tác nhân người dùng không điển hình cho các quản trị viên của bạn.
- Tăng đột biến trong các yêu cầu ra ngoài từ máy chủ đến các điểm đến không xác định (có thể chỉ ra việc khai thác sau).
- Báo cáo từ người dùng về việc chuyển hướng hoặc popup khi họ nhấp vào các liên kết chia sẻ cụ thể.
Tìm kiếm trong nhật ký của bạn các yêu cầu đến các điểm cuối của chủ đề với các mẫu tải trọng đáng ngờ (ký tự mã hóa phần trăm, từ khóa đáng ngờ). Sử dụng bảng điều khiển hosting của bạn hoặc nhật ký WP-Firewall để lọc theo URI yêu cầu và chuỗi truy vấn.
Danh sách kiểm tra phân loại an toàn (người dùng không kỹ thuật)
- Cập nhật Loobek lên 1.5.2. Nếu bạn không thể, hãy yêu cầu nhà phát triển hoặc nhà cung cấp dịch vụ của bạn làm điều đó cho bạn.
- Buộc đăng xuất tất cả người dùng và yêu cầu đặt lại mật khẩu cho các tài khoản quản trị hoặc biên tập viên.
- Chạy quét toàn bộ trang web với trình quét bảo mật của bạn và xem xét bất kỳ cảnh báo nào.
- Nếu bạn thấy các tệp hoặc nội dung độc hại, hãy đưa trang web ngoại tuyến và liên hệ với nhà cung cấp phản ứng sự cố chuyên nghiệp, hoặc làm theo các bước phục hồi bên dưới.
Cách WP‑Firewall bảo vệ bạn (tổng quan kỹ thuật)
Tại WP-Firewall, chúng tôi tiếp cận các rủi ro XSS phản chiếu ở hai cấp độ:
- Ngăn chặn theo mặc định — bộ quy tắc tường lửa được quản lý của chúng tôi chặn các mẫu tiêm XSS phổ biến ở rìa, trước khi chúng đến WordPress. Điều này bao gồm việc phát hiện tải trọng mã trong chuỗi truy vấn, tham số đường dẫn và đầu vào biểu mẫu, cũng như chặn các mã hóa đáng ngờ và kỹ thuật làm mờ tải trọng.
- Váo váy ảo — khi một lỗ hổng của chủ đề hoặc plugin được công bố, đội ngũ của chúng tôi tạo ra các quy tắc nhắm mục tiêu để chặn và trung hòa các nỗ lực khai thác cho điểm yếu cụ thể đó. Các váy ảo được triển khai để bảo vệ các trang web trực tiếp cho đến khi chủ sở hữu trang web có thể áp dụng bản vá chính thức từ nhà cung cấp.
Một váy ảo dành riêng cho một XSS phản chiếu đã được xác định thường sẽ:
- Chặn các yêu cầu mà tham số truy vấn hoặc đầu vào POST đến điểm cuối bị ảnh hưởng chứa các mã kịch bản hoặc trình xử lý sự kiện.
- Từ chối các yêu cầu khớp với các mẫu URL khai thác đã biết được báo cáo bởi các nhà nghiên cứu.
- Tăng cường cảnh báo và ghi lại chi tiết về các nỗ lực bị chặn để phân tích sự cố.
Bởi vì các biện pháp này được áp dụng ở lớp WAF, chúng bảo vệ các trang web ngay cả khi phiên bản chủ đề bị lỗ hổng vẫn đang được sử dụng.
Các biện pháp giảm thiểu thực tiễn bạn có thể áp dụng ngay bây giờ (với các chi tiết an toàn, không khai thác)
Dưới đây là các bước thực tiễn — từ đơn giản nhất đến phức tạp hơn — để giảm thiểu sự tiếp xúc ngay lập tức.
1) Cập nhật Chủ đề
- Sao lưu trang web của bạn (tệp + cơ sở dữ liệu).
- Cập nhật Loobek lên v1.5.2 hoặc phiên bản mới hơn.
- Kiểm tra giao diện front-end và admin sau khi cập nhật.
2) Chặn hoặc lọc các chuỗi truy vấn nghi ngờ bằng cách sử dụng WAF
Nếu bạn chạy một WAF (được khuyến nghị), áp dụng các quy tắc chặn các mẫu nghi ngờ trong các chuỗi truy vấn hoặc thân POST. Ví dụ về logic quy tắc (mã giả):
- Nếu URI yêu cầu khớp với các điểm cuối của chủ đề (ví dụ: /wp-content/themes/loobek/ hoặc tên điểm cuối được sử dụng bởi chủ đề) VÀ
- Nếu chuỗi truy vấn hoặc thân POST chứa “<script” (không phân biệt chữ hoa chữ thường) HOẶC các trình xử lý sự kiện như “onerror=” hoặc “onload=” HOẶC “javascript:” giao thức giả,
- Thì chặn hoặc làm sạch yêu cầu và ghi lại sự kiện.
Chúng tôi cung cấp các ví dụ quy tắc WAF cụ thể ở phía dưới (ModSecurity và các đoạn mã NGINX).
3) Thêm xác thực đầu vào / thoát ở phía máy chủ
Nếu chủ đề của bạn có các điểm cuối hoặc trình xử lý biểu mẫu tùy chỉnh mà bạn kiểm soát, hãy đảm bảo tất cả các tham số được làm sạch và mã hóa đầu ra trước khi hiển thị. Sử dụng các hàm thoát thích hợp cho các ngữ cảnh HTML trên máy chủ.
4) Củng cố quyền truy cập admin
- Giới hạn wp-admin chỉ cho các IP đã biết (bên máy chủ hoặc thông qua một proxy ngược).
- Yêu cầu xác thực hai yếu tố cho tất cả người dùng quản trị.
- Thực thi mật khẩu mạnh và xoay vòng định kỳ cho các tài khoản có quyền.
5) Chính sách bảo mật nội dung (CSP)
Một CSP được cấu hình tốt có thể giảm thiểu tác động bằng cách chặn việc thực thi script nội tuyến hoặc giới hạn nguồn script. Ví dụ về tiêu đề CSP hạn chế:
- Để bảo vệ tối đa trên các trang quản trị:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; - Cẩn thận: CSP có thể làm hỏng chức năng nếu trang của bạn phụ thuộc vào các script bên thứ ba. Kiểm tra trên môi trường staging trước.
6) Tăng cường ghi log và giám sát
- Bật ghi log WAF chi tiết cho các điểm cuối bị ảnh hưởng.
- Giám sát các mẫu yêu cầu lặp lại (quét tự động).
- Giữ log đủ lâu để điều tra các khoảng thời gian sự cố.
Ví dụ về WAF / Bản vá ảo (an toàn, không cụ thể khai thác)
Những ví dụ này cung cấp các mẫu quy tắc để chặn đầu vào nghi ngờ. Chúng được thiết kế một cách tổng quát—không dựa vào chúng như là biện pháp bảo vệ duy nhất của bạn. Kiểm tra các quy tắc trong môi trường staging.
Quan trọng: Thích ứng với loại máy chủ và môi trường của bạn.
Quy tắc mẫu ModSecurity (Apache) (khái niệm)
# Block suspicious script tokens in requests targeting Loobek theme endpoints
SecRule REQUEST_URI "@contains /wp-content/themes/loobek/" "phase:2,chain,deny,status:403,id:900001,log,msg:'Blocked potential reflected XSS against Loobek theme endpoint'"
SecRule ARGS "@rx (<|%3C).*script|on(error|load|click|mouseover)|javascript:|document\.cookie" "t:none,t:lowercase,chain"
SecRule REQUEST_METHOD "!@streq OPTIONS"
Ghi chú:
- Tránh chặn chức năng hợp pháp; giám sát log ở chế độ học trước khi từ chối hoàn toàn.
- Sử dụng chuyển đổi chữ thường và giải mã URL khi thích hợp.
Quy tắc khái niệm NGINX / Lua / ngx_lua
# Mã giả sử dụng lua trong nginx
.htaccess ngăn chặn đơn giản (cho Apache không có ModSecurity)
Quy tắc .htaccess cơ bản # để từ chối chuỗi truy vấn chứa "<script"<|%3C).*script" [NC] RewriteRule .* - [F,L]
RewriteCond %{QUERY_STRING} "(.
<|).*script" [NC]
- RewriteRule .* - [F,L].
- Cảnh báo: Đây là một công cụ thô và có thể làm hỏng các yêu cầu hợp lệ bao gồm những chuỗi con đó vì lý do hợp lệ. Sử dụng cùng với ghi log và kiểm tra.
- Cách kiểm tra rằng các biện pháp giảm thiểu của bạn hoạt động (một cách an toàn).
Sử dụng môi trường staging hoặc trang thử nghiệm.
Phản ứng sự cố nếu bạn nghi ngờ bị khai thác
- Mô phỏng các yêu cầu vô hại và xác minh chức năng vẫn nguyên vẹn.
- Sử dụng các công cụ quét bảo mật (không cố gắng tải xuống các payload phá hoại) để kiểm tra các vấn đề phản chiếu và mã hóa. Đảm bảo các công cụ quét đến từ các nguồn đáng tin cậy và chạy chúng trong môi trường thử nghiệm.
- Không bao giờ thử nghiệm các PoC không xác định trên các trang sản xuất. Nếu bạn không tự tin trong việc kiểm tra, hãy hỏi một chuyên gia.
- Cách ly: Đưa trang vào chế độ bảo trì hoặc chặn truy cập công cộng tạm thời.
- Bảo tồn chứng cứ: Xuất log, sao lưu trạng thái hiện tại của trang (tệp và DB). Không ghi đè lên log.
- Thay đổi thông tin đăng nhập: Tài khoản quản trị, FTP/SFTP, mật khẩu người dùng cơ sở dữ liệu, khóa API.
- Quét phần mềm độc hại toàn diện và kiểm tra thủ công: tìm các tệp PHP mới trong wp-content, người dùng quản trị không mong đợi, các tác vụ đã lên lịch không được ủy quyền (các mục cron), hoặc các tệp core/theme/plugin đã được sửa đổi.
Xóa nội dung độc hại và tăng cường: Thay thế các tệp đã sửa đổi từ các bản sao lưu sạch hoặc gói nhà cung cấp; áp dụng lại các bản cập nhật theme/plugin.
Quét lại nhiều lần cho đến khi sạch.
- Công bố một tóm tắt sự cố ngắn gọn cho các bên liên quan bị ảnh hưởng và cập nhật bất kỳ thông tin liên lạc công khai nào nếu dữ liệu người dùng có thể đã bị ảnh hưởng.
- Nếu bạn cần giúp đỡ, hãy liên hệ với một chuyên gia bảo mật đáng tin cậy có thể thực hiện phân tích pháp y và khắc phục.
- Cài đặt lại lõi WordPress, chủ đề và plugin từ các gói nhà cung cấp mới khi có thể.
- Tăng cường truy cập (hạn chế IP, thực thi 2FA).
- Áp dụng các quy tắc WAF bao gồm vá ảo để ngăn chặn tái khai thác.
- Thực hiện đánh giá bảo mật toàn diện và lên lịch quét định kỳ.
Khuyến nghị tăng cường an ninh lâu dài
- Giữ cho lõi WordPress, các chủ đề và plugin được cập nhật. Đăng ký nhận thông báo bảo mật từ nhà cung cấp hoặc sử dụng quy trình cập nhật được quản lý.
- Sử dụng nguyên tắc quyền tối thiểu cho các vai trò người dùng. Tránh sử dụng tài khoản quản trị cho việc chỉnh sửa nội dung thường xuyên.
- Triển khai xác thực đa yếu tố cho tất cả các tài khoản có quyền.
- Thường xuyên sao lưu và kiểm tra quy trình khôi phục.
- Sử dụng WAF hỗ trợ triển khai quy tắc nhanh chóng và vá ảo.
- Duy trì kế hoạch phản ứng sự cố và thực hiện các bài tập bàn với nhóm của bạn.
Ví dụ về chữ ký quy tắc WAF (gợi ý mẫu cho các nhóm)
Khi tạo chữ ký, ưu tiên các mẫu bảo thủ và kết hợp với ngữ cảnh (URI mục tiêu, uy tín IP, bất thường tác nhân người dùng). Các thành phần phát hiện mẫu:
- Mẫu: Sự hiện diện của "<script", "<img onerror", "javascript:" trong chuỗi truy vấn hoặc thân POST.
- Mẫu: Các thuộc tính trình xử lý sự kiện (onload=, onerror=, onclick=) trong các tham số.
- Pattern: Suspicious percent‑encoded tokens like "%3Cscript%3E" and multiple encoding layers.
- Bộ lọc ngữ cảnh: Chỉ áp dụng chặn nghiêm ngặt khi yêu cầu đến các tệp chủ đề hoặc điểm cuối được biết đến là phản ánh đầu vào. Không chặn tất cả các yêu cầu trên toàn bộ trang mà không thử nghiệm.
Luôn ghi lại các kết quả khớp một cách chi tiết (thời gian, IP nguồn, yêu cầu đầy đủ, id quy tắc khớp) cho mục đích pháp y.
Dương tính giả: giảm thiểu sự cố
- Bắt đầu ở chế độ giám sát: chỉ ghi lại, không chặn, trong một khoảng thời gian ngắn để hiểu hành vi bình thường.
- Sử dụng danh sách trắng cho các IP quản trị đáng tin cậy trong quá trình thử nghiệm.
- Tinh chỉnh bằng cách loại trừ các URL hợp pháp hoặc tham số có thể chứa dữ liệu hợp lệ (ví dụ, mô tả sản phẩm chứa “javascript” như một từ—hiếm, nhưng có thể).
Các câu hỏi thường gặp (câu trả lời ngắn)
Hỏi: Liệu XSS này có thể bị khai thác mà không cần tương tác không?
MỘT: Không. XSS phản ánh yêu cầu người dùng nhấp vào một liên kết được tạo hoặc truy cập một trang được tạo. Tuy nhiên, kẻ tấn công sử dụng kỹ thuật xã hội để lừa các quản trị viên nhấp vào những liên kết như vậy (email, nhắn tin, v.v.).
Hỏi: Việc chặn "<script" trong các yêu cầu có làm hỏng trang web của tôi không?
MỘT: Có thể. Nhiều trang web hiện đại không gửi thẻ script trong chuỗi truy vấn, nhưng một số tính năng hoặc tích hợp có thể bao gồm dữ liệu được mã hóa. Luôn kiểm tra trước khi bật chặn nghiêm ngặt.
Hỏi: Tôi có nên gỡ bỏ chủ đề Loobek cho đến khi nó được vá không?
MỘT: Nếu bạn không thể cập nhật một cách an toàn, hãy xem xét chuyển sang một chủ đề khác hoặc một bản sao sạch của Loobek 1.5.2 sau khi thử nghiệm. Tối thiểu, hãy áp dụng vá ảo WAF và tăng cường quyền truy cập quản trị.
Về các biện pháp giảm thiểu WP‑Firewall và vá ảo
Bộ quy tắc quản lý của chúng tôi chứa các chữ ký lớp được điều chỉnh cho các mẫu WordPress và các điểm cuối chủ đề/plugin phổ biến. Khi có thông báo lỗ hổng mới, đội ngũ bảo mật của chúng tôi nhanh chóng phát triển, thử nghiệm và triển khai các bản vá ảo mục tiêu mà:
- Phát hiện và chặn các mẫu yêu cầu khai thác đã biết.
- Giảm thiểu thời gian tiếp xúc cho các chủ sở hữu trang web không thể cập nhật ngay lập tức.
- Cung cấp nhật ký chi tiết và cảnh báo để các quản trị viên có thể điều tra các nỗ lực khai thác.
Vá ảo không phải là sự thay thế cho các bản cập nhật của nhà cung cấp — đó là một biện pháp bảo vệ trong khi bạn thực hiện bản cập nhật vĩnh viễn. Chúng tôi khuyên bạn nên kết hợp vá ảo với bản cập nhật và các biện pháp tăng cường lâu dài được mô tả ở trên.
Mới: Bảo mật trang web của bạn ngay lập tức với Kế hoạch Miễn phí WP‑Firewall
Bảo vệ trang WordPress của bạn không nên chờ đến khi bạn có thể lên lịch cho một bản cập nhật đầy đủ. Nếu bạn muốn bảo vệ ngay lập tức, được quản lý trong khi bạn lên kế hoạch hoặc thử nghiệm bản cập nhật cho Loobek 1.5.2, kế hoạch miễn phí của WP‑Firewall cung cấp các biện pháp phòng ngừa thiết yếu rất hiệu quả trong việc chặn các nỗ lực XSS phản ánh và các rủi ro phổ biến khác.
Tại sao nên xem xét kế hoạch miễn phí?
- Bảo vệ thiết yếu: tường lửa được quản lý với bộ quy tắc được chọn lọc cẩn thận chặn các tải trọng XSS phổ biến và các rủi ro Top 10 của OWASP.
- Băng thông không giới hạn: không có giới hạn hoặc hạn chế ẩn trong khi các mẫu lưu lượng thay đổi do quét hoặc hoạt động khắc phục.
- Trình quét phần mềm độc hại và WAF: giúp phát hiện và chặn lưu lượng khai thác đã thử nghiệm và bề mặt các hiện vật nghi ngờ.
- Thiết lập nhanh và không tính phí: bảo vệ ngay lập tức trong khi bạn thử nghiệm hoặc áp dụng các bản cập nhật của nhà cung cấp.
Đăng ký kế hoạch miễn phí và nhận bảo vệ nhanh chóng, được quản lý từ đội ngũ của chúng tôi: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Các khuyến nghị cuối cùng — ưu tiên
- Cập nhật Loobek lên phiên bản 1.5.2 (sửa chữa vĩnh viễn).
- Nếu việc cập nhật ngay lập tức không khả thi, hãy kích hoạt vá lỗi ảo WAF được quản lý và áp dụng các quy tắc tạm thời được mô tả ở trên.
- Tăng cường quyền truy cập quản trị (giới hạn IP, xác thực hai yếu tố) và buộc đặt lại mật khẩu cho người dùng có quyền cao.
- Tăng cường giám sát và giữ lại nhật ký; xem xét nhật ký để phát hiện hoạt động đáng ngờ.
- Nếu bạn nghi ngờ bị xâm phạm, hãy cách ly trang web, bảo tồn nhật ký và thực hiện dọn dẹp toàn bộ hoặc thuê chuyên gia.
Ghi chú kết thúc từ đội ngũ bảo mật WP‑Firewall
Các sự cố bảo mật như CVE‑2026‑25349 là lời nhắc nhở rằng các hệ sinh thái WordPress là động. Cập nhật kịp thời là biện pháp phòng thủ tốt nhất — nhưng chúng tôi biết rằng các bản cập nhật thường cần có giai đoạn, thử nghiệm hoặc phối hợp với nhà phát triển. Đó là lý do tại sao vá lỗi ảo và bảo vệ tường lửa được quản lý từ WP‑Firewall tồn tại: để cung cấp cho bạn không gian thở ngay lập tức trong khi bạn thực hiện biện pháp khắc phục đúng đắn.
Nếu bạn cần hỗ trợ về phát hiện, vá lỗi ảo khẩn cấp, hoặc ý kiến thứ hai về các bước khắc phục, đội ngũ WP‑Firewall sẵn sàng giúp đỡ. Để có sự bảo vệ miễn phí ngay lập tức mà bạn có thể kích hoạt hôm nay, hãy truy cập: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Hãy giữ an toàn và cập nhật các trang của bạn.
— Nhóm bảo mật WP‑Firewall
