Ngày 14/9/2026, đội Wordfence Threat Intelligence công bố phát hiện khá giật mình: hai chuỗi lỗ hổng độc lập trong plugin The Events Calendar — plugin quản lý sự kiện được cài trên hơn 600.000 website WordPress — đều cho phép kẻ tấn công không cần đăng nhập vẫn có thể đi đến Remote Code Execution (RCE), tức chạy lệnh tùy ý trên server của bạn. Điểm đặc biệt: cả hai chuỗi đều được phát hiện bởi Wordfence Argus, hệ thống dùng AI để soi code plugin, chứ không phải researcher ngồi đọc tay.
Mình viết bài này cho ai đang chạy The Events Calendar, hoặc quản trị nhiều site WordPress cho khách. Bạn làm theo 3 bước dưới đây là kiểm tra và xử lý xong trong khoảng 10 phút. Nếu bạn từng đọc bài mình viết về lỗ hổng Tutor LMS RCE 100.000 site thì quy trình lần này gần giống, chỉ khác plugin.
Lỗ hổng này nguy hiểm như thế nào?
Cả hai chuỗi tấn công đều xuất phát từ widget-rendering pipeline của The Events Calendar — là đoạn code chịu trách nhiệm render các widget lịch sự kiện ra trang. Từ điểm vào này, kẻ tấn công đi tiếp theo hai hướng khác nhau và đều chạm tới RCE mà không cần bất kỳ tài khoản nào trên site. Với mức độ như vậy, đây thuộc nhóm Critical — nghiêm trọng nhất trong thang đánh giá. Với hơn 600.000 site đang dùng plugin này, ảnh hưởng rất rộng, và bạn nên coi như mình có 48 giờ để xử lý.
Mình cần làm gì ngay trong 10 phút?
Tóm tắt nhanh: kiểm tra xem site có dùng The Events Calendar không, nếu có thì cập nhật lên bản mới nhất ngay, rồi rà dấu vết tấn công trong log và thư mục uploads. Wordfence đã triển khai rule firewall cho khách hàng Premium/Care/Response từ khi phát hiện, nhưng đừng ỷ lại vào firewall — vá plugin vẫn là ưu tiên số một. Ba bước cụ thể mình chi tiết ở các phần dưới, kèm lệnh WP-CLI chạy được cả khi bạn quản lý hàng chục site.
Bước 1: Kiểm tra site có dùng The Events Calendar không?
SSH vào server rồi chạy lệnh sau. Lưu ý: đừng bỏ qua bước này dù bạn “đ chắc chắn” là không cài — nhiều theme hoặc site khách hàng cũ có plugin này nằm im từ năm ngoái mà bạn quên mất.
sudo -u www-data wp plugin list --path=/var/www/yoursite/public_html | grep -i "events-calendar"Nếu có dòng the-events-calendar hiện ra, ghi lại cột version để so sánh ở bước 2. Nếu bạn quản lý nhiều site, dùng vòng lặp:
for d in /var/www/*/public_html; do
echo "== $d"
sudo -u www-data wp plugin list --path=$d 2>/dev/null | grep -i "events-calendar"
doneCũng nên kiểm tra luôn các plugin họ hàng của StellarWP như Events Calendar Pro, Event Tickets — chúng dùng chung một phần hệ sinh thái.
Bước 2: Cập nhật lên bản mới nhất thế nào cho an toàn?
Nhà phát hành đã phát hành bản vá, nên cách nhanh nhất là cập nhật lên bản mới nhất thay vì mò version cụ thể. Chạy lệnh:
sudo -u www-data wp plugin update the-events-calendar --path=/var/www/yoursite/public_htmlSau khi update, xác nhận lại version và xóa cache nếu site bạn dùng LiteSpeed Cache hay WP Rocket:
sudo -u www-data wp plugin list --path=/var/www/yoursite/public_html | grep events-calendar
sudo -u www-data wp cache flush --path=/var/www/yoursite/public_html 2>/dev/null || true
cd /var/www/yoursite/public_html && wp litespeed-purge all 2>/dev/null || trueLưu ý quan trọng: trước khi update, tạo backup tối thiểu thư mục plugin và database. Nếu bản mới nhất xung đột với theme cũ của bạn (widget calendar đột nhiên render lỗi), đừng rollback về bản lỗi — hãy tạm deactivate plugin rồi liên hệ developer:
sudo -u www-data wp plugin deactivate the-events-calendar --path=/var/www/yoursite/public_htmlBước 3: Rà dấu vết tấn công bằng WP-CLI như thế nào?
Vì lỗ hổng đi qua widget-rendering, dấu vết thường nằm ở access log (các request lạ nhắm vào REST endpoint và route widget của plugin) và ở thư mục uploads (file PHP lạ). Kiểm tra nhanh log 30 ngày gần nhất:
grep -Ei "tribe|events.*(widget|v[0-9])" /var/log/nginx/access.log | grep -vE " (200|304) " | tail -50Rà file PHP nghi vấn trong uploads — đây là nơi backdoor sau RCE hay nằm nhất:
find /var/www/yoursite/public_html/wp-content/uploads -name "*.php" -mtime -60Kiểm tra xem có admin lạ được tạo gần đây không, giống trường hợp malware must-use plugin giấu tài khoản admin ảo mình từng bóc tách:
sudo -u www-data wp user list --path=/var/www/yoursite/public_html --fields=ID,user_login,roles,user_registered | sort -k4Nếu thấy user đăng ký trong đúng giai đoạn mà bạn không nhận diện được, khóa ngay: wp user update <ID> --role=subscriber rồi đổi mật khẩu toàn bộ admin.
Troubleshooting: hay gặp lỗi gì ở đâu?
Lỗi “Error updating plugin” khi update: thường do quyền file sai. Chạy sudo chown -R www-data:www-data wp-content/plugins rồi thử lại.
Update xong lịch sự kiện biến mất: kiểm tra trang Settings > Events, phần imports và template overrides trong theme (wp-content/themes/your-theme tribe/) — bản mới đôi khi đổi cấu trúc template.
Không SSH được, chỉ có wp-admin: vào Plugins, tìm The Events Calendar, nhấn Update Now. Chậm hơn nhưng vẫn đạt yêu cầu.
Đã bị nhiễm rồi thì sao: đừng chỉ vá và coi như xong. Hạ độ nghi ngờ bằng cách scan với Wordfence, soát file must-use (wp-content/mu-plugins/), và nếu chưa chắc, khôi phục từ backup sạch trước ngày 21/8/2026 — mốc thời điểm Wordfence Argus phát hiện hai chuỗi lỗ hổng.
Mình nên rút ra bài học gì từ vụ này?
Thứ nhất, plugin càng phổ biến càng là mục tiêu — 600.000 site là mồi rất béo. Thứ hai, hai chuỗi lỗ hổng này do AI (Wordfence Argus) tìm ra, đúng như xu hướng mình từng đề cập trong bài về Cloudflare dùng GPT-5.6 Cyber tự tìm lỗ hổng: cả bên tấn công lẫn bên phòng thủ đều đang dùng AI, nên vòng đời lỗ hổng ngắn đi và bạn phải update nhanh hơn xưa. Thứ ba, hãy đặt lịch rà soát plugin định kỳ — một lệnh wp plugin list --update=available mỗi tuần chạy qua cron sẽ giúp bạn không bao giờ rơi vào tình trạng “quên mất plugin đó đang nằm trên site”.
