Everest Forms Pro CVE-2026-3300 RCE Đang Bị Khai Thác Thật: Hướng Dẫn Vá 1.9.13 Và Rà Dấu Vết Bằng WP-CLI

Câu trả lời nhanh
CVE-2026-3300 là lỗi RCE CVSS 9.8 trong Everest Forms Pro đến 1.9.12, cho phép kẻ tấn công chưa đăng nhập chèn mã PHP qua tính năng Complex Calculation do hàm process_filter dùng eval() với đầu vào chưa escape dấu nháy đơn. Bạn cần cập nhật lên 1.9.13 ngay, kiểm tra admin lạ bằng WP-CLI và quét log theo các IOC của Wordfence.

Nếu site bạn đang chạy Everest Forms Pro để làm form tính tiền, tính điểm hay bất kỳ calculation nào, mình khuyên bạn dừng lại 5 phút đọc bài này. Lỗi CVE-2026-3300 với điểm CVSS 9.8 cho phép kẻ tấn công chưa đăng nhập chèn mã PHP độc trực tiếp qua các trường form công khai, và theo dữ liệu Wordfence, nó đã bị khai thác thật với hơn 29.300 lần tấn công bị chặn. Trong bài này mình sẽ đi từ nguyên nhân kỹ thuật, cách kiểm tra site bằng WP-CLI, đến checklist rà soát dấu vết nếu bạn nghi ngờ đã dính đòn.

CVE-2026-3300 là lỗi gì mà nguy hiểm đến vậy?

Lỗi nằm ở tính năng Complex Calculation của Everest Forms Pro, cụ thể là hàm process_filter(). Hàm này ghép chuỗi đầu vào của người dùng thành mã PHP rồi đưa thẳng vào eval() để chạy. Nghe đã thấy vấn đề rồi đúng không: dùng eval() trên dữ liệu mà bất kỳ ai truy cập form cũng gửi được lên. Vendor có xử lý đầu qua sanitize_text_field(), nhưng hàm này không escape dấu nháy đơn, nên kẻ tấn công chỉ cần chèn một dấu nháy đơn, theo sau là mã PHP tuỳ ý và chuỗi comment, là thoát ra khỏi chuỗi và chạy code của hắn trên server của bạn. Vì form là endpoint công khai, tấn công không cần bất kỳ tài khoản nào.

Site nào đang nằm trong tầm ngắm?

Cụ thể như sau: mọi phiên bản Everest Forms Pro từ 1.9.12 trở xuống đều dính, riêng site bật tính năng Complex Calculation là lộ diện nguy hiểm nhất. Kẻ tấn công nhắm vào endpoint /wp-admin/admin-ajax.php bằng các POST request được đóng gói sẵn. Về hành vi sau khi khai thác thành công, mẫu tấn công phổ biến nhất là gọi wp_insert_user() để tạo tài khoản admin ma có username “diksimarina”, sau đó dùng quyền admin để upload webshell, cài backdoor plugin hay thâm nhập sâu hơn vào hosting. Bản vá 1.9.13 đã ra từ 18/3, nhưng đến giờ vẫn còn rất nhiều site chưa cập nhật.

Làm sao kiểm tra site có đang bị tấn công?

Mình thường làm hai bước: kiểm tra phiên bản plugin trước, rồi quét log. Chạy lệnh WP-CLI sau trên server:

sudo -u www-data wp plugin list --path=/var/www/site/public_html | grep everest

Nếu phiên bản của bạn dưới 1.9.13 thì vá ngay, không bàn cãi. Tiếp theo, quét access log tìm dấu vết tấn công:

grep -E "admin-ajax.php" /var/log/nginx/access.log | grep -iE "action=.*everest" | head -50

# Lọc theo các IP độc hại đã được xác nhận
grep -E "202\.56\.2\.126|209\.146\.60\.26|15\.235\.166\.18|185\.78\.165\.153" /var/log/nginx/access.log | wc -l

Bốn địa chỉ IPv4 trên cộng thêm một địa chỉ IPv6 2402:1f00:8000:800::40db là những IOC mà Wordfence xác nhận đang khai thác hàng loạt, riêng IP 202.56.2.126 đã bị chặn hàng chục nghìn request. Nếu số dòng khác 0, bạn cần rà soát toàn bộ site ngay.

Vá lỗi như thế nào cho an toàn?

Cách nhanh nhất vẫn là cập nhật trực tiếp:

sudo -u www-data wp plugin update everest-forms-pro --path=/var/www/site/public_html

# Xác nhận lại phiên bản sau khi update
sudo -u www-data wp plugin list | grep everest

Nếu bạn không dùng tính năng Complex Calculation, cân nhắc vô hiệu hóa nó trong cài đặt form để giảm bề mặt tấn công. Còn nếu workflow bắt buộc dùng calculation, bắt buộc phải lên 1.9.13 trở lên. Một điều mình muốn nhấn: firewall rule kiểu Wordfence chỉ là lớp phòng thủ tạm thời, nó chặn payload đã biết chứ không thay thế bản vá. Đừng thấy log không còn request độc là yên tâm.

Đã dính rồi thì rà dấu vết ra sao?

Bạn cần kiểm tra ba chỗ theo đúng thứ tự ưu tiên. Thứ nhất là tài khoản admin lạ:

sudo -u www-data wp user list --role=administrator --path=/var/www/site/public_html

Nhìn kỹ từng user, đặc biệt tên “diksimarina” hoặc các tài khoản tạo gần đây mà bạn không nhớ đã tạo. Thứ hai là các file PHP mới xuất hiện trong uploads và thư mục plugin, vì webshell thường nằm ở đó:

find /var/www/site/public_html/wp-content/uploads -name "*.php" -mtime -90
find /var/www/site/public_html/wp-content/plugins -name "*.php" -newer /var/www/site/public_html/wp-config.php -mmin -43200

Thứ ba, nếu tìm thấy admin lạ hoặc file khả nghi, đổi toàn bộ mật khẩu admin, regenerate các key và salt trong wp-config.php, và quét mã độc bằng Wordfence scan hoặc external script mà bạn tin tưởng. Trường hợp phát hiện webshell đang hoạt động, cách an toàn nhất vẫn là khôi phục từ backup sạch trước thời điểm tấn công.

Bài học nào đáng nhớ cho admin WordPress?

Vụ này lặp lại đúng một pattern mình đã thấy ở Super Forms, Forminator hay Gravity Forms: plugin form liên quan tới tính toán động, code user-controlled đi vào eval() hoặc include, và hàng trăm nghìn site trả giá. Nếu bạn chọn plugin form cho khách hàng, ưu tiên những plugin không dùng eval() cho calculation. Và hãy bật auto-update cho plugin thương mại đang active, vì theo thống kê phần lớn site bị khai thác đều có bản vá sẵn từ nhiều tháng trước. Năm phút kiểm tra hôm nay rẻ hơn nhiều so với một tuần xử lý site bị hack.

Bạn có thể tham khảo thêm cách rà soát lỗ hổng WordPress bằng runbook WP-CLI và bài kiểm tra lỗ hổng Everest Forms bản free CVE-2026-19598 mà mình đã hướng dẫn trước đây để có quy trình phòng thủ tổng thể hơn.

Thanh Tùng

Mình là Thanh Tùng. Bạn bè gọi mình là "bác sĩ máy tính" vì hễ máy nào có vấn đề là mình muốn mò vào xem sao. Mình viết hướng dẫn theo cách mà mình mong người khác đã viết cho mình ngày xưa — từng bước rõ ràng, không bỏ sót, và nói luôn cái gì hay bị lỗi. Ngoài giờ làm mình chơi guitar, nuôi mèo, và có một con VPS riêng dành riêng cho việc cài thử đủ thứ linh tinh.

Xem tất cả bài viết →

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *