Trong 72 giờ qua, NVD liên tục công bố 5 lỗ hổng nghiêm trọng CVSS 9.8 nhắm vào plugin WordPress, và nghiêm trọng nhất là CVE-2026-83627 trong plugin Hummingbird — plugin tối ưu tốc độ, cache, minify đang chạy trên hàng trăm nghìn site. Điểm đặc biệt của lỗi này: nó không cần đăng nhập, không cần tương tác của quản trị viên, chỉ cần một HTTP request là attacker có thể chạy mã PHP tùy ý trên server của bạn. Mình đã rà lại cơ chế khai thác và trong bài này sẽ hướng dẫn bạn kiểm tra, vá và rà dấu vết tấn công bằng WP-CLI từ A đến Z.
Hummingbird CVE-2026-83627 là lỗi gì mà nguy hiểm đến vậy?
Đây là lỗ hổng unauthenticated code execution (CVSS 9.8) ảnh hưởng đến mọi phiên bản Hummingbird từ 3.21.0 trở xuống. Nguyên nhân gốc nằm ở hàm log_msg() trong file core/modules/class-page-cache.php của module Page Cache.
Vấn đề nằm ở ba điểm nối với nhau thành chuỗi khai thác hoàn chỉnh. Một, plugin ghi debug log ra đường dẫn wp-content/wphb-logs/page-caching-log.php — đây là file .php nằm trong thư mục web truy cập được trực tiếp. Hai, nội dung log không được sanitize đầy đủ, nên attacker có thể “tiêm” mã PHP vào log qua request bình thường. Ba, khi đã có mã trong file, attacker chỉ cần truy cập thẳng URL /wp-content/wphb-logs/page-caching-log.php và server sẽ parse file đó thành code chạy ngay.
Quy trình khai thác hoạt động như thế nào?
Chuỗi tấn công đơn giản đến mức đáng lo. Attacker gửi một request có chứa payload PHP (ví dụ fragment dạng <?php system($_GET['c']); ?>) đến site của bạn. Dữ liệu request này bị ghi vào debug log của module page cache — và vì log là file .php nên payload nằm dormant trong đó.
Tiếp theo, attacker chỉ cần mở URL trực tiếp đến file log kèm tham số lệnh, ví dụ ?c=id. Web server thực thi file PHP đó với quyền của user web service. Từ thời điểm này, attacker có quyền đọc wp-config.php lấy mật khẩu database, chèn malware, drop webshell, làm SEO spam, thậm chí pivot sang các site khác nếu bạn chạy shared hosting. Không cần thông tin đăng nhập, không cần brute force, không cần ai click vào gì cả.
Cách kiểm tra site có đang chạy Hummingbird lỗi không?
Mình làm việc này bằng WP-CLI cho nhanh. SSH vào server rồi chạy:
sudo -u www-data wp plugin list --path=/var/www/thienlv.com/public_html | grep hummingbirdNếu đầu ra hiển thị phiên bản 3.21.0 hoặc thấp hơn, site bạn đang nằm trong vùng nguy hiểm. Nếu plugin không có tên trong danh sách, bạn an toàn với CVE này — nhưng đừng tắt terminal vội, vì còn 4 CVE nữa trong đợt công bố này.
Kiểm tra luôn 4 plugin còn lại trong đợt NVD 72 giờ qua:
sudo -u www-data wp plugin list --path=/var/www/thienlv.com/public_html | grep -E "mail-mint|post-grid|comboblocks"Danh sách cần rà gồm: Mail Mint (CVE-2026-10196, CVSS 9.8), Post Grid and Gutenberg Blocks hay còn gọi ComboBlocks (CVE-2024-11080, CVSS 9.8 — lỗi cũ từ 2024 nhưng vẫn tái xuất trong feed critical của NVD), cùng CVE-2026-16310 và CVE-2026-75816.
Rà dấu vết tấn công trong log và filesystem?
Nếu site bạn từng chạy Hummingbird bản lỗi, hãy săn hai dấu vết đặc trưng. Dấu vết thứ nhất trong access log — tìm các request trực tiếp đến file log:
grep -E "wphb-logs/page-caching-log\.php" /var/log/nginx/access.log
# hoặc với Apache:
grep -E "wphb-logs" /var/log/apache2/access.logBất kỳ request nào đến đường dẫn này đều đáng ngờ, vì traffic bình thường gần như không có lý do gì request thẳng file log. Đặc biệt chú ý các request mang query lạ dạng ?c=, ?cmd= hoặc chuỗi base64.
Dấu vết thứ hai trên filesystem — kiểm tra file log có tồn tại và chứa mã PHP không:
ls -la wp-content/wphb-logs/ 2>/dev/null
grep -l "<?php" wp-content/wphb-logs/*.php 2>/dev/nullRà thêm các file PHP mới hoặc bị sửa gần đây dưới wp-content, vì webshell thường được drop ra ngoài thư mục plugin:
find wp-content -name "*.php" -mtime -30 -not -path "*/plugins/*" -not -path "*/themes/*" | head -20Cách vá CVE-2026-83627 và các lỗi kèm theo?
Bước 1 — cập nhật Hummingbird lên bản mới nhất (bản vá từ 3.21.1):
sudo -u www-data wp plugin update hummingbird --path=/var/www/thienlv.com/public_htmlBước 2 — cập nhật toàn bộ plugin đang outdated. Như báo cáo của 20i mình từng phân tích, 88% site WordPress toàn cầu chưa cập nhật đủ, và chính thói quen này là mồi cho các đợt khai thác hàng loạt:
sudo -u www-data wp plugin update --all --path=/var/www/thienlv.com/public_htmlBước 3 — nếu không dùng Page Cache của Hummingbird thì tắt debug logging đi, và chặn truy cập trực tiếp các file log bằng rule Nginx:
location ~* /wp-content/wphb-logs/.*\.php$ {
deny all;
}Bước 4 — nếu phát hiện dấu vết khai thác: xóa toàn bộ thư mục wphb-logs, đổi mật khẩu database, xoay security keys trong wp-config.php, và rà lại danh sách admin cũng như must-use plugin — malware thường giấu persistence dưới dạng mu-plugin như mình đã phân tích trong bài trước.
Blog thienlv.com có bài nào liên quan nên đọc thêm?
Nếu bạn muốn đào sâu thêm về mảng bảo mật WordPress, mình có vài bài đáng đọc thêm: hướng dẫn rà soát 358 lỗ hổng WordPress trong 1 tuần bằng WP-CLI, cách phát hiện malware giấu tài khoản admin ảo trong must-use plugin, và runbook kiểm tra và update hàng loạt site bằng WP-CLI.
Mình đánh giá thế nào về đợt CVE này?
Điều khiến mình để ý nhất không phải con số CVSS 9.8, mà là dạng lỗi: ghi log ra file .php trong thư mục web-accessible là một anti-pattern kinh điển lặp đi lặp lại trong hệ sinh thái plugin WordPress. Attacker không cần tìm zero-day, chỉ cần chờ các plugin tái phạm sai lầm cũ. Tới thời điểm mình viết, 5 CVE này chưa nằm trong danh sách KEV của CISA, nhưng với WordPress, khoảng cách giữa disclosure và khai thác hàng loạt thường chỉ tính bằng ngày. Kiểm tra ngay hôm nay, đừng đợi đến cuối tuần.
