Nếu bạn nghĩ rằng đã cập nhật WordPress 7.1.2 xong là hết chuyện với CVE-2026-87902 thì mới đúng một nửa. Ngày 23/9, Patchstack công bố số liệu đáng lo: traffic khai thác lỗi này tăng hơn 10 lần chỉ sau một ngày, kẻ tấn công đã chuyển từ dò quét sang ghi file PHP thật sự vào /tmp, và một template Nuclei tên nuclei-cve-2026-87902 đã được phát tán công khai. Nghĩa là bất kỳ ai có danh sách website cũng có thể scans hàng loạt. Trong bài này, mình sẽ hướng dẫn bạn từng bước kiểm tra log server để biết site mình đã bị “ghé thăm” chưa, và nếu có thì phải xử lý ra sao.
Tấn công CVE-2026-87902 đang diễn ra như thế nào?
Theo Patchstack, chiến dịch tấn công chạy qua ba giai đoạn rõ rệt. Giai đoạn một dò xem lỗi inclusion còn sống không bằng cách trỏ vào các file core vô hại như wp-links-opml.php hay wp-includes/feed-rss2.php. Giai đoạn hai trỏ vào pearcmd.php kèm tham số +config-show để xác nhận PEAR tồn tại và thủ thuật argv hoạt động. Giai đoạn ba đổi sang +config-create, ghi file PHP do kẻ tấn công kiểm soát vào /tmp và /var/tmp. Các file được ghi có tên như poc87902.php, wp-pear-rce-flag.php hay luci_random.php. Đã có hai nhóm payload: một nhóm ghi chuỗi đánh dấu vô hại để lập danh sách host dễ bị tấn công, nhóm còn lại ghi webshell thật.
Cập nhật WordPress 7.1.2 ngay nếu chưa kịp làm?
Đây vẫn là việc ưu tiên số một. CVE-2026-87902 ảnh hưởng đến WordPress từ 4.7.0 đến 7.1.1, điểm CVSS 9.2 Critical, không cần đăng nhập để khai thác. Bản vá có mặt ở 7.1.2, 7.0.6, 6.9.9, 6.8.10 và cả backport về 4.7.37, nên dù site bạn đang nhánh cũ cũng vẫn có bản vá. Nếu bạn quản trị nhiều site, hãy chạy lệnh WP-CLI dưới đây từ máy trung tâm để kiểm tra phiên bản hàng loạt trước, rồi cập nhật những site chưa vá:
wp core check-update --path=/var/www/thienlv.com/public_html
wp core update --path=/var/www/site-khac/public_htmlBạn nên đọc lại hai bài trước của mình về việc vá lỗi và siết bảo mật tầng server để có bức tranh đầy đủ: hướng dẫn vá WordPress 7.1.2 và ra soát theme và chặn RCE ở tầng server với pearcmd.php và open_basedir.
Kiểm tra log access như thế nào để phát hiện dấu vết?
Có ba tín hiệu rất khó bị nhiễu mà bạn nên tìm. Thứ nhất, cặp tham số page_id và pagename xuất hiện cùng nhau trong cùng một request là chuyện gần như không bao giờ xảy ra trong traffic bình thường. Thứ hai, chuỗi %252f và %252e (double-encoding) vì payload luôn phải encode mới lọt qua bộ sanitise của WordPress. Thứ ba, tiền tố templates%2f mở đường cho chuỗi traversal. Trên Nginx, log access thường nằm ở /var/log/nginx/access.log. Bạn chạy lần lượt các lệnh sau:
# Tín hiệu 1: cặp page_id + pagename cùng lúc
grep -E 'page_id=[0-9]+&pagename=' /var/log/nginx/access.log | head -50
# Tín hiệu 2 và 3: double-encode và tiền tố templates
grep -iE '%252e%252e|%252f|templates%252f' /var/log/nginx/access.log | head -50
# Giai đoạn nguy hiểm: chạm vào pearcmd
grep -i 'pearcmd' /var/log/nginx/access.log | head -50Nếu grep trả về kết quả, đừng hoảng loạn. Request dò quét thất bại không có nghĩa là site bị xâm nhập. Điều cần xác định tiếp là liệu file PHP đã được ghi xuống đĩa hay chưa.
Kiểm tra server đã bị ghi file hay chưa?
Mình đề xuất một quy trình ba bước, làm đúng thứ tự. Bước một, tìm các file PHP lạ trong thư mục tạm và thư mục uploads với hai lệnh find dưới đây. Bước hai, nếu thấy file khớp mẫu poc, luci, zeta hay wp-pear-rce-flag thì đọc nội dung file bằng cat để xác định là marker vô hại hay webshell. Bước ba, ghi lại timestamp của file rồi đối chiếu ngược với log access để biết chính xác request nào đã ghi nó:
find /tmp /var/tmp -name '*.php' -mtime -7 2>/dev/null
find /var/www -path '*/uploads/*' -name '*.php' -mtime -7 2>/dev/null
# Nếu tìm thấy file khả nghi, xem nội dung và đối chiếu
cat /tmp/poc87902.php
grep 'config-create' /var/log/nginx/access.logLưu ý một điểm quan trọng: file nằm trong /tmp thường không truy cập được qua web, nên nó là bằng chứng bị khai thác chứ chưa chắc là backdoor bền vững. Tuy nhiên nếu kẻ tấn công đã ghi được vào /tmp thì primitive ghi file đã hoạt động, và họ có thể ghi vào nơi nguy hiểm hơn bất cứ lúc nào.
Chặn tái phát bằng fail2ban ra sao?
Sau khi xác nhận sạch, mình luôn khuyên chặn luôn các đợt quét sau bằng fail2ban, vì chiến dịch này chưa dừng và user agent giả mạo browser là đa số nên không thể lọc theo UA. Tạo filter bắt cặp tham số page_id kèm pagename có encode, đây là tín hiệu đặc thù của CVE này:
# /etc/fail2ban/filter.d/wp-cve-87902.conf
[Definition]
failregex = ^<HOST> .*"(GET|POST) /.*page_id=[0-9]+&pagename=.*%25
ignoreregex =
# /etc/fail2ban/jail.local
[wp-cve-87902]
enabled = true
port = http,https
filter = wp-cve-87902
logpath = /var/log/nginx/access.log
maxretry = 1
bantime = 86400Khởi động lại dịch vụ bằng systemctl restart fail2ban rồi theo dõi bằng fail2ban-client status wp-cve-87902. Với maxretry bằng 1, một request dò quét duy nhất cũng đủ bị ban 24 giờ.
Nếu site đã bị ghi webshell thì xử lý thế nào?
Trường hợp xấu nhất: bạn tìm thấy file PHP chứa hàm system, exec hoặc eval obfuscate. Lúc này hãy coi site là đã compromised hoàn toàn và phản ứng theo bốn bước. Một, cô lập site bằng cách bật maintenance page hoặc chặn truy cập ở firewall. Hai, đổi toàn bộ mật khẩu: admin WordPress, database, SFTP, và thu hồi toàn bộ Application Passwords cũng như API key trong wp-config.php. Ba, sao lưu toàn bộ file và database làm bằng chứng trước khi dọn dẹp, vì bạn sẽ cần đối chiếu sau. Bốn, dọn file lạ, cập nhật core, plugin, theme về bản mới nhất rồi khôi phục từ backup sạch nếu có. Đừng chỉ xóa file webshell rồi coi như xong, vì đó thường chỉ là một trong nhiều cánh cửa kẻ tấn công để lại.
Mình rút ra được gì từ đợt tấn công này?
Điều khiến mình ấn tượng nhất là tốc độ: patch ra sáng 22/9, request đầu tiên đến firewall Patchstack lúc 11:49 UTC cùng ngày, và chưa đầy 24 giờ sau đã có template scan công khai. Khoảng cách giữa “vừa vá xong” và “bị quét hàng loạt” giờ tính bằng giờ chứ không phải bằng ngày. Với mình, bài học thực tế là ba việc nên làm mặc định sau mỗi security release: cập nhật ngay trong ngày, grep log tìm tín hiệu đặc trưng của CVE đó, và kiểm tra thư mục tạm xem có file lạ không. Ba việc này tốn chưa đến mười phút mỗi lần, rẻ hơn rất nhiều so với chi phí dọn dẹp một site bị xâm nhập. Bạn có thể tham khảo thêm cách kiểm tra bảo mật plugin bằng Plugin Check mà mình đã hướng dẫn trước đây để bổ sung cho checklist tại đây.
