WordPress 7.1.2 ra mắt ngày 22/9 vá lỗ hổng nghiêm trọng CVE-2026-87902, cho phép kẻ tấn công chưa đăng nhập include một file PHP bất kỳ nằm ngoài thư mục theme qua cơ chế phân giải page template. Nếu chủ nhân website đã cập nhật thì tốt, nhưng mình đã có bài hướng dẫn vá và rà dấu vết chi tiết, nhưng theo kinh nghiệm của mình, rất nhiều site vẫn đang chạy bản cũ, và vấn đề thật sự nằm ở chỗ: lỗ hổng này chỉ thành RCE khi kết hợp điều kiện môi trường server. Trong bài này, mình sẽ hướng dẫn bạn rà từng điều kiện đó và chặn luôn lớp tấn công pearcmd.php ở tầng PHP, bất kể bạn đã nâng cấp WordPress hay chưa.
CVE-2026-87902 hoạt động thế nào và tại sao cần quan tâm?
Lỗ hổng nằm ở hàm get_page_template() khi phân giải page template của theme. Kẻ tấn công chưa cần đăng nhập vẫn có thể ép WordPress include một file .php cục bộ nằm ngoài thư mục theme đang kích hoạt. Bản thân việc include file chưa phải RCE ngay, nhưng nếu trên server tồn tại một file PHP “hữu ích” cho kẻ tấn công — nổi tiếng nhất là pearcmd.php — thì chain hoàn chỉnh dẫn tới thực thi mã từ xa. Đây là lý do bản vá được đánh giá nghiêm trọng và WordPress khuyến cáo cập nhật ngay lập tức.
Theme của bạn có nằm trong vùng rủi ro không?
Theo advisory chính thức, điều kiện thứ nhất là theme con hoặc theme cha đang kích hoạt có một thư mục ở cấp gốc mà tên bắt đầu bằng page- — ví dụ page-templates. Danh sách bị ảnh hưởng bao gồm Twenty Twelve, Twenty Fourteen cũ và một số theme phổ biến như Neve, Hestia, Sydney. Bạn kiểm tra nhanh bằng WP-CLI:
wp theme list --status=active --fields=name,version
ls $(wp theme path --dir)/$(wp theme list --status=active --field=name)/ | grep '^page-'Nếu lệnh grep trả về kết quả, theme của bạn nằm trong vùng rủi ro. Nếu không trả về gì thì chuỗi tấn công qua route này không khả thi với site bạn — nhưng đừng chủ quan, hãy vẫn cập nhật WordPress, vì điều kiện theme chỉ là một nửa của phương trình.
Điều kiện thứ hai: pearcmd.php và register_argc_argv là gì?
Điều kiện còn lại là trên server phải tồn tại file .php đọc được và khai thác được. Cuộc chơi phổ biến nhất nhắm vào pearcmd.php — file có sẵn trong PEAR, đi kèm nhiều bản PHP cũ — cho phép chạy lệnh PEAR qua query string, từ đó ghi file webshell. Chiêu này chỉ ăn khi directive register_argc_argv bật On. Đáng lo là nhiều môi trường quen thuộc đang bật mặc định: image PHP chính thức của Docker, và cấu hình cPanel mặc định với PHP dưới 8.5. Kiểm tra bằng lệnh:
php -i | grep register_argc_argv
# hoặc trên site đang chạy:
wp eval 'var_dump(ini_get("register_argc_argv"));'Kết quả là string(2) "On" nghĩa là bạn đang giữ cửa mở cho kỹ thuật pearcmd RCE — không chỉ với lỗi WordPress này mà với mọi lỗi LFI khác trong tương lai.
Tắt register_argc_argv và chặn pearcmd.php như thế nào?
Mình đã tắt directive này trên toàn bộ server mình quản lý và chưa gặp plugin WordPress nào thật sự cần nó — WP-CLI chạy bình thường vì có cơ chế riêng. Cách làm cho từng môi trường:
PHP-FPM (Nginx, OpenLiteSpeed): thêm vào php.ini hoặc pool config (www.conf):
register_argc_argv = OffRồi restart PHP-FPM: systemctl restart php8.3-fpm (đổi đúng phiên bản của bạn).
Shared hosting cPanel: vào MultiPHP INI Editor, chọn domain, tìm register_argc_argv và chuyển sang Off.
Chặn thẳng pearcmd.php ở web server: nếu dùng Nginx:
location ~* /pearcmd\.php { deny all; return 404; }Với OpenLiteSpeed, thêm rule tương tự qua Rewrite trong Virtual Host. Cách này giúp bạn ngủ ngon ngay cả khi quên cập nhật một bản vá nào đó trong tương lai.
Vì sao open_basedir là lớp phòng thủ đáng thêm vào?
Lỗi này thuộc dạng path traversal, nghĩa là kẻ tấn công phải đọc được file ngoài thư mục cho phép. Directive open_basedir của PHP giới hạn phạm vi file mà PHP được mở. Nếu bạn khoá về đúng thư mục của site:
php_admin_value[open_basedir] = /var/www/thienlv.com/public_html:/tmpthì ngay cả khi WordPress chưa vá, việc include file PHP ở đường dẫn lạ cũng bị PHP từ chối ở tầng thấp hơn. Đây là lớp defense-in-depth mình luôn khuyến nghị cho VPS chạy nhiều site: mỗi site một basedir riêng, lỗi của site này không thể chạm tới file của site kia. Lưu ý kiểm tra lại sau khi bật, vì một số plugin backup, log cần thêm đường dẫn vào danh sách.
Checklist tổng hợp sau đợt CVE này gồm những gì?
Túm lại, bạn làm theo thứ tự sau: một, cập nhật WordPress lên 7.1.2 hoặc bản vá tương ứng nhánh cũ của bạn (fix đã backport tới 4.7, nhưng chỉ bản mới nhất được hỗ trợ actively). Hai, kiểm tra theme active có thư mục gốc bắt đầu bằng page- hay không. Ba, tắt register_argc_argv và chặn truy cập pearcmd.php. Bốn, cân nhắc open_basedir cho từng site. Năm, rà log access xem có dấu hiệu probe bất thường những ngày qua. Góc nhìn của mình: mỗi đợt security release như thế này là một lần đáng giá để siết lại hygiene của server, chứ không chỉ nhấn nút Update rồi quên. Nếu bạn quản lý nhiều site khách hàng, hãy biến checklist trên thành template dùng lại cho mọi lần CVE, và nếu bạn viết plugin thì bổ sung thêm Plugin Check để rà bảo mật code — chi phí nhỏ, tránh họa lớn.
Kết luận
CVE-2026-87902 là minh điển hình rằng một lỗi trong ứng dụng chỉ trở thành thảm họa khi server của bạn vô tình “hợp tác” với kẻ tấn công. Cập nhật WordPress 7.1.2 là bắt buộc, nhưng tắt register_argc_argv, chặn pearcmd.php và cấu hình open_basedir mới là những lớp tường khiến site của bạn sống sót qua cả những lỗ hổng chưa được phát hiện. Làm một lần, hưởng lợi dài lâu.
