Super Forms CVE-2026-14894 CVSS 9.8 Đang Bị Khai Thác Thật: Hướng Dẫn Kiểm Tra, Vá 6.3.314 Và Rà Dấu Vết Mushr00w

Nếu website của bạn đang dùng plugin Super Forms (Drag & Drop Form Builder) mà chưa cập nhật lên bản 6.3.314 thì mình khuyên bạn dừng đọc một phút, cập nhật ngay rồi mới quay lại đọc tiếp. Ngày 3/9/2026, đội Threat Research của Wordfence xác nhận lỗ hổng CVE-2026-14894 (CVSS 9.8) trong plugin này đang bị khai thác trong thực tế, với hơn 250.000 lần tấn công đã bị firewall của Wordfence chặn. Đây là lỗi unauthenticated arbitrary file upload, nghĩa là kẻ tấn công không cần tài khoản, không cần mật khẩu, chỉ cần hai request HTTP là có thể upload webshell lên server của bạn.

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

Super Forms là form builder dạng kéo thả có khoảng 13.000 site đang dùng, hỗ trợ field upload file. Lỗi nằm ở hàm submit_form của AJAX handler super_submit_form dành cho khách chưa đăng nhập (nopriv). Plugin không kiểm tra kiểu file, không kiểm tra quyền, chỉ chặn bằng một session nonce.

Vấn đề là nonce đó lấy được quá dễ: endpoint super_create_nonce cũng là nopriv, bất kỳ ai cũng gọi được để xin một sf_nonce hợp lệ kèm session cookie. Kết quả: toàn bộ “hàng rào” chỉ còn hai request HTTP không xác thực — request đầu xin nonce, request thứ hai gửi form chứa file PHP giả dạng chuỗi datauristring base64. Tất cả bản từ 6.3.313 trở xuống đều dính, khai thác được lên tới remote code execution.

Kẻ tấn công đang để lại dấu vết gì trên server?

Theo dữ liệu thật mà Wordfence ghi nhận từ 14/7/2026 (chỉ vài giờ sau khi rule firewall phát hành), webshell được upload thường có tên rất đặc trưng là Mushr00w_upl.php. Nội dung file là một uploader nhỏ gọn được AI sinh ra, có khả năng nhận thêm file thứ hai rồi upload tiếp vào sâu trong thư mục. Nếu bạn thấy file tên này trên server thì gần như chắc chắn đã bị compromise.

Nhưng đừng chỉ tìm đúng một cái tên. Kẻ tấn công hoàn toàn có thể đổi tên và đổi vị trí file. Mình từng dọn mấy site bị lỗi tương tự, webshell thường nằm rải rác trong wp-content/uploads hoặc các thư mục con của plugin, nên cách kiểm tra phải rộng hơn — sẽ có lệnh cụ thể ở phần dưới.

Làm sao kiểm tra site có đang dùng Super Forms lỗi không?

Bạn SSH vào server rồi chạy lệnh WP-CLI sau. Nhớ chạy bằng đúng user của web server (thường là www-data) như mình hay làm:

sudo -u www-data wp plugin list --path=/var/www/example.com/public_html | grep super-forms

Nếu version nhỏ hơn hoặc bằng 6.3.314 thì phải xử lý. Trường hợp không nhớ đường dẫn từng site trên VPS nhiều website, quét nhanh theo filesystem:

find /var/www -maxdepth 5 -type d -name "super-forms" 2>/dev/null

Kiểm tra bản ghi của plugin trong database (nếu thư mục đã bị xóa nhưng DB còn sót metadata của plugin inactive cũng đáng lưu ý):

sudo -u www-data wp db query "SELECT * FROM wp_options WHERE option_name='_site_transient_update_plugins';" --path=/var/www/example.com/public_html | grep -o 'super-forms/super-forms.php;[0-9.]*'

Rà soát dấu vết tấn công bằng WP-CLI như thế nào?

Cập nhật plugin lên 6.3.314 trước đã, rồi mới rà dấu vết. Mình rà theo ba lớp, tầng nào cũng chạy:

Lớp 1 — tìm file PHP đáng ngờ trong uploads, đặc biệt mọi file tạo hoặc sửa đổi từ ngày 8/7/2026 trở đi:

find /var/www/example.com/public_html/wp-content/uploads -name "*.php" -newermt "2026-07-08" -ls
find /var/www -name "Mushr00w*" 2>/dev/null

Lớp 2 — soi access log tìm request POST vào admin-ajax.php mang action super_submit_form và super_create_nonce:

grep -E "admin-ajax.php" /var/log/nginx/access.log | grep -E "super_submit_form|super_create_nonce" | grep "POST" | head -50

Hai request liền kề từ cùng một IP — một cái xin nonce, một cái submit form — là bằng chứng gần như chắc chắn của vụ khai thác.

Lớp 3 — kiểm tra user admin lạ và scheduled event, vì webshell thường được dùng để tạo backdoor bền vững hơn:

sudo -u www-data wp user list --role=administrator --path=/var/www/example.com/public_html
sudo -u www-data wp cron event list --path=/var/www/example.com/public_html

Nếu phát hiện bị nhiễm thì xử lý ra sao?

Trường hợp tìm thấy webshell hoặc bằng chứng trong log, đừng chỉ xóa file rồi coi như xong. Mình xử lý theo đúng trình tự này:

1. Cách ly site (maintenance mode hoặc chặn IP ngoài), giữ nguyên hiện trường để điều tra.
2. Xóa toàn bộ file lạ trong uploads, đổi mật khẩu tất cả admin, đổi salt và key trong wp-config.php, revoke API keys của plugin.
3. Kiểm tra các user tạo sau 8/7/2026 bằng wp user list --fields=ID,user_login,user_registered, xóa hoặc hạ quyền những tài khoản khả nghi.
4. Chạy lại quét từ đầu sau 48 giờ để chắc chắn không còn backdoor thứ hai mà uploader AI sinh ra planted thêm.

Chi tiết cách rà soát dấu vết tấn công từng bước, bạn nên đọc thêm bài runbook WP-CLI rà soát 6 lỗ hổng tháng 8/2026 mà mình từng hướng dẫn — kỹ thuật tương tự, áp dụng được nguyên vẹn cho vụ này.

Làm sao tránh dính các lỗi plugin kiểu này về sau?

Vụ Super Forms lặp lại đúng một môtuyp cũ: plugin trả phí ít được audit, lỗi critical bị exploit chỉ vài ngày sau khi công bố. Với mình, ba thói quen dưới đây là rẻ nhất mà hiệu quả nhất:

Một là bật auto-update cho plugin form và mọi plugin chạm vào file upload — đây chính là nhóm rủi ro cao nhất, như vụ FS-Poster RCE mình viết hôm trước. Hai là chặn chạy PHP trong wp-content/uploads bằng một rule Nginx vài dòng, việc này vô hiệu hóa luôn phần lớn thiệt hại kể cả khi bị upload file:

location ~* /wp-content/uploads/.*\.php$ { deny all; }

Ba là nhận thông báo bằng Wordfence Intelligence hoặc Patchstack để biết tin sớm hơn tốc độ kẻ tấn công. Lỗi này được vá từ 8/7 nhưng hàng nghìn site vẫn dính nửa tháng sau đó chỉ vì không ai đọc changelog. Đừng để site của bạn nằm trong số đó.