Tên plugin	Chuyển hướng cho Biểu mẫu liên hệ 7
Loại lỗ hổng	Lỗ hổng hủy tuần tự hóa PHAR
Số CVE	CVE-2025-8289
Tính cấp bách	Cao
Ngày xuất bản CVE	2025-08-19
URL nguồn	CVE-2025-8289

Khẩn cấp: Chèn đối tượng PHP trong 'Chuyển hướng cho Biểu mẫu liên hệ 7' (<= 3.2.4) — Những điều chủ sở hữu trang web WordPress cần làm ngay bây giờ

Tác giả: Nhóm bảo mật WP-Firewall
Ngày: 2025-08-20
Thẻ: WordPress, WAF, Lỗ hổng, Tiêm đối tượng PHP, Contact Form 7, Bảo mật

Bản tóm tắt: Lỗ hổng PHP Object Injection (CVE-2025-8289, CVSS 7.5) ảnh hưởng đến Redirection cho Contact Form 7 phiên bản ≤ 3.2.4, cho phép kẻ tấn công không xác thực kích hoạt hủy tuần tự hóa PHAR và có khả năng thực thi mã từ xa, truy cập dữ liệu hoặc xâm nhập trang web. Hãy cập nhật ngay lên 3.2.5 và làm theo các biện pháp giảm thiểu theo từng lớp bên dưới.

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

Một lỗ hổng bảo mật mới đã được phát hiện trong plugin "Redirection for Contact Form 7" được sử dụng rộng rãi, cho phép thực hiện tấn công PHP Object Injection (POI) không xác thực thông qua giải mã PHAR. Do sự cố này không được xác thực và plugin này rất phổ biến, đây là một vấn đề rủi ro cao, có thể - khi có sự hiện diện của một chuỗi tiện ích - bị chuyển thành thực thi mã, đọc/ghi tệp hoặc các cuộc tấn công gây ảnh hưởng nghiêm trọng khác. Các nỗ lực khai thác có khả năng được tự động hóa và lan rộng. Nếu trang web của bạn đang chạy plugin này mà không được cập nhật hoặc giảm thiểu, hãy coi đó là vấn đề cấp bách.

---

PHP Object Injection thông qua PHAR deserialization là gì?

Một lời giải thích ngắn gọn không mang tính học thuật:

• Tiêm đối tượng PHP (POI) xảy ra khi một ứng dụng hủy tuần tự hóa dữ liệu do người dùng kiểm soát có chứa các đối tượng PHP đã được tuần tự hóa. Khi PHP tái cấu trúc các đối tượng, các phương thức ma thuật của chúng (ví dụ: __thức dậy, __phá hủy) có thể chạy và có thể bị lạm dụng nếu các lớp đó thực hiện các hành động nhạy cảm (hoạt động tệp, đánh giá, truy vấn cơ sở dữ liệu, v.v.).
• Giải tuần tự hóa PHAR là một kỹ thuật tấn công trong đó kẻ tấn công tải lên hoặc tham chiếu đến kho lưu trữ PHAR (hoặc nếu không thì khiến mã mở tệp bằng phar:// trình bao bọc luồng). Khi PHP đọc một kho lưu trữ PHAR, siêu dữ liệu của kho lưu trữ có thể chứa các đối tượng được tuần tự hóa. PHP sẽ hủy tuần tự hóa siêu dữ liệu đó, có khả năng gây ra lỗi chèn đối tượng ngay cả khi ứng dụng không gọi rõ ràng. hủy tuần tự hóa() dựa trên thông tin đầu vào của người dùng.
• Khi kết hợp, kẻ tấn công có thể tạo ra một tải trọng PHAR sao cho khi ứng dụng tải kho lưu trữ (hoặc tương tác với tệp/tài nguyên giải quyết thành PHAR), PHP sẽ thực hiện một đường dẫn hủy tuần tự hóa không an toàn, gây ra các hành vi nguy hiểm.

Điều gì làm cho lỗ hổng này đặc biệt nguy hiểm:

• Điểm cuối của plugin có thể kích hoạt mà không cần xác thực (bất kỳ khách nào cũng có thể thử yêu cầu).
• Việc hủy tuần tự hóa PHAR có thể cho phép kẻ tấn công khai thác các lớp tích hợp hoặc mã plugin/chủ đề có "chuỗi tiện ích" — chuỗi các phương thức ma thuật và thuộc tính đối tượng dẫn đến các hành động tùy ý.
• Khi thực thi được mã hoặc truy cập được vào tệp, kẻ tấn công thường cài cửa hậu, tạo người dùng quản trị hoặc đánh cắp dữ liệu.

---

CVE và các thông tin kỹ thuật

• CVE: CVE-2025-8289
• Phần mềm bị ảnh hưởng: Chuyển hướng cho plugin Contact Form 7 — phiên bản ≤ 3.2.4
• Đã sửa trong: phiên bản 3.2.5
• Mức độ nghiêm trọng: Cao (CVSS 7.5)
• Quyền yêu cầu: Chưa xác thực
• Đã báo cáo: Ngày 19 tháng 8 năm 2025
• Khai thác vector: Giải mã PHAR gây ra lỗi PHP Object Injection

Vá hoặc giảm thiểu ngay lập tức. Xử lý tất cả các trang web có plugin dễ bị tấn công như những trang web có nguy cơ cho đến khi được khắc phục.

---

Ai nên đọc bài viết này ngay bây giờ?

• Quản trị viên WordPress và chủ sở hữu trang web sử dụng Contact Form 7 và Chuyển hướng cho Contact Form 7
• Các nhà cung cấp WordPress được quản lý và nhóm bảo mật lưu trữ
• Các nhóm bảo mật quản lý lỗ hổng bảo mật và các chương trình vá lỗi
• Bất kỳ tổ chức nào coi việc cài đặt WordPress của họ là một phần của kho tài sản hướng tới internet

---

Hành động ngay lập tức (cần làm gì trong giờ tiếp theo)

1. Xác định các trang web bị ảnh hưởng
   • Đăng nhập vào từng trang WordPress và vào Plugin → Plugin đã cài đặt.
   • Tìm "Chuyển hướng cho Contact Form 7" và xác nhận phiên bản đã cài đặt. Nếu bạn có nhiều trang web, hãy sử dụng WP-CLI:

     danh sách plugin wp --field=tên,phiên bản | grep -i wpcf7-redirect

   • Kiểm kê tất cả các trang web có plugin có phiên bản ≤ 3.2.4.
2. Cập nhật plugin ngay bây giờ
   • Nhà cung cấp đã phát hành phiên bản 3.2.5 để khắc phục sự cố. Cập nhật qua WP admin hoặc WP-CLI:

     cập nhật plugin wp wpcf7-redirect

   • Nếu bạn không thể cập nhật ngay lập tức (cửa sổ bảo trì, kiểm tra khả năng tương thích), hãy áp dụng các biện pháp giảm thiểu tạm thời bên dưới.
3. Đưa máy chủ vào trạng thái an toàn
   • Nếu bạn phát hiện hành vi khai thác đang diễn ra (tệp PHP đáng ngờ, tài khoản quản trị viên được thêm vào, tệp bị làm tối), hãy ngắt kết nối quyền truy cập công khai hoặc đặt trang bảo trì trong khi điều tra.
4. Bật WAF/bản vá ảo (nếu có)
   • Cấu hình Tường lửa ứng dụng web của bạn để chặn các kiểu khai thác đã biết cho lỗ hổng này. (Xem các quy tắc mẫu bên dưới.)
5. Quét tìm sự thỏa hiệp
   • Chạy quét phần mềm độc hại chuyên sâu, kiểm tra dấu thời gian đã sửa đổi, quét webshell PHP và xác minh tính toàn vẹn của cơ sở dữ liệu và tài khoản người dùng.

---

Các biện pháp giảm thiểu được đề xuất (ngắn hạn–trung hạn–dài hạn)

Phòng thủ nhiều lớp là điều cần thiết. Đừng chỉ dựa vào một biện pháp duy nhất.

1. Bản vá (chính/vĩnh viễn)
   • Cập nhật plugin lên phiên bản 3.2.5 trở lên. Đây là bản sửa lỗi hoàn chỉnh và được hỗ trợ duy nhất.
2. Quy tắc vá lỗi ảo / WAF (tạm thời / ngay lập tức)
   • Chặn các yêu cầu có chứa việc sử dụng phar:// trình bao bọc luồng hoặc các yêu cầu cố gắng tải lên .phar tập tin.
   • Giới hạn tốc độ hoặc chặn các POST đáng ngờ tới các điểm cuối của plugin nếu có thể.
   • Thêm các quy tắc cụ thể để từ chối các yêu cầu chứa dữ liệu đối tượng tuần tự đáng ngờ khi được phát hiện trong phần thân/trường.
3. Ngăn chặn việc xử lý tệp không an toàn
   • Đảm bảo bảo vệ tải tệp lên ngăn chặn .phar tải lên và xác thực các loại MIME.
   • Hạn chế các thư mục lưu trữ các tệp tải lên và không cho phép thực thi PHP trong các thư mục đó (ví dụ: vô hiệu hóa thực thi PHP trong wp-content/tải lên).
4. Củng cố cấu hình PHP
   • Đảm bảo phar.readonly = 1 (mặc định trên hầu hết các môi trường). Điều này làm giảm nguy cơ tạo hoặc sửa đổi kho lưu trữ phar trên máy chủ.
   • Luôn cập nhật PHP và máy chủ web.
   • KHÔNG bật chế độ không an toàn php.ini cài đặt để "giải quyết" vấn đề; sử dụng bản cập nhật plugin và WAF.
5. Quyền và đặc quyền tối thiểu
   • Chạy các tiến trình PHP-FPM và quyền hệ thống tệp với đặc quyền ít nhất.
   • Hạn chế vị trí có thể ghi và phạm vi truy cập cơ sở dữ liệu cho các quy trình web.
6. Giám sát và kiểm toán
   • Theo dõi nhật ký máy chủ web để tìm ra các mẫu bất thường (phương pháp phát hiện chi tiết bên dưới).
   • Kiểm tra tính toàn vẹn của tệp thường xuyên (so sánh với các bản sao đã biết) và xác minh các chỉnh sửa gần đây.

---

Phát hiện — cách để biết ai đó đã cố gắng hay thành công

Hãy tìm các chỉ báo sau trong nhật ký và hệ thống tệp. Không chỉ riêng những chỉ báo này chứng minh được việc khai thác thành công, mà chúng còn cho thấy hành vi lạm dụng đang diễn ra hoặc đã được thực hiện:

• Nhật ký truy cập máy chủ web: Các yêu cầu có chứa “phar://” trong URI yêu cầu, chuỗi truy vấn hoặc nội dung yêu cầu.
• Tải lên các điểm cuối nhận tệp với .phar phần mở rộng hoặc với các loại MIME không phổ biến: ứng dụng/x-phar, ứng dụng/luồng octet với .phar tên tệp.
• POST bao gồm các chuỗi dài được tuần tự hóa (các chuỗi bắt đầu bằng Ồ: hoặc S: và nhiều dấu hai chấm/dấu ngoặc nhọn), đặc biệt là trong các trường thông thường không bao gồm dữ liệu được tuần tự hóa.
• Việc tạo hoặc sửa đổi bất ngờ các tệp PHP trong wp-content/tải lên, wp-content/plugin, hoặc wp-content/chủ đề.
• Người dùng quản trị mới được tạo hoặc có những thay đổi trái phép đối với vai trò của người dùng.
• Các tác vụ theo lịch trình (WP-Cron) không được tạo ra một cách có chủ đích.
• Kết nối đi đến các miền đáng ngờ ngay sau khi tương tác với plugin.
• Nội dung được mã hóa Base64 trong dữ liệu plugin hoặc tùy chọn cơ sở dữ liệu mà trước đây không tồn tại.
• Các chữ ký webshell đã biết được phát hiện bởi trình quét phần mềm độc hại (ví dụ: các tệp có mã bị che giấu, đánh giá(base64_decode())).

Các lệnh phát hiện được đề xuất:

• Tìm kiếm các đề cập đến phar:

  grep -R "phar://" /var/www/html -n

• Tìm kiếm các tải trọng tuần tự đáng ngờ:

  grep -R "O:[0-9]\+:" /var/www/html -n

• Kiểm tra các tập tin đã sửa đổi trong những ngày gần đây:

  tìm /var/www/html -type f -mtime -7 -ls

Nếu bạn tìm thấy tệp đáng ngờ, hãy lưu nhật ký và tạo bản sao pháp y trước khi thực hiện thay đổi.

---

Ví dụ về các quy tắc WAF và biện pháp giảm thiểu ở cấp độ máy chủ

Dưới đây là các quy tắc mẫu bạn có thể áp dụng nhanh chóng. Hãy thử nghiệm ở chế độ phát hiện trước để tránh kết quả dương tính giả.

Nginx (chặn các URI chứa phar://):

# Từ chối mọi yêu cầu có chứa phar:// trong URL hoặc chuỗi truy vấn nếu ($request_uri ~* "phar://") { return 403; }

Apache (.htaccess) — chặn tải lên các tệp .phar và trình bao bọc phar:

# Chặn các yêu cầu trực tiếp với mẫu phar:// trong yêu cầu RewriteEngine trên RewriteCond %{THE_REQUEST} phar:// [NC] RewriteRule .* - [F] # Từ chối truy cập vào bất kỳ tệp .phar nào Lệnh cho phép, từ chối Từ chối tất cả

Quy tắc ModSecurity (ví dụ):

SecRule REQUEST_HEADERS|REQUEST_BODY "phar://" "id:1001001,phase:2,deny,log,msg:'Nỗ lực đóng gói phar bị chặn'" SecRule FILES_NAMES|REQUEST_BODY "\.phar$" "id:1001002,phase:2,deny,log,msg:'Nỗ lực tải lên PHAR bị chặn'"

Khối nỗ lực tốt nhất của WordPress (PHP) bên trong mu-plugin (giảm thiểu tạm thời):

Mã này cố gắng phát hiện việc sử dụng trình bao bọc phar trong tải trọng yêu cầu hoặc các tệp đã tải lên và chặn quá trình xử lý tiếp theo. Đặt vào wp-content/mu-plugins/ tạm thời (kiểm tra trước khi triển khai vào sản xuất).

<?php
// MU plugin: block obvious PHAR attempts. Temporary measure.
add_action('init', function() {
    $blocked = false;
    // Check raw request body
    $raw = file_get_contents('php://input');
    if (stripos($raw, 'phar://') !== false) $blocked = true;
    // Check uploaded filenames
    foreach ($_FILES as $f) {
        if (!empty($f['name']) && stripos($f['name'], '.phar') !== false) $blocked = true;
    }
    if ($blocked) {
        header('HTTP/1.1 403 Forbidden');
        exit('Forbidden');
    }
}, 0);

Lưu ý: Đây là giải pháp tạm thời, mang tính phòng thủ. Nó không thể thay thế bản vá lỗi chính thức và có thể gây ra lỗi cảnh báo sai. Hãy xóa plugin sau khi cập nhật.

---

Danh sách kiểm tra sau khi khai thác — nếu bạn nghi ngờ có sự xâm phạm

Nếu bạn tìm thấy dấu hiệu khai thác thành công, hãy coi trang web đó có khả năng bị xâm phạm và làm theo danh sách kiểm tra ưu tiên sau:

1. Đưa trang bảo trì xuống chế độ ngoại tuyến hoặc hiển thị (nếu cần), nhưng vẫn lưu lại nhật ký và hình ảnh pháp y.
2. Thay đổi mật khẩu và xoay vòng bí mật:
   • Mật khẩu quản trị WordPress.
   • Bảng điều khiển lưu trữ, FTP/SFTP, thông tin đăng nhập SSH.
   • Bất kỳ khóa API nào được trang web sử dụng (nhà cung cấp dịch vụ thư, bộ xử lý thanh toán, CDN).
3. Chạy quét phần mềm độc hại đầy đủ và xem xét mã thủ công:
   • Tìm kiếm webshell, PHP bị che giấu, tác vụ theo lịch trình không mong muốn hoặc tùy chọn cơ sở dữ liệu có nội dung được đưa vào.
4. Khôi phục từ bản sao lưu sạch (nếu có) từ trước khi bị xâm phạm.
   • Đảm bảo phiên bản plugin được cập nhật trước khi đưa trang web trở lại hoạt động.
5. Nếu không có bản sao lưu sạch, hãy xây dựng lại trang web và chỉ nhập nội dung sau khi đã khử trùng kỹ lưỡng.
6. Xem xét và xóa người dùng quản trị, plugin và chủ đề không được nhận dạng.
7. Kiểm tra nhật ký truy cập để xác định IP của kẻ tấn công và phương thức xâm nhập; chặn và tăng cường bảo mật cho phù hợp.
8. Triển khai giám sát (tính toàn vẹn của tệp, cảnh báo đăng nhập, nhật ký WAF).
9. Hãy cân nhắc sử dụng dịch vụ ứng phó sự cố chuyên nghiệp để phân tích pháp y nếu địa điểm đó quan trọng hoặc nếu vi phạm có vẻ phức tạp.

---

Kẻ tấn công thường sử dụng PHP Object Injection như thế nào

• Việc vũ khí hóa thường bắt đầu bằng một cuộc thăm dò: kẻ tấn công gửi yêu cầu kiểm tra đến các điểm cuối xử lý tệp hoặc tài nguyên bên ngoài. Nếu một ứng dụng sử dụng file_get_contents hoặc các hoạt động tập tin khác trên đầu vào do kẻ tấn công kiểm soát, kẻ tấn công cố gắng thay thế một kho lưu trữ PHAR hoặc một đường dẫn kích hoạt phar:// giấy gói.
• Nếu ứng dụng hoặc môi trường chứa các lớp có phương thức magic không an toàn, siêu dữ liệu được tuần tự hóa sẽ bị hủy tuần tự hóa và chuỗi đối tượng độc hại sẽ được kích hoạt.
• Khi mã thực thi có sẵn, kẻ tấn công sẽ:
  • Tải một backdoor cố định (webshell) lên thư mục tải lên hoặc tệp plugin.
  • Tạo người dùng quản trị để truy cập liên tục.
  • Trích xuất nội dung cơ sở dữ liệu.
  • Thiết lập các tác vụ theo lịch trình.
  • Chuyển sang hệ thống khác nếu thông tin đăng nhập được sử dụng lại.

---

Tại sao WAF / Virtual Patching lại hữu ích — và những gì nó không thể làm được

Tường lửa ứng dụng web (WAF) là một lớp phản hồi nhanh, hữu ích, có thể chặn các nỗ lực khai thác trước khi chúng tiếp cận được mã dễ bị tấn công. Các quy tắc WAF hiệu quả có thể:

• Phát hiện và chặn các mẫu khai thác đã biết (phar://, các tải trọng tuần tự đáng ngờ).
• Chặn các IP độc hại đã biết và giới hạn lưu lượng truy cập đáng ngờ.
• Cung cấp bản vá ảo tạm thời cho đến khi plugin được cập nhật.

Những gì WAF không thể làm:

• Thay thế bản sửa lỗi bảo mật do nhà cung cấp cung cấp. Nếu lỗ hổng tồn tại trong PHP hoặc ứng dụng, biện pháp khắc phục hoàn toàn duy nhất là vá mã bị lỗi.
• Hãy chính xác 100% — các khai thác mới, phức tạp có thể vượt qua các quy tắc đơn giản và các kết quả dương tính giả có thể chặn lưu lượng truy cập hợp pháp.

Đó là lý do tại sao chúng tôi khuyên bạn nên sử dụng bản vá + WAF + giám sát như một phương pháp kết hợp.

---

Cách xác thực bạn an toàn sau khi cập nhật

Sau khi bạn cập nhật Chuyển hướng cho Contact Form 7 lên 3.2.5, hãy thực hiện các bước xác minh sau:

1. Xác nhận phiên bản plugin:
   • Quản trị viên WordPress → Plugin hoặc
   • danh sách plugin wp | grep wpcf7-redirect
2. Xóa bộ nhớ đệm (bộ nhớ đệm đối tượng, CDN) và bộ nhớ đệm của trình duyệt.
3. Quét lại phần mềm độc hại và tính toàn vẹn:
   • Chạy so sánh tính toàn vẹn của tệp với các gói plugin và chủ đề mới.
   • Quét các webshell được chèn vào và các tệp đáng ngờ.
4. Theo dõi nhật ký để phát hiện các nỗ lực khai thác lặp lại:
   • Ngay cả sau khi vá lỗi, kẻ tấn công vẫn có thể tiếp tục thăm dò; theo dõi phar:// số lần thử và IP.
5. Thay đổi chìa khóa và thông tin xác thực nếu có bằng chứng cho thấy có sự thỏa hiệp.

---

Ghi chú thực tế dành cho nhà phát triển (dành cho tác giả plugin/chủ đề)

Nếu bạn là nhà phát triển, hãy áp dụng những phương pháp hay nhất sau:

• Tránh xa hủy tuần tự hóa() trên dữ liệu đầu vào không đáng tin cậy. Thay vào đó, hãy sử dụng JSON cho dữ liệu bên ngoài.
• Không bao giờ gọi các hàm xử lý tệp trên URI do người dùng kiểm soát mà không có xác thực nghiêm ngặt.
• Hãy lưu ý đến trình bao bọc luồng PHAR và cách một số thao tác tệp nhất định có thể dẫn đến việc hủy tuần tự hóa siêu dữ liệu.
• Triển khai xác thực và khử trùng đầu vào ngay tại điểm nhập sớm nhất.
• Việc củng cố mã để hoạt động an toàn theo nguyên tắc đặc quyền tối thiểu khiến việc khai thác trở nên khó khăn hơn.
• Luôn cập nhật các thư viện và phần phụ thuộc của bên thứ ba.

---

Ví dụ về mốc thời gian sự cố (những điều cần lưu ý trong đợt bùng phát dịch)

• T0: Lỗ hổng được công bố công khai. Chữ ký quét tự động bắt đầu được lưu hành trong vòng vài giờ.
• T1 (0–24 giờ): Quét hàng loạt internet. Nhiều bot khối lượng lớn sẽ cố gắng thăm dò phar:// và các điểm cuối đã biết.
• T2 (24–72 giờ): Các tập lệnh khai thác tự động có thể cố gắng tải lên các payload hoặc tạo payload PHAR để kích hoạt quá trình giải tuần tự hóa. Một số cuộc tấn công chỉ thành công khi có chuỗi tiện ích.
• T3 (>72 giờ): Kẻ tấn công thiết lập tính bền bỉ (webshell, tài khoản quản trị). Việc dọn dẹp sẽ tốn nhiều thời gian hơn.
• Câu trả lời được đề xuất: Bản vá trong vòng 24 giờ và kích hoạt quy tắc WAF ngay lập tức.

---

Câu hỏi thường gặp (FAQ)

H: Trang web của tôi không sử dụng tính năng chuyển hướng — liệu nó có còn dễ bị tấn công không?
A: Có thể. Lỗ hổng nằm trong chính mã plugin và trong nhiều trường hợp có thể được kích hoạt bởi các yêu cầu chưa được xác thực. Nếu plugin đã được cài đặt và đang hoạt động, hãy coi như nó vẫn còn lỗ hổng cho đến khi được cập nhật.

H: Tôi không thể cập nhật ngay lập tức do đang kiểm tra khả năng tương thích — tôi nên làm gì?
A: Kích hoạt WAF/bản vá ảo để chặn các kiểu khai thác, triển khai các quy tắc tạm thời phía máy chủ để từ chối phar:// sử dụng và .phar tải lên và hạn chế quyền truy cập (danh sách IP được phép) vào trang web hoặc các điểm cuối bị ảnh hưởng trong khi bạn thử nghiệm.

H: Việc thiết lập phar.readonly = 1 có bảo vệ tôi không?
MỘT: phar.readonly Mặc dù có ích nhưng không phải là giải pháp hoàn hảo. Nó ngăn chặn việc tạo/sửa đổi các tệp lưu trữ PHAR trên máy chủ, nhưng việc hủy tuần tự hóa siêu dữ liệu PHAR vẫn có thể xảy ra khi tệp PHAR được đọc. Cần phải kết hợp các biện pháp giảm thiểu.

H: Tôi có nên xóa hoàn toàn plugin không?
A: Nếu bạn không cần plugin, hãy gỡ bỏ nó. Nếu cần, hãy cập nhật lên phiên bản 3.2.5 và áp dụng các biện pháp tăng cường bảo mật được đề xuất.

---

WP-Firewall bảo vệ bạn như thế nào (tóm tắt)

• Các quy tắc WAF được quản lý và tối ưu hóa hiệu suất, chặn các chữ ký khai thác phổ biến bao gồm các nỗ lực hủy tuần tự hóa dựa trên PHAR.
• Quét phần mềm độc hại và cảnh báo các tệp và thay đổi đáng ngờ.
• Khả năng vá lỗi ảo để bảo vệ trang web của bạn trong khi thực hiện các bản cập nhật và thử nghiệm cần thiết.
• Giám sát và báo cáo để bạn có thể thấy các nỗ lực khai thác và hiệu quả giảm thiểu gần như theo thời gian thực.

---

Mới: Bảo vệ trang web của bạn ngay bây giờ với Gói miễn phí WP-Firewall

Tiêu đề: Tăng cường trang web của bạn trong vài phút — Bắt đầu với gói bảo vệ miễn phí

Nếu bạn lo lắng về lỗ hổng này hoặc muốn chủ động bảo vệ trang web WordPress của mình, gói Cơ bản miễn phí của chúng tôi cung cấp các biện pháp bảo vệ thiết yếu mà bạn có thể kích hoạt ngay lập tức. Gói Cơ bản (Miễn phí) bao gồm tường lửa được quản lý, quy tắc WAF, trình quét phần mềm độc hại, băng thông không giới hạn và khả năng giảm thiểu 10 rủi ro hàng đầu của OWASP — chính xác là những biện pháp phòng thủ giúp ngăn chặn loại tấn công được sử dụng trong sự cố giải tuần tự hóa PHAR này. Đăng ký gói miễn phí và kích hoạt các biện pháp bảo vệ chỉ trong vài phút: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Nếu bạn cần tự động hóa mạnh hơn và trợ giúp từ chuyên gia, gói Standard và Pro của chúng tôi sẽ bổ sung tính năng tự động xóa phần mềm độc hại, kiểm soát cho phép/từ chối IP, báo cáo hàng tháng và tự động vá lỗi ảo.)

---

Ghi chú kết thúc — ưu tiên vá lỗi, nhưng đừng quên theo dõi

Lỗ hổng này vừa có mức độ nghiêm trọng cao vừa dễ khai thác vì không yêu cầu xác thực. Cách nhanh nhất và an toàn nhất là cập nhật lên Redirection cho Contact Form 7 phiên bản 3.2.5. Nếu bạn không thể cập nhật ngay lập tức, hãy áp dụng nhiều lớp phòng thủ: vá lỗi ảo thông qua WAF, các quy tắc cấp máy chủ để chặn phar:// Và .phar tệp, tăng cường bảo mật khi tải tệp lên và giám sát chủ động để phát hiện các dấu hiệu khai thác.

Nếu bạn cần hỗ trợ, ứng phó sự cố hoặc trợ giúp cấu hình bảo vệ và giám sát cho nhiều trang web WordPress, nhóm WP-Firewall của chúng tôi luôn sẵn sàng hỗ trợ — các công cụ được quản lý của chúng tôi được thiết kế để cung cấp bản vá lỗi ảo khẩn cấp, quy tắc WAF theo ngữ cảnh và hướng dẫn khắc phục các lỗ hổng plugin nghiêm trọng như thế này.

Hãy giữ an toàn và hành động ngay bây giờ — khoảng thời gian giữa việc tiết lộ và khai thác tự động rất ngắn.