Mình vừa đọc báo cáo của Wordfence đầu tuần này và phải nói thẳng: đây là kiểu lỗ họng mà dân quản trị WordPress hay chủ quan nhất. Plugin All-in-One WP Migration and Backup — công cụ backup và chuyển host hơn 5 triệu site đang dùng — dính lỗi CVE-2026-19949, điểm CVSS 8.8, cho phép kẻ tấn công chưa đăng nhập chiếm toàn quyền điều khiển website. Bản vá 7.110 ra mắt từ 20/8 nhưng đến giờ vẫn còn khoảng 3,2 triệu site chưa cập nhật. Nếu site bạn đang dùng plugin này, bài hướng dẫn dưới đây là checklist mình làm lại từ A đến Z để kiểm tra và vá trong 15 phút.
All-in-One WP Migration dính lỗ hổng gì mà nguy hiểm đến vậy?
Đây là lỗi second-order SQL injection (SQLi bậc hai) nằm ở chức năng khôi phục archive .wpress của plugin, được Defiant — công ty mẹ của Wordfence — phát hiện và công bố. Nói ngắn gọn: dữ liệu độc hại không tấn công ngay mà nằm im trong database trước, đợi đúng thời điểm plugin chạy khôi phục archive mới được “thăng cấp” thành lệnh SQL thật. Kết quả cuối cùng là kẻ tấn công đọc được secret key của quá trình import, sau đó đẩy lên một archive chứa malicious must-use plugin — và từ đó có toàn quyền thực thi mã (RCE) trên site bạn.
Quy trình tấn công diễn ra như thế nào?
Mình tóm tắt lại chuỗi khai thác thành bốn bước để bạn hình dung rõ luồng tấn công. Hiểu cơ chế sẽ giúp bạn biết chặn ở đâu thay vì chỉ vá máy móc.
- Kẻ tấn công gửi hai trackback đến một bài viết công khai trên site bạn, mỗi trackback chứa dấu gạch chéo ngược cuối chuỗi và một URL dẫn đến payload. WordPress lưu input này vào database mà không lọc backslash.
- Chờ admin tạo archive backup rồi import lại. Trong lúc import, plugin rewrite URL và table prefix trong SQL đã lưu — lúc này input độc hại được đẩy lên thành SQL thực thi, và secret key bị ghi ra một comment đã được duyệt, hiển thị công khai.
- Kẻ tấn công lấy secret key qua REST API comments của site (không cần đăng nhập).
- Dùng key đó import một archive .wpress chứa must-use plugin độc hại, hoạt động ngay ở lần tải trang kế tiếp — RCE hoàn chỉnh, cài webshell, leo thang toàn site.
Cách kiểm tra site có đang dùng bản lỗi không?
Bạn chỉ cần một dòng WP-CLI. SSH vào server, chạy:
wp plugin list --status=active | grep all-in-oneHoặc xem chi tiết phiên bản:
wp plugin get all-in-one-wp-migration --field=versionThật ra mình khuyên bạn rà luôn toàn bộ bản extension của plugin này, vì các bản mở rộng trả phí cài thêm cũng dùng chung lõi import. Quy tắc đơn giản: mọi bản dưới 7.109 đều dính lỗi, bản 7.110 trở lên đã vá.
Quy trình vá an toàn gồm những bước nào?
Mình luôn vá theo trình tự bốn bước dưới đây, không bỏ qua bước nào — nhất là khi thao tác với plugin backup, lỡ update lỗi là mất luôn phương án khôi phục.
- Backup trước: dump database và nén thư mục wp-content. Đây là plugin backup mà mình vẫn không dám tin nó 100%, nên tự backup độc lập:
mysqldump -u root -p dbname | gzip > /root/db_$(date +%F).sql.gztar -czf /root/wp-content_$(date +%F).tar.gz /var/www/site/public_html/wp-content - Cập nhật lên 7.110:
wp plugin update all-in-one-wp-migration - Xác nhận phiên bản mới:
wp plugin get all-in-one-wp-migration --field=version - Rà dấu vết tấn công: kiểm tra comment trackback lạ và must-use plugin không rõ nguồn gốc:
wp comment list --status=approve --number=100 | grep -i trackbackls -la wp-content/mu-plugins/
Làm sao phát hiện site đã bị khai thác từ trước?
Vì chuỗi tấn công đi qua trackback và REST API comments, bạn có thể grep log access theo ba mẫu này. Mình từng chỉ dẫn chi tiết cách đọc log trong bài phát hiện tấn công CVE-2026-87902 trong log, bạn nên đọc kèm.
# Trackback chứa payload
grep -i "trackback" /var/log/nginx/access.log
# Truy vấn REST API comments từ IP lạ
grep "wp-json/wp/v2/comments" /var/log/nginx/access.log
# Request import archive .wpress từ bên ngoài
grep -i "action=restoration\|\.wpress" /var/log/nginx/access.logNgoài ra kiểm tra bảng wp_comments các bản trackback dài bất thường có backslash cuối chuỗi, và thư mục mu-plugins chỉ nên chứa file bạn tự biết nguồn gốc. Nếu thấy file lạ — cho isolated site, đổi mật khẩu admin, secret key trong wp-config.php và khôi phục từ backup sạch.
Có cách chặn tạm khi chưa update ngay không?
Nếu bạn quản lý hàng chục site khách và không thể update tất cả trong hôm nay, chặn trackback là biện pháp cắt đứt bước đầu tiên của chuỗi tấn công. Trong Settings → Discussion, bỏ chọn “Allow link notifications from other blogs (pingbacks and trackbacks)”. Hoặc chặn ở tầng Nginx:
location = /xmlrpc.php { deny all; return 403; }Lưu ý đây chỉ là lớp tạm — trackback còn đi qua wp-trackback.php và REST, nên bạn vẫn phải update lên 7.110 sớm nhất có thể.
Bài học rút ra cho người quản trị WordPress?
Mình rút ra hai điều. Thứ nhất, plugin backup không đồng nghĩa với an toàn — chính công cụ bạn dùng để cứu site có thể trở thành cánh cửa vào. UpdraftPlus từng dính lỗi authentication bypass tương tự năm ngoái, mình đã có bài kiểm tra và vá chi tiết bạn nên tham khảo. Thứ hai, thống kê 65% site chưa update sau hơn một tháng có bản vá cho thấy cập nhật tự động cho plugin quan trọng không phải tùy chọn — hãy bật auto-update và đặt lịch rà phiên bản hàng tuần bằng WP-CLI, cùng lịch kiểm tra weekly vulnerabilities như cách mình tổng hợp trong bài ra soát 358 lỗ hổng. Lỗ hổng chỉ nghiêm trọng khi bạn là người cập nhật chậm cuối cùng.
