Wordfence vừa công bố báo cáo lỗ hổng hàng tuần cho khoảng 14–20/9/2026: 358 lỗ hổng được công bố trong 243 plugin và 4 theme WordPress, trong đó 47 lỗ hổng vẫn chưa có bản vá và 18 lỗ hổng đạt mức critical. Con số này cho thấy một thực tế: chờ vendor phát hành bản vá là chưa đủ, bạn cần một quy trình ra soát định kỳ cho site của mình. Trong bài này, mình sẽ hướng dẫn bạn thực hiện quy trình ra soát 30 phút mỗi tuần bằng WP-CLI và nguồn dữ liệu miễn phí của Wordfence Intelligence.
Tuần vừa rồi có bao nhiêu lỗ hổng WordPress mới?
Theo báo cáo của Wordfence, tuần từ 14 đến 20/9/2026 có 358 lỗ hổng mới được thêm vào cơ sở dữ liệu Wordfence Intelligence, đến từ 243 plugin và 4 theme, với 184 nhà nghiên cứu đóng góp. Phân theo mức độ: 4 lỗ hổng low, 262 medium, 74 high và 18 critical. Về trạng thái vá: 311 lỗ hổng đã có bản vá, còn lại 47 lỗ hổng chưa được vá — đây chính là nhóm nguy hiểm nhất mà bạn cần xử lý ngay bằng cách vô hiệu hóa plugin liên quan.
Nhóm lỗi nào chiếm nhiều nhất trong 358 lỗ hổng này?
Thống kê theo CWE cho thấy ba nhóm đứng đầu là Cross-Site Scripting với 94 lỗ hổng, Missing Authorization với 68 lỗ hổng và SQL Injection với 35 lỗ hổng. Tiếp theo là Authorization Bypass Through User-Controlled Key (27) và lộ thông tin nhạy cảm (26). Điểm đáng chú ý: các lỗi liên quan phân quyền tổng cộng chiếm tỷ lệ rất lớn. Điều đó có nghĩa là plugin cài thừa, bật vai trò không cần thiết, để đăng ký user tự do đều là những lá thư mời kẻ tấn công.
Lỗ hổng nào đáng quan tâm nhất tuần này?
Đáng chú ý nhất là CVE-2026-85128, CVSS 9.8 Critical: plugin “Choose User Role at Registration for WooCommerce” phiên bản 1.3.2 trở xuống bị leo thang đặc quyền mà không cần xác thực, tức kẻ tấn công có thể tự đăng ký thành admin. Ngoài ra Wordfence cũng triển khai rule WAF-RULE-957 cho lỗi Stored XSS trong lõi WordPress 7.1 trở xuống qua xử lý blockquote của hàm wpautop — lỗi này mình đã có bài phân tích riêng, bạn nên đọc thêm để hiểu cơ chế khai thác.
Làm sao để liệt kê toàn bộ plugin đang chạy trên site?
Bước đầu tiên của quy trình ra soát là biết mình đang chạy gì. Nếu bạn quản lý VPS hoặc shared hosting có SSH, WP-CLI là công cụ nhanh nhất. Kết nối vào server rồi chạy:
wp plugin list --path=/var/www/thienlv.com/public_html --format=csv > /tmp/plugins-$(date +%F).csv
cat /tmp/plugins-$(date +%F).csvKết quả là file CSV gồm tên, phiên bản, trạng thái active/inactive và có bản cập nhật hay chưa. Với site có nhiều plugin, mình khuyên bạn lưu file này lại mỗi tuần để đối chiếu. Plugin đang inactive nhưng vẫn nằm trên server vẫn có rủi ro, vì file PHP của nó vẫn có thể được gọi trực tiếp qua các request crafted.
Cách đối chiếu plugin của mình với danh sách lỗ hổng thế nào?
Wordfence Intelligence cung cấp miễn phí giao diện tra cứu, API và webhook cho mục đích cá nhân lẫn thương mại. Bạn vào wordfence.com/threat-intel, tìm theo slug plugin trong file CSV vừa xuất. Nhanh hơn, dùng API để tự động hóa:
curl -s "https://www.wordfence.com/api/intelligence/v2/vulnerabilities/scanner" \
| jq '.data[] | select(.software[]?.slug=="choose-user-role-at-registration")'Nếu slug plugin của bạn xuất hiện trong kết quả, hãy kiểm tra hai thông số: phiên bản đã vá (patched version) và trạng thái patch. Plugin đã vá thì cập nhật ngay, plugin chưa vá thì sang bước kế tiếp. Cách này áp dụng tốt cho cả agency quản lý hàng chục site, vì toàn bộ database hơn 40.000 lỗ hổng đều mở miễn phí.
Plugin có lỗ hổng chưa vá thì xử lý ra sao?
Trường hợp xấu nhất là plugin của bạn nằm trong nhóm 47 lỗ hổng chưa vá. Lúc này bạn có ba lựa chọn, theo thứ tự ưu tiên: một là vô hiệu hóa plugin ngay nếu không thực sự cần thiết; hai là tìm plugin thay thế chức năng tương đương; ba là chặn truy cập trực tiếp vào file plugin ở tầng web server trong lúc chờ vá. Ví dụ với Nginx:
location ~* /wp-content/plugins/choose-user-role-at-registration/ {
deny all;
return 403;
}Với OpenLiteSpeed bạn thêm rule tương tự vào .htaccess của site. Nhớ reload web server và kiểm tra lại bằng curl từ ngoài. Vô hiệu hóa trong wp-admin chỉ tắt hook, không chặn truy cập file, nên kết hợp cả hai lớp là an toàn nhất.
Cập nhật hàng loạt plugin an toàn bằng lệnh nào?
Sau khi ra soát, phần còn lại là cập nhật 311 lỗ hổng đã có bản vá. Với WP-CLI, việc này chỉ mất một phút:
wp plugin update --all --path=/var/www/thienlv.com/public_html
wp theme update --all --path=/var/www/thienlv.com/public_html
wp core update --path=/var/www/thienlv.com/public_htmlTrước khi cập nhật, tạo bản sao lưu tối thiểu cho database và thư mục wp-content. Hai lệnh dưới đây là đủ cho hầu hết trường hợp:
wp db export /root/backup-$(date +%F).sql --path=/var/www/thienlv.com/public_html
tar -czf /root/wp-content-$(date +%F).tar.gz /var/www/thienlv.com/public_html/wp-contentCập nhật xong, quay lại kiểm tra trang chủ và một vài trang quan trọng ở trạng thái đăng nhập và thoát. Đa số sự cố sau update đến từ cache, nên xả cache cả ở plugin lẫn web server trước khi kết luận lỗi. Nếu bạn chưa quen với khâu kiểm tra plugin trước khi cài, xem lại bài hướng dẫn Plugin Check của mình.
Mình nên lập lịch ra soát định kỳ như thế nào?
Mình đã theo quy trình “thứ Sáu 30 phút” được vài tháng và thấy nó đủ để không bỏ sót lỗ hổng nghiêm trọng: xuất danh sách plugin, đối chiếu báo cáo Wordfence hàng tuần, cập nhật những gì đã vá, vô hiệu hóa những gì chưa vá, cuối cùng là kiểm tra log xem có dấu hiệu dò quét bất thường. Nếu bạn muốn chủ động hơn, đăng ký webhook của Wordfence Intelligence để nhận thông báo lỗ hổng mới theo thời gian thực, hoàn toàn miễn phí.
Quay lại con số 358 lỗ hổng một tuần: không ai kịp đọc hết danh sách đó, và cũng không cần. Bạn chỉ cần quan tâm đến những dòng trùng với plugin trên site mình. Bảo mật WordPress không phải là chiến đấu với hàng trăm CVE, mà là một thói quen lặp lại mỗi tuần — đúng tinh thần defense in depth mà mình đã chia sẻ trong loạt bài về hardening PHP và đọc log phát hiện tấn công trước đây.
