Nội dung bài viết
Ngày 28/10/2026, WordPress phát hành bản 7.1.4 để vá 22 lỗ hổng bảo mật. Lỗi nghiêm trọng nhất nằm ngay trong quá trình cập nhật WordPress: kẻ tấn công không cần tài khoản vẫn có thể chạy mã trên máy chủ.
Chỉ 3 ngày sau, lỗi đã bị tấn công dồn dập. Theo số liệu của Wordfence công bố ngày 30-31/10, có khoảng 60.000-63.000 lượt tấn công nhắm vào lỗ hổng này chỉ trong 24 giờ (tùy nguồn). Trước đó, trong 21 giờ đầu sau khi Wordfence triển khai luật chặn, con số mới là khoảng 18.500 lượt.
Các con số trên là lượt tấn công đã bị chặn, chưa phải số website bị chiếm. Tới nay chưa có báo cáo website nào bị khai thác thành công. Nhưng mức tăng nhanh như vậy cho thấy kẻ tấn công đang quét hàng loạt, nên chủ website WordPress cần xử lý ngay.
Tóm tắt nhanh
| Mục | Chi tiết |
|---|---|
| Mã lỗi | CVE-2026-119977 (theo Wordfence; một số nguồn ghi chưa được cấp CVE) |
| Mức độ | CVSS 8.1 (cao) |
| Phiên bản bị ảnh hưởng | WordPress 4.7 tới 7.1.3 |
| Bản vá | 7.1.4, cùng các bản vá cho nhánh cũ: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14... xuống tới 4.7.39 |
| Không có bản vá | WordPress 4.6 trở về trước |
| Cần đăng nhập? | Không |
| Tình trạng | Đang bị dò quét và tấn công hàng loạt, chưa ghi nhận site bị chiếm |
Lỗ hổng hoạt động thế nào?
Khi WordPress cập nhật lõi (core), nó giải nén toàn bộ bộ cài đặt mới vào thư mục wp-content/upgrade/ rồi mới chép đè lên website. Thư mục này thường truy cập được từ trình duyệt. Trước bản 7.1.4 có hai vấn đề:
- Tên thư mục giải nén đoán được.
- File
index.phpcó tác dụng chặn liệt kê nội dung thư mục bị xóa trong quá trình dọn dẹp.
Vì vậy, trong vài giây lúc cập nhật, một bản WordPress đầy đủ, gồm cả trình cài đặt wp-admin/setup-config.php, nằm ở một đường dẫn mà ai cũng có thể đoán ra. Trình cài đặt này chạy được độc lập, không cần cấu hình của website. Kẻ tấn công gọi nó vào đúng lúc đó, trỏ nó tới một cơ sở dữ liệu do chúng kiểm soát, rồi từ đó tìm cách chạy mã trên máy chủ.
Khoảng thời gian để khai thác chỉ kéo dài vài giây, nên lỗi được chấm là khó khai thác. Kẻ tấn công bù lại bằng cách gửi request liên tục vào các đường dẫn này để canh đúng lúc website đang cập nhật. Đó là lý do số lượt tấn công lên tới hàng chục nghìn.
Có một chi tiết dễ bị bỏ qua: khoảng thời gian nguy hiểm này xuất hiện lại mỗi lần WordPress cập nhật, kể cả khi cập nhật tự động lúc nửa đêm.
Bản 7.1.4 sửa lỗi bằng cách:
- thêm 16 ký tự ngẫu nhiên vào tên thư mục giải nén;
- tạo lại và giữ file
index.php; - không chép
wp-config.phpra khỏi thư mục làm việc nữa.
Việc cần làm ngay
1. Kiểm tra phiên bản WordPress
Vào trang quản trị, chọn Bảng tin → Cập nhật (Dashboard → Updates) để xem phiên bản đang chạy. Phiên bản an toàn là 7.1.4, hoặc bản vá tương ứng của nhánh bạn đang dùng (ví dụ 7.0.8, 6.9.11).
Website bật cập nhật tự động thường đã được nâng lên 7.1.4. Tuy vậy, đừng mặc định là đã xong: cập nhật tự động có thể thất bại vì lỗi quyền ghi file, hết dung lượng, hoặc do plugin chặn. Hãy kiểm tra trực tiếp.
Nếu website vẫn chạy WordPress 4.6 hoặc cũ hơn, sẽ không có bản vá nào cho bạn. Đây là lúc phải nâng cấp lên bản mới.
2. Chặn truy cập web vào thư mục wp-content/upgrade/
Đây là biện pháp quan trọng nhất sau khi cập nhật, vì nó bịt hẳn đường tấn công cho cả những lần cập nhật sau. Bình thường thư mục này chỉ chứa file index.php, không có lý do gì để trình duyệt truy cập vào.
Apache hoặc LiteSpeed (phần lớn hosting cPanel, DirectAdmin tại Việt Nam): thêm đoạn sau vào file .htaccess ở thư mục gốc website, đặt phía trên dòng # BEGIN WordPress:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>
Không nên đặt file .htaccess bên trong chính thư mục upgrade, vì WordPress xóa nội dung thư mục này mỗi lần cập nhật.
Nginx (VPS tự quản lý): thêm vào khối server của website, rồi tải lại Nginx:
location ^~ /wp-content/upgrade/ {
deny all;
}
Kiểm tra lại: mở https://ten-mien-cua-ban/wp-content/upgrade/ trên trình duyệt. Kết quả đúng là lỗi 403 Forbidden. Nếu thấy danh sách file hoặc trang trắng, nghĩa là quy tắc chưa có tác dụng.
Website cài WordPress trong thư mục con (ví dụ /blog/) thì phải thêm tên thư mục con vào đường dẫn cho đúng.
3. Đừng trông chờ vào plugin tường lửa
Patchstack lưu ý rằng tường lửa chạy dưới dạng plugin WordPress không chặn được lỗi này. Lý do là bản WordPress được giải nén tạm tự chạy bằng file của chính nó, không nạp các plugin bảo mật của website.
Ngoài ra, với Wordfence, luật chặn lỗi này đã có cho khách trả phí từ ngày 28/10. Người dùng bản miễn phí phải đợi tới 27/11/2026 mới nhận được, theo độ trễ 30 ngày thông thường. Cách bảo vệ chắc chắn vẫn là cập nhật WordPress và chặn thư mục ở tầng máy chủ web như hướng dẫn trên.
21 lỗ hổng còn lại trong bản 7.1.4
Ngoài lỗi RCE, bản 7.1.4 vá thêm 21 lỗ hổng. Phần lớn là stored XSS (chèn mã độc vào nội dung, chạy khi người khác mở trang). Nhiều lỗi nằm trong Interactivity API và một số block như Categories, Comments Pagination, Post Navigation Link. Những lỗi này cần tài khoản từ quyền Contributor (Cộng tác viên) trở lên mới khai thác được. Có một lỗi không cần đăng nhập: để lộ các thay đổi chưa xuất bản trong Customizer.
Vì vậy, ngoài việc cập nhật, nên rà lại danh sách tài khoản trên website. Hãy xóa các tài khoản cộng tác viên, tác giả không còn dùng, đặc biệt trên các website cho phép đăng ký thành viên.
Bản 7.1.4 cũng cập nhật bộ chứng chỉ gốc đi kèm WordPress, để gỡ các chứng chỉ eMudhra đã bị thu hồi.
Tháng 10 "nóng" với WordPress
Đây là một trong rất nhiều sự cố nhắm vào hệ sinh thái WordPress chỉ trong tháng 10/2026. Trước đó đã có lỗ hổng PHP2Shell trong lõi PHP, YOOtheme Pro bị khai thác để cài webshell và Rank Math SEO PRO bị cài mã độc ngay trong gói cập nhật.
Bài học chung không mới nhưng luôn đúng:
- bật cập nhật tự động cho lõi WordPress và kiểm tra định kỳ xem cập nhật có thành công không;
- sao lưu đều đặn và lưu bản sao ngoài máy chủ;
- chặn ở tầng máy chủ web những thư mục không cần truy cập công khai, như
wp-content/upgrade/và các file.env,.git.
Nguồn tham khảo: WordPress.org, Wordfence, Patchstack, SecurityWeek, The Hacker News và Cyber Security News.