Tên plugin	Backup Guard
Loại lỗ hổng	Lỗ hổng vượt qua đường dẫn
Số CVE	CVE-2026-4853
Tính cấp bách	Thấp
Ngày xuất bản CVE	2026-04-17
URL nguồn	CVE-2026-4853

Quan trọng: Vượt qua đường dẫn + Xóa thư mục tùy ý trong JetBackup / Backup Guard (CVE-2026-4853) — Những gì chủ sở hữu trang WordPress cần biết và cách bảo vệ bản thân

Đã xuất bản: 17 Tháng 4, 2026
Plugin bị ảnh hưởng: JetBackup / Backup Guard (plugin slug: backup)
Các phiên bản dễ bị tấn công: <= 3.1.19.8
Phiên bản đã được vá: 3.1.20.3
CVE: CVE-2026-4853
Mức độ nghiêm trọng: Thấp (Ưu tiên Patchstack: Thấp, CVSS: 4.9) — nhưng đừng bị đánh lừa: tác động thực tế có thể đáng kể nếu kẻ tấn công có được hoặc đã kiểm soát tài khoản Quản trị viên.

Là đội ngũ đứng sau WP-Firewall, chúng tôi theo dõi các lỗ hổng WordPress liên tục và tư vấn cho các chủ sở hữu trang, nhà phát triển và nhà cung cấp về các phản ứng thực tiễn, có ưu tiên. Lỗ hổng JetBackup/Backup Guard này là một lỗ hổng vượt qua đường dẫn đã xác thực cho phép người dùng cấp độ Quản trị viên xóa các thư mục tùy ý thông qua một giá trị được chế tạo trong tên tệp tham số (thường được gửi đến một điểm cuối sao lưu/xóa). Lỗi này đã được công bố một cách có trách nhiệm và được vá trong phiên bản 3.1.20.3 — việc cập nhật là biện pháp khắc phục đơn giản và hiệu quả nhất. Dưới đây, chúng tôi sẽ phân tích chi tiết kỹ thuật, kịch bản rủi ro thực tế, chiến lược phát hiện và giảm thiểu, quy tắc vá ảo WAF thực tiễn, các bước phản ứng sự cố và khuyến nghị tăng cường lâu dài để bạn có thể hành động nhanh chóng và tự tin.

Lưu ý: Thông báo này được viết cho các chủ sở hữu trang WordPress, kỹ sư bảo mật và đội ngũ lưu trữ quản lý. Nó bao gồm các cấu hình phòng thủ có thể hành động và mẫu mã để giúp bạn giảm thiểu vấn đề một cách nhanh chóng và an toàn.

Tóm tắt điều hành (ngắn gọn)

Cái gì: Vượt qua đường dẫn trong trình xử lý xóa sao lưu plugin thông qua tên tệp tham số. Một Quản trị viên đã xác thực có thể sử dụng các chuỗi vượt qua đường dẫn (../) để nhắm mục tiêu các thư mục bên ngoài các thư mục sao lưu mong đợi và kích hoạt việc xóa.
Ai bị ảnh hưởng: Các trang web chạy plugin ở phiên bản <= 3.1.19.8.
Sự va chạm: Xóa thư mục tùy ý (tệp trang, tải lên, sao lưu, nhật ký) — phá hủy nếu bị khai thác. Cần có quyền Quản trị viên để khai thác, vì vậy các cuộc tấn công có khả năng xảy ra nhất sau khi tài khoản quản trị viên bị xâm phạm hoặc lạm dụng.
Sửa chữa ngay lập tức: Cập nhật plugin lên 3.1.20.3 hoặc phiên bản mới hơn.
Các biện pháp giảm thiểu tạm thời: Áp dụng các quy tắc WAF để chặn các tải trọng vượt qua đường dẫn, hạn chế quyền truy cập vào bảng điều khiển quản trị cho các IP đáng tin cậy, vô hiệu hóa plugin hoặc điểm cuối xóa có lỗ hổng cho đến khi được vá, tăng cường quyền truy cập tệp và đảm bảo sao lưu mạnh mẽ.

Cách mà lỗ hổng hoạt động (tổng quan kỹ thuật, giải thích không thể khai thác)

Ở mức độ cao, lỗ hổng phát sinh từ việc xác thực và làm sạch không đủ đối với một tên tệp tham số do người dùng cung cấp mà plugin sử dụng để xây dựng đường dẫn hệ thống tệp cho việc xóa. Khi plugin xây dựng một đường dẫn như:

/wp-content/plugins/backup/backup-files/

và nó không thành công trong việc chuẩn hóa hoặc hạn chế đúng cách tênTậpTin, một kẻ thù có thể bao gồm các chuỗi duyệt đường dẫn như ../../ trong tham số. Nếu plugin sau đó truyền đường dẫn đã xây dựng đó cho các chức năng xóa hệ thống tệp mà không kiểm tra xem đường dẫn đã giải quyết có nằm trong một thư mục cơ sở mong đợi hay không, nó có thể xóa các thư mục hoặc tệp tùy ý.

Các nguyên nhân gốc rễ chính thường thấy trong loại lỗi này:

Không có kiểm tra canonicalization/realpath — plugin tin tưởng vào đường dẫn nối mà không xác minh đường dẫn đã giải quyết cuối cùng nằm dưới thư mục cho phép.
Thiếu kiểm tra basename hoặc danh sách trắng — plugin chấp nhận các giá trị tên tệp tùy ý thay vì hạn chế vào các tên sao lưu đã biết.
Kiểm tra khả năng/nonce không đầy đủ hoặc thiếu nonces trên các điểm cuối nhạy cảm (mặc dù ở đây kẻ tấn công phải là quản trị viên, vì vậy khả năng có mặt; ngăn chặn CSRF và việc sử dụng quyền hạn quá mức vẫn là điều quan trọng).
Thất bại trong việc xác thực sự tồn tại của tệp/thư mục và ngăn chặn việc xóa thư mục (rmdir/unlink) cho các tài nguyên không được sao lưu.

Bởi vì các cuộc gọi xóa có thể đệ quy nếu mã bọc sử dụng các triển khai rmdir đệ quy, hiệu ứng có thể leo thang từ việc xóa một tệp đơn lẻ đến việc xóa toàn bộ thư mục.

Các kịch bản khai thác và tác động thực tiễn

Mặc dù lỗ hổng yêu cầu quyền quản trị viên để kích hoạt, đây là những cách thực tế mà lỗi có thể trở thành một mối đe dọa thực tiễn:

Thỏa hiệp thông tin xác thực của quản trị viên: Lừa đảo, mật khẩu tái sử dụng, mật khẩu bị rò rỉ, hoặc kỹ thuật xã hội có thể cung cấp cho kẻ tấn công một tài khoản quản trị viên. Khi họ có quyền truy cập giao diện người dùng cấp quản trị, họ có thể tạo một yêu cầu đến điểm cuối dễ bị tổn thương để xóa các thư mục trang web.
Nguy cơ từ quản trị viên độc hại hoặc nội bộ: Một quản trị viên hoặc nhà thầu bất chính với quyền truy cập hợp pháp có thể lạm dụng tính năng này.
Các cuộc tấn công chuỗi: Một kẻ tấn công đã kiểm soát một plugin có quyền hạn thấp hơn hoặc chủ đề bị xâm phạm có thể nâng cao hoặc chuyển hướng để đạt được quyền quản trị khi kết hợp với các điểm yếu khác. Trong một cuộc tấn công nhiều bước như vậy, khả năng xóa bỏ làm gia tăng thiệt hại.

Tác động tiềm tàng bao gồm:

Xóa các thư mục sao lưu và các bản sao lưu đã lưu trữ (từ chối phục hồi).
Xóa các tệp tải lên (hình ảnh, phương tiện) và các tệp wp-content (chủ đề/plugin).
Loại bỏ các nhật ký và các hiện vật pháp y.
Xóa các thư mục cấu hình hoặc tùy chỉnh bên ngoài webroot nếu việc duyệt đường dẫn cho phép rời khỏi thư mục cơ sở dự kiến.
Gián đoạn dịch vụ và mất dữ liệu dẫn đến thời gian ngừng hoạt động và chi phí phục hồi.

Ngay cả với CVSS “Thấp”, chi phí hoạt động và tác động đến danh tiếng của các sự kiện xóa hàng loạt có thể cao — đặc biệt đối với các trang web không có bản sao lưu gần đây hoặc môi trường staging.

Danh sách kiểm tra hành động ngay lập tức (những gì cần làm ngay bây giờ)

Nếu trang web của bạn sử dụng plugin JetBackup / Backup Guard và bạn lưu trữ hoặc duy trì các trang WordPress, hãy làm theo danh sách kiểm tra ưu tiên này ngay lập tức:

Cập nhật plugin lên 3.1.20.3 hoặc phiên bản mới hơn.
– Đây là bản sửa lỗi cuối cùng. Hãy làm điều này trước tiên trên môi trường staging, sau đó là sản xuất. Kiểm tra các luồng sao lưu/phục hồi sau khi cập nhật.
Nếu bạn không thể cập nhật ngay lập tức:
– Vô hiệu hóa plugin hoặc vô hiệu hóa chức năng xóa sao lưu cho đến khi một bản vá có thể được áp dụng.
– Hạn chế quyền truy cập /wp-admin/ và các điểm cuối plugin đến các địa chỉ IP đáng tin cậy nếu có thể.
– Áp dụng các quy tắc WAF tạm thời (các ví dụ và mẫu ở phía dưới) để chặn các yêu cầu chứa các mẫu duyệt đường dẫn trong tên tệp 7. hoặc các tham số tương tự.
Thay đổi thông tin đăng nhập quản trị và kích hoạt 2FA cho tất cả các tài khoản quản trị viên.
Xác minh các bản sao lưu trang web (ngoài trang) và đảm bảo bạn có một kế hoạch phục hồi đã được kiểm tra trước khi thực hiện thay đổi.
Giám sát các nhật ký để phát hiện các yêu cầu xóa đáng ngờ và việc loại bỏ tệp đột ngột.
Giao tiếp với các bên liên quan (chủ sở hữu trang, nhà cung cấp dịch vụ, vận hành) và chuẩn bị một kế hoạch phản ứng sự cố nếu phát hiện các vụ xóa bất ngờ.

Phát hiện: cách phát hiện các cuộc tấn công hoặc khai thác thành công

Tìm kiếm các dấu hiệu sau trong nhật ký truy cập, nhật ký kiểm toán và hoạt động hệ thống tệp:

Các yêu cầu HTTP nhắm vào các điểm cuối plugin xử lý sao lưu hoặc xóa tệp với các tham số truy vấn như tênTậpTin, tên tệp, tài liệu, tên hoặc các thân POST chứa tên. Ví dụ về các mẫu truy vấn đáng ngờ:
- filename=../../
- filename=....
- fileName=wp-contentuploads
Các yêu cầu có chuỗi vượt qua đường dẫn trong bất kỳ tham số nào:
- ../
- ..\\
- Các tương đương được mã hóa URL %2e%2e%2f hoặc %2e%2e%5c
Các tệp hoặc thư mục đột ngột bị thiếu trong wp-content, uploads, hoặc thư mục sao lưu của plugin.
Các sự kiện xóa tệp bất ngờ được quan sát trong các công cụ giám sát hệ thống tệp, hoặc sự gia tăng trong các hoạt động “xóa”.
Đăng nhập quản trị từ các IP / vị trí địa lý bất thường theo sau là các yêu cầu đến các điểm cuối sao lưu.

Ví dụ về các quy tắc phát hiện (cấp cao):

Khớp các yêu cầu mà một tham số có tên không phân biệt chữ hoa chữ thường như tên tệp, tênTậpTin, tài liệu chứa \.\./ hoặc %2e%2e%2f.
Khớp các thân POST cố gắng xóa hoặc quản lý các bản sao lưu bao gồm các chuỗi vượt qua.
Cảnh báo về rmdir hoặc hủy liên kết các lỗi trong nhật ký máy chủ tương ứng với các đường dẫn không mong đợi bên ngoài thư mục cơ sở được phép.

Lệnh shell hữu ích để tìm các mục đã được sửa đổi/xóa gần đây (chạy với quyền quản trị, cẩn thận):

# Tìm các tệp trong webroot đã được sửa đổi trong 7 ngày qua (điều chỉnh khi cần)

Nếu bạn có giám sát tính toàn vẹn tệp (Tripwire, OSSEC, v.v.), hãy sử dụng nó để nhanh chóng tìm các mục đã xóa.

Bản vá ảo & quy tắc WAF (chữ ký thực tiễn bạn có thể áp dụng ngay bây giờ)

Tường lửa ứng dụng web (WAF) có thể được cấu hình để chặn các yêu cầu cố gắng khai thác việc duyệt đường dẫn. Dưới đây là các mẫu quy tắc an toàn, phòng thủ và các ví dụ thực tiễn. Áp dụng chúng để chặn đầu vào độc hại thay vì các quy tắc kiểu cho phép có thể phá vỡ quy trình làm việc của quản trị viên. Đây là các mẫu phòng thủ — hãy thử nghiệm chúng ở chế độ giám sát trước khi chặn.

Quan trọng: điều chỉnh tên tham số cho các điểm cuối của plugin và cho các mẫu nhật ký của bạn. Tham số dễ bị tổn thương thường được đặt tên là tênTậpTin (có thể có các biến thể không phân biệt chữ hoa chữ thường).

Ví dụ về quy tắc theo kiểu ModSecurity (khái niệm):

# Block requests where any argument named filename (case-insensitive) contains ../ or encoded variants
SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Block possible Backup plugin path traversal attempt', \
 chain"
SecRule ARGS "@rx (\.\./|\.\.\\||)" "t:none,deny,status:403"

Đoạn mã vị trí Nginx (chặn chuỗi truy vấn có ../ trong filename):

if ($arg_filename ~* "\.\./|") {
 return 403;
}
# Repeat for $arg_fileName or other param names

Đề xuất WAF/Quy tắc chung:

Chặn bất kỳ yêu cầu nào mà ARGS chứa các ký tự duyệt đường dẫn mã hóa và nơi yêu cầu nhắm đến đường dẫn điểm cuối xóa của plugin (ví dụ: /wp-admin/admin-ajax.php?action=backup_delete hoặc tuyến ajax cụ thể của plugin).
Phát hiện và chặn các tải trọng null-byte hoặc các ký tự duyệt đường dẫn mã hóa Unicode.
Kết hợp phát hiện mẫu với giới hạn tỷ lệ và hạn chế truy cập bảng điều khiển quản trị.
Ghi lại các sự kiện bị chặn với đầy đủ tiêu đề và thân yêu cầu để xem xét pháp y.

Giữ cho các quy tắc bảo thủ để tránh các dương tính giả; xem xét chỉ đưa chúng vào chế độ chặn sau khi giám sát trong một hoặc hai ngày.

Ví dụ mã cứng hóa an toàn cho các tác giả plugin / nhóm phát triển

Nếu bạn duy trì tích hợp tùy chỉnh hoặc một bản vá, hãy đảm bảo rằng phía máy chủ sử dụng chuẩn hóa và thực thi nghiêm ngặt các thư mục cơ sở được phép và danh sách trắng. Dưới đây là một mẫu an toàn cho PHP trong ngữ cảnh WordPress (làm sạch tên tệp và xác minh đường dẫn thực).

Quan trọng: đây là mã mẫu phòng thủ để minh họa việc xử lý an toàn; các tác giả plugin nên điều chỉnh, làm sạch và kiểm tra trước khi triển khai.

<?php

Các kiểm tra chính được minh họa:

Kiểm tra khả năng (người dùng hiện tại có thể)
Xác minh Nonce
Sử dụng basename() hoặc danh sách trắng nghiêm ngặt để ngăn chặn các ký tự phân tách đường dẫn
Sử dụng đường dẫn thực tế để chuẩn hóa và kiểm tra tiền tố đảm bảo mục tiêu nằm trong thư mục được phép

Các biện pháp giảm thiểu cấp máy chủ mà bạn có thể áp dụng ngay bây giờ

Nếu bạn là một máy chủ hoặc quản lý máy chủ, hãy áp dụng các bước tăng cường bổ sung sau:

Hạn chế quyền truy cập vào khu vực quản trị chỉ cho các địa chỉ IP đáng tin cậy thông qua quy tắc tường lửa hoặc danh sách truy cập máy chủ web (nếu có thể).
Sử dụng open_basedir để giới hạn các quy trình PHP trong các thư mục cho phép.
Cấu hình quyền tệp sao cho người dùng máy chủ web không thể xóa các tệp hệ thống tùy ý (hãy chú ý đến nhu cầu của plugin và sao lưu).
Sử dụng các hồ sơ SELinux hoặc AppArmor để cách ly các quy trình WordPress và hạn chế quyền truy cập tệp.
Bật kiểm toán cấp quy trình (auditd) để ghi lại các lần xóa tệp bởi các quy trình PHP cho phân tích pháp y.
Sử dụng sao lưu ngoài (lưu trữ bên ngoài máy chủ web) để đảm bảo phục hồi an toàn ngay cả khi các sao lưu cấp trang web bị xóa.

Phản ứng sự cố: nếu bạn nghi ngờ bị khai thác

Nếu bạn tin rằng trang web của bạn đã bị khai thác thông qua lỗ hổng này (hoặc bất kỳ lỗ hổng nào khác), hãy làm theo các bước sau:

Ngay lập tức cách ly trang web (tắt nó hoặc bật chế độ bảo trì) để ngăn chặn thiệt hại thêm.
Bảo tồn nhật ký và dữ liệu pháp y của máy chủ — sao chép nhật ký truy cập, nhật ký lỗi và bất kỳ nhật ký ứng dụng nào vào một kho lưu trữ riêng biệt, không thể thay đổi.
Khôi phục từ một bản sao lưu đã biết tốt được lưu trữ bên ngoài (không trong các bản sao lưu do plugin quản lý nếu bạn nghi ngờ bị xóa).
Thay đổi tất cả thông tin đăng nhập cho các tài khoản Quản trị viên và bất kỳ khóa API, mã thông báo hoặc thông tin đăng nhập cơ sở dữ liệu nào có thể đã bị lộ.
Buộc đặt lại mật khẩu cho người dùng có vai trò đặc quyền và bật xác thực hai yếu tố (2FA).
Quét tìm các cửa hậu bổ sung, các tác vụ cron đáng ngờ, người dùng quản trị mới hoặc các tệp plugin/theme đã được sửa đổi.
Cài đặt lại lõi WordPress và tất cả các plugin/theme từ các nguồn chính thức sau khi đã dọn dẹp, hoặc khôi phục một bản sao lưu đã được xác thực hoàn toàn.
Nếu bạn không có chuyên môn, hãy thuê một nhà cung cấp phản ứng sự cố an ninh chuyên biệt hoặc một nhà cung cấp WordPress quản lý đáng tin cậy và chia sẻ các tài liệu pháp y.

Các khuyến nghị và thực tiễn tốt nhất lâu dài

Để giảm thiểu khả năng lỗ hổng loại này gây ra thiệt hại lớn trong tương lai, hãy tuân theo các nguyên tắc sau:

Quyền tối thiểu: giảm thiểu số lượng người dùng có quyền Quản trị viên. Sử dụng quyền truy cập dựa trên vai trò và chỉ cấp những gì cần thiết.
MFA ở mọi nơi: thực thi xác thực đa yếu tố cho tất cả các tài khoản có khả năng quản trị.
Cập nhật thường xuyên: thiết lập một chu kỳ (hàng tuần/hai tuần) để cập nhật lõi WordPress, chủ đề và plugin; thử nghiệm cập nhật trong môi trường staging trước.
Sao lưu an toàn: duy trì nhiều bản sao lưu tự động ngoài site (hàng ngày/hàng tuần) và định kỳ kiểm tra phục hồi.
Kiểm tra plugin: giữ một danh sách nhỏ, được chọn lọc các plugin và loại bỏ các plugin không sử dụng. Ưu tiên các plugin được duy trì tích cực với hồ sơ bảo mật.
Vá ảo: duy trì các quy tắc WAF có thể được cập nhật nhanh chóng để chặn các mẫu tấn công đã biết cho đến khi các bản vá của nhà cung cấp được áp dụng.
Quy trình phát triển an toàn (SDLC): các nhà phát triển nên thực hiện xác thực đầu vào, chuẩn hóa và kiểm tra quyền tối thiểu trên tất cả các thao tác tệp.
Ghi log & giám sát: có SIEM hoặc tổng hợp log để cảnh báo về hoạt động quản trị đáng ngờ và sự kiện xóa.

Ví dụ quy tắc WAF thực tiễn (thêm)

Dưới đây là một số ví dụ quy tắc phòng thủ cho các môi trường khác nhau. Vui lòng xác thực các quy tắc này trong một môi trường staging an toàn trước khi áp dụng vào sản xuất.

Chặn chung trên các ký tự duyệt trong tênTậpTin tham số (khái niệm):
- Điều kiện: Yêu cầu chứa tên tham số khớp với (?i:file(Tên)?) và giá trị khớp với các mẫu duyệt.
- Hành động: Chặn và ghi lại.
Giới hạn hành động AJAX cụ thể của plugin (nếu plugin sử dụng admin-ajax):
- Chặn bất kỳ cuộc gọi admin-ajax nào với action=xóa_sao_lưu trừ khi yêu cầu xuất phát từ các IP được cho vào danh sách trắng hoặc chứa một nonce site hợp lệ.
Chặn duyệt mã hóa:
- Phát hiện cả chuỗi thô (../) và chuỗi mã hóa URL (%2e%2e%2f, /) và các biến thể Unicode.
Giới hạn tỷ lệ:
- Giới hạn các hành động phá hủy (xóa điểm cuối) ở mức thấp mỗi phút cho mỗi tài khoản quản trị viên hoặc địa chỉ IP.

Tại sao phải cập nhật ngay cả khi CVSS có vẻ “thấp”?

CVSS là một yếu tố, nhưng rủi ro thực tế phụ thuộc vào ngữ cảnh. Lỗ hổng này yêu cầu quyền quản trị viên — điều đó giảm rủi ro khai thác ẩn danh từ xa — nhưng trên thực tế, nhiều trang web thiếu vệ sinh tài khoản quản trị viên nghiêm ngặt. Tài khoản quản trị viên thường bị xâm phạm qua việc tái sử dụng thông tin xác thực, mật khẩu yếu hoặc lừa đảo. Khi một kẻ tấn công có quyền truy cập quản trị, khả năng xóa thư mục từ xa có thể gây ra thảm họa.

Cũng cần xem xét:

Kẻ tấn công có thể kết hợp các lỗ hổng. Một điểm khởi đầu nhỏ + khả năng xóa này = thiệt hại lớn.
Xóa các tệp sao lưu sẽ loại bỏ con đường phục hồi của bạn.
Chi phí danh tiếng và phục hồi có thể vượt xa nhãn độ nghiêm trọng “Thấp” ban đầu.

Vì vậy, hãy coi đây là một rủi ro thực tiễn ưu tiên cao nếu bạn lưu trữ các trang sản xuất hoặc nhiều khách hàng.

Ví dụ về các truy vấn và cảnh báo giám sát

Cảnh báo khi một người dùng quản trị thực hiện cuộc gọi xóa nhắm vào các điểm cuối plugin với ../ trong các tham số.
Cảnh báo khi số lượng lớn tệp bị xóa từ wp-content/tải lên hoặc thư mục sao lưu plugin.
Tóm tắt hàng ngày: danh sách các tệp bị xóa do các quy trình PHP-FPM khởi xướng trong webroot.

Ví dụ về loggrep đơn giản để tìm các yêu cầu đáng ngờ (Apache/Nginx):

# Look for traversal patterns in access logs
grep -E "(filename|fileName|file)=.*(\.\./|)" /var/log/nginx/access.log | tail -n 200

Sau bản vá: xác minh và xác nhận

Sau khi cập nhật plugin lên 3.1.20.3 (hoặc phiên bản mới hơn), hãy xác thực:

Chức năng xóa của plugin vẫn hoạt động như mong đợi đối với các tệp sao lưu hợp lệ, nhưng không thể truy cập ra ngoài thư mục được chỉ định.
Không có lỗi bất ngờ nào xảy ra trong các quy trình sao lưu/phục hồi.
Thực hiện một bài kiểm tra có kiểm soát: cố gắng yêu cầu xóa với một payload truy cập (trong môi trường staging) và xác minh rằng nó bị từ chối và/hoặc được ghi lại.
Chỉ kích hoạt lại bất kỳ quy tắc WAF tạm thời nào sau khi xác nhận rằng plugin đã được sửa; giữ các quy tắc phát hiện để cảnh báo về hoạt động bất thường.

Thời gian và thông báo trách nhiệm (ngắn gọn)

Lỗ hổng này đã được xác định và báo cáo cho nhà cung cấp trước khi công bố công khai. Nhà cung cấp đã phát hành một bản vá trong 3.1.20.3. CVE-2026-4853 đã được gán để theo dõi vấn đề. Chúng tôi luôn khuyến nghị cập nhật lên phiên bản đã được vá như là biện pháp khắc phục chính.

Ví dụ thực tế: những gì một quản trị viên hosting nên làm trong 15–60 phút

Nếu bạn là một quản trị viên hosting hoặc chủ sở hữu trang web thức dậy với thông báo này, đây là một “sổ tay 60 phút đầu tiên” ngắn gọn:

0–10 phút:

Xác định các trang bị ảnh hưởng (plugin đã cài đặt và phiên bản <= 3.1.19.8).
Thông báo cho các bên liên quan (chủ sở hữu trang web, hoạt động).

10–30 phút:

Nếu việc cập nhật ngay lập tức là khả thi, hãy cập nhật plugin trên staging và sau đó là production.
Nếu bạn không thể cập nhật, hãy vô hiệu hóa plugin và/hoặc hạn chế quyền truy cập vào các điểm cuối quản trị thông qua danh sách cho phép IP.

30–60 phút:

Áp dụng các quy tắc WAF tạm thời để chặn các mẫu truy cập đường dẫn đối với các điểm cuối của plugin.
Thay đổi thông tin đăng nhập quản trị và kích hoạt 2FA.
Xác minh rằng các bản sao lưu ngoài trang web vẫn nguyên vẹn và thực hiện một bản sao lưu thủ công bổ sung nếu có thể.

Ghi chú cuối — cân bằng giữa sự khẩn cấp và an toàn

Cập nhật lên 3.1.20.3 hoặc phiên bản mới hơn ngay khi bạn có thể. Nếu bạn không thể cập nhật ngay lập tức, hãy sử dụng các biện pháp giảm thiểu theo lớp được mô tả ở trên: vá ảo WAF, hạn chế IP, vô hiệu hóa plugin, hoặc cắt bỏ khả năng xóa cho đến khi bản vá được áp dụng. Luôn đảm bảo rằng bạn đã kiểm tra các bản sao lưu ngoài trang web trước khi thực hiện các thay đổi khắc phục lớn.

Chúng tôi hiểu rằng các bản cập nhật đôi khi có thể làm hỏng tính tương thích. Đó là lý do tại sao các đội ngũ chủ nhà và đại lý cần quy trình làm việc có thể dự đoán và đã được kiểm tra cho các bản cập nhật plugin, các bản vá ảo khẩn cấp và các thực hành phục hồi. Nếu bạn quản lý nhiều trang WordPress, tự động hóa và quản lý tập trung cho các bản cập nhật, quy tắc WAF và sao lưu sẽ giảm đáng kể thời gian phản ứng.

Bắt đầu bảo vệ trang của bạn với kế hoạch miễn phí WPFirewall

Nếu bạn muốn một cách nhanh chóng và thực tiễn để thêm một lớp bảo vệ trong khi xử lý các bản cập nhật plugin, hãy xem xét bắt đầu với kế hoạch WPFirewall miễn phí của chúng tôi. Nó cung cấp các biện pháp bảo vệ thiết yếu giúp chặn các nỗ lực khai thác và theo dõi hành vi đáng ngờ trong khi bạn vá lỗi:

Cơ bản (Miễn phí) — Bảo vệ thiết yếu: tường lửa được quản lý, băng thông không giới hạn, một WAF, quét phần mềm độc hại và giảm thiểu các rủi ro OWASP Top 10.
Tiêu chuẩn — Tất cả các tính năng cơ bản cộng với việc xóa malware tự động và khả năng đưa vào danh sách đen/trắng lên đến 20 IP.
Chuyên nghiệp — Tất cả các tính năng tiêu chuẩn cộng với báo cáo bảo mật hàng tháng, vá lỗi ảo tự động cho các lỗ hổng và quyền truy cập vào các tiện ích mở rộng cao cấp: Quản lý Tài khoản Đặc biệt, Tối ưu hóa Bảo mật, Mã thông báo Hỗ trợ WP, Dịch vụ WP Quản lý và Dịch vụ Bảo mật Quản lý.

Xem chi tiết gói và đăng ký tại đây: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Kết luận: những gì chúng tôi khuyên, theo thứ tự

Cập nhật JetBackup / Backup Guard lên phiên bản 3.1.20.3 hoặc mới hơn ngay lập tức.
Nếu bạn không thể cập nhật ngay lập tức, hãy áp dụng các quy tắc WAF để chặn việc duyệt đường dẫn trong tên tệp/tênTậpTin các tham số và hạn chế quyền truy cập của quản trị viên.
Thay đổi thông tin xác thực của quản trị viên, kích hoạt 2FA và xem xét danh sách người dùng quản trị viên cho các tài khoản không xác định.
Xác minh các bản sao lưu ngoài trang và kiểm tra khôi phục.
Củng cố cài đặt máy chủ (open_basedir, SELinux/AppArmor, quyền hạn nghiêm ngặt) và xem xét khả năng vá lỗi ảo cho việc giảm thiểu nhanh chóng trong tương lai.
Duy trì ghi chép, giám sát và danh sách kiểm tra phản ứng sự cố để bạn có thể hành động nhanh chóng nếu có bất kỳ điều gì đáng ngờ xảy ra.

Nếu bạn cần giúp đỡ trong việc triển khai các quy tắc WAF, quét các chỉ số bị xâm phạm, hoặc áp dụng các bản vá ảo an toàn trên nhiều trang, đội ngũ WPFirewall có thể giúp. Chúng tôi cung cấp các biện pháp bảo vệ được quản lý tích hợp chữ ký WAF, vá lỗi ảo và giám sát liên tục để bạn có thể tập trung vào việc điều hành trang của mình, không phải theo đuổi các bản vá khẩn cấp.

Hãy giữ an toàn, và vui lòng liên hệ nếu bạn muốn được hỗ trợ kiểm tra các trang bị ảnh hưởng hoặc triển khai các quy tắc bảo vệ.

Lỗ hổng truy cập đường dẫn nghiêm trọng trong Backup Guard//Xuất bản vào 2026-04-17//CVE-2026-4853

Quan trọng: Vượt qua đường dẫn + Xóa thư mục tùy ý trong JetBackup / Backup Guard (CVE-2026-4853) — Những gì chủ sở hữu trang WordPress cần biết và cách bảo vệ bản thân

Tóm tắt điều hành (ngắn gọn)

Cách mà lỗ hổng hoạt động (tổng quan kỹ thuật, giải thích không thể khai thác)

Các kịch bản khai thác và tác động thực tiễn

Danh sách kiểm tra hành động ngay lập tức (những gì cần làm ngay bây giờ)

Phát hiện: cách phát hiện các cuộc tấn công hoặc khai thác thành công

Bản vá ảo & quy tắc WAF (chữ ký thực tiễn bạn có thể áp dụng ngay bây giờ)

Ví dụ mã cứng hóa an toàn cho các tác giả plugin / nhóm phát triển

Các biện pháp giảm thiểu cấp máy chủ mà bạn có thể áp dụng ngay bây giờ

Phản ứng sự cố: nếu bạn nghi ngờ bị khai thác

Các khuyến nghị và thực tiễn tốt nhất lâu dài

Ví dụ quy tắc WAF thực tiễn (thêm)

Tại sao phải cập nhật ngay cả khi CVSS có vẻ “thấp”?

Ví dụ về các truy vấn và cảnh báo giám sát

Sau bản vá: xác minh và xác nhận

Thời gian và thông báo trách nhiệm (ngắn gọn)

Ví dụ thực tế: những gì một quản trị viên hosting nên làm trong 15–60 phút

0–10 phút:

10–30 phút:

30–60 phút:

Ghi chú cuối — cân bằng giữa sự khẩn cấp và an toàn

Bắt đầu bảo vệ trang của bạn với kế hoạch miễn phí WPFirewall

Kết luận: những gì chúng tôi khuyên, theo thứ tự

Nhận WP Security Weekly miễn phí 👋
Đăng ký ngay!!

Liên hệ với chúng tôi để lên lịch tư vấn bảo mật WordPress miễn phí

Lỗ hổng truy cập đường dẫn nghiêm trọng trong Backup Guard//Xuất bản vào 2026-04-17//CVE-2026-4853

Quan trọng: Vượt qua đường dẫn + Xóa thư mục tùy ý trong JetBackup / Backup Guard (CVE-2026-4853) — Những gì chủ sở hữu trang WordPress cần biết và cách bảo vệ bản thân

Tóm tắt điều hành (ngắn gọn)

Cách mà lỗ hổng hoạt động (tổng quan kỹ thuật, giải thích không thể khai thác)

Các kịch bản khai thác và tác động thực tiễn

Danh sách kiểm tra hành động ngay lập tức (những gì cần làm ngay bây giờ)

Phát hiện: cách phát hiện các cuộc tấn công hoặc khai thác thành công

Bản vá ảo & quy tắc WAF (chữ ký thực tiễn bạn có thể áp dụng ngay bây giờ)

Ví dụ mã cứng hóa an toàn cho các tác giả plugin / nhóm phát triển

Các biện pháp giảm thiểu cấp máy chủ mà bạn có thể áp dụng ngay bây giờ

Phản ứng sự cố: nếu bạn nghi ngờ bị khai thác

Các khuyến nghị và thực tiễn tốt nhất lâu dài

Ví dụ quy tắc WAF thực tiễn (thêm)

Tại sao phải cập nhật ngay cả khi CVSS có vẻ “thấp”?

Ví dụ về các truy vấn và cảnh báo giám sát

Sau bản vá: xác minh và xác nhận

Thời gian và thông báo trách nhiệm (ngắn gọn)

Ví dụ thực tế: những gì một quản trị viên hosting nên làm trong 15–60 phút

0–10 phút:

10–30 phút:

30–60 phút:

Ghi chú cuối — cân bằng giữa sự khẩn cấp và an toàn

Bắt đầu bảo vệ trang của bạn với kế hoạch miễn phí WP­Firewall

Kết luận: những gì chúng tôi khuyên, theo thứ tự

Nhận WP Security Weekly miễn phí 👋Đăng ký ngay!!

Liên hệ với chúng tôi để lên lịch tư vấn bảo mật WordPress miễn phí

Bắt đầu bảo vệ trang của bạn với kế hoạch miễn phí WPFirewall

Nhận WP Security Weekly miễn phí 👋
Đăng ký ngay!!