WordPress 7.1.4 vá lỗ hổng RCE: 62.969 lần tấn công chỉ trong 24 giờ — kiểm tra và cập nhật ngay
WordPress vừa phát hành bản vá bảo mật 7.1.4 vào ngày 28/10/2026, và kẻ tấn công gần như không chờ đợi một giây nào. Chỉ 9 phút sau khi hãng bảo mật Wordfence triển khai quy tắc tường lửa chặn lỗ hổng mới, request tấn công đầu tiên đã xuất hiện. Trong 24 giờ tiếp theo, Wordfence ghi nhận tới 62.969 lần tấn công nhắm vào đúng lỗ hổng này.
Nếu bạn đang vận hành một website WordPress — blog cá nhân, web bán hàng, hay site của khách hàng — thì đây là bài bạn nên đọc hết và làm theo ngay hôm nay. Tin tốt là bản vá đã có sẵn, cập nhật chỉ mất vài phút. Tin xấu là: nếu bạn chần chừ, chính lần cập nhật tiếp theo của bạn cũng có thể trở thành thời điểm kẻ tấn công chờ đợi.
1. Chuyện gì đã xảy ra
Ngày 28/10/2026, WordPress phát hành phiên bản 7.1.4 — một bản cập nhật bảo mật sửa tổng cộng 22 lỗ hổng. Trong đó, nghiêm trọng nhất là một lỗ hổng thực thi mã từ xa (RCE) nằm ngay trong quy trình cập nhật core của WordPress, do nhà nghiên cứu Umut Bayram báo cáo một cách có trách nhiệm.
Diễn biến sau đó cho thấy tốc độ của kẻ tấn công nhanh tới mức nào:
| Thời điểm | Sự kiện |
|---|---|
| 28/10/2026 | WordPress phát hành 7.1.4, sửa 22 lỗ hổng, trong đó có lỗi RCE ở quy trình cập nhật core |
| 28/10/2026, khoảng 20:30 UTC | Wordfence triển khai quy tắc tường lửa chặn lỗ hổng cho khách hàng Premium, Care và Response |
| 9 phút sau đó | Request tấn công đầu tiên khớp với quy tắc mới của Wordfence |
| 21 giờ đầu tiên | Hơn 18.500 request nhắm vào đường dẫn installer tạm thời setup-config.php |
| 30/10/2026 | The Hacker News đưa tin: Wordfence đã chặn 62.969 lần tấn công trong 24 giờ |
| 31/10/2026 | Lỗ hổng được cấp mã CVE-2026-119977 (trước đó, khi The Hacker News đưa tin ngày 30/10, nó vẫn chưa có mã CVE) |
Một chi tiết quan trọng cần nói rõ ngay từ đầu: 62.969 là số request tấn công bị chặn, không phải 62.969 website đã bị hack. Tính đến 31/10, chưa có vụ xâm nhập thành công nào từ lỗ hổng này được công bố. Nhưng con số đó vẫn rất đáng báo động, vì nó chứng minh kẻ tấn công đã hiểu rõ cơ chế lỗ hổng và đang quét diện rộng để chờ đúng thời điểm ra tay.
2. Lỗ hổng hoạt động như thế nào
Để hiểu vì sao lỗ hổng này nguy hiểm, bạn hãy hình dung quy trình cập nhật WordPress như sau.
Khi bạn bấm cập nhật core bằng gói đầy đủ (full-package update), WordPress sẽ giải nén toàn bộ file của phiên bản mới vào một thư mục tạm nằm dưới wp-content/upgrade/. Bản sao tạm này bao gồm cả trình cài đặt WordPress (wp-admin/setup-config.php) — file vốn chỉ nên xuất hiện khi bạn cài đặt site mới.
Vấn đề nằm ở chỗ, trên các phiên bản từ 4.7 đến 7.1.3:
- Tên thư mục tạm có thể đoán trước được, thay vì ngẫu nhiên.
- Thư mục tạm truy cập được từ web trên nhiều cấu hình máy chủ, và PHP bên trong nó vẫn chạy được bình thường.
- Kẻ tấn công không cần tài khoản trên site của bạn — chỉ cần gửi request đúng lúc tới file installer trong bản sao tạm đó, rồi tương tác với nó để đi tới thực thi mã PHP trên máy chủ.
Nghe thì có vẻ khó tin, vì cửa sổ tấn công này chỉ tồn tại trong vài giây — đúng khoảng thời gian WordPress giải nén xong nhưng chưa dọn dẹp thư mục tạm. Trong phòng lab của Wordfence, cửa sổ này cũng chỉ kéo dài vài giây. Nhưng kẻ tấn công không gửi một request duy nhất rồi hy vọng may mắn. Họ quét liên tục: hai nguồn tấn công lớn nhất đã dò một nhóm nhỏ website suốt khoảng 14,5 giờ liên tục, còn các nguồn khác thử đủ biến thể tên thư mục và tên phiên bản. Cứ quét đủ lâu, đủ nhiều site, thì sớm muộn cũng có một lần cập nhật trùng với một request dò đúng lúc.
Đó chính là bản chất của lỗ hổng race condition (đua tranh thời gian): không phải lúc nào cũng khai thác được, nhưng khi có hàng nghìn site cùng cập nhật và hàng nghìn bot cùng quét, xác suất thành công tích lũy theo thời gian là có thật.
Bản vá WordPress 7.1.4 sửa lỗi này bằng ba thay đổi: tên thư mục tạm giờ có thêm hậu tố ngẫu nhiên 16 ký tự, file index.php bảo vệ thư mục được giữ lại và tái tạo, và trình cập nhật không còn đẩy file wp-config.php từ thư mục tạm lên thư mục gốc của site một cách không an toàn nữa. Bản vá cũng được backport về tất cả các nhánh còn được hỗ trợ, xuống tới 4.7.
3. Ai bị ảnh hưởng
Lỗ hổng RCE này ảnh hưởng tới WordPress Core từ phiên bản 4.7 đến 7.1.3. Nói cách khác, nếu site của bạn chưa lên 7.1.4 (hoặc bản vá tương ứng của nhánh mình đang dùng), bạn vẫn nằm trong diện ảnh hưởng — bất kể bạn dùng theme hay plugin nào, vì lỗi nằm ở chính core của WordPress, không phải ở plugin.
| Nhóm phiên bản | Tình trạng |
|---|---|
| WordPress 4.7 — 7.1.3 | Bị ảnh hưởng bởi lỗi RCE ở cửa sổ cập nhật |
| WordPress 7.1.4 | Đã vá |
| Các nhánh cũ (ví dụ 7.0.8, 6.9.11, 6.8.12… xuống tới 4.7.39) | Đã có bản vá bảo mật tương ứng của từng nhánh |
| WordPress 4.6 trở về trước | Không còn nhận cập nhật bảo mật — cần nâng cấp lên nhánh được hỗ trợ |
Ngoài lỗi RCE, WordPress 7.1.4 còn sửa 21 lỗ hổng khác, phần lớn yêu cầu tài khoản Contributor trở lên: nhiều lỗi stored XSS trong các block và Interactivity API, một lỗi lộ thông tin Customizer chưa công bố mà không cần đăng nhập, và một lỗi phân quyền trong Notes REST API. Những lỗi này ít khẩn cấp hơn lỗi RCE, nhưng chúng là lý do bạn không nên chỉ vá lỗi RCE rồi dừng lại — cập nhật lên WordPress 7.1.4 là xử lý trọn gói cả 22 lỗi cả 22 lỗi.
Lưu ý cho người dùng Wordfence miễn phí: quy tắc chặn lỗ hổng này chỉ đến tay bản Free vào 27/11/2026, sau khoảng trễ 30 ngày. Trước đó, bản vá core là lớp bảo vệ duy nhất của bạn.
4. Mức độ nghiêm trọng: nói thật, không phóng đại
Wordfence chấm lỗ hổng này CVSS 8.1 (mức High) — không phải 9.x hay 10.0 như một số lỗ hổng gần đây. Điểm số này phản ánh đúng bản chất hai mặt của nó:
- Tác động thì rất lớn: nếu khai thác thành công, kẻ tấn công chạy được mã trên máy chủ của bạn.
- Độ khó khai thác thì cao: cần đúng một lần cập nhật full-package đang chạy, đúng đường dẫn thư mục tạm, và đúng thời điểm vài giây trước khi WordPress dọn dẹp.
Bạn cũng cần phân biệt rõ ba khái niệm mà nhiều bài viết hay đánh đồng:
- Bị quét / bị tấn công: đã xảy ra, quy mô lớn (62.969 request bị chặn trong 24 giờ).
- Bị xâm nhập thành công: chưa có trường hợp nào được công bố tính đến 31/10.
- An toàn vì chưa bị hack: sai. Kẻ tấn công quét hôm nay chính là để xâm nhập vào lần cập nhật tiếp theo của bạn.
Nói ngắn gọn: đây không phải lỗ hổng “cứ để đó rồi tính”, nhưng cũng không phải lý do để hoảng loạn. Nó là lý do để bạn cập nhật ngay trong hôm nay, theo đúng thứ tự an toàn ở các mục dưới đây.
5. Kiểm tra site của bạn đang chạy phiên bản nào
Trước khi cập nhật, bạn cần biết mình đang ở đâu. Cách nhanh nhất là vào trang quản trị: Dashboard > Updates sẽ hiển thị phiên bản hiện tại và thông báo “WordPress 7.1.4 is available! Please update now” nếu bạn chưa cập nhật.
Nếu bạn có quyền SSH vào máy chủ, WP-CLI cho bạn câu trả lời trong một dòng:
cd /var/www/example.com
wp core versionKhông có WP-CLI thì bạn vẫn kiểm tra được trực tiếp từ file version của WordPress:
grep "wp_version =" wp-includes/version.phpMình đã chạy thử các lệnh kiểm tra này trong môi trường giả lập mô phỏng một site WordPress, và kết quả cho thấy đúng dạng output bạn sẽ thấy trên máy chủ thật. Ảnh terminal dưới đây là kết quả chạy thật đó: site mẫu đang ở 7.1.3 (thuộc diện bị ảnh hưởng), thư mục wp-content/upgrade/ hiện trống vì không có lần cập nhật nào đang chạy, và file log mẫu cho thấy dạng request dò setup-config.php mà bạn cần tìm trong access log của mình.
Lưu ý khi đọc log: địa chỉ IP trong ảnh chỉ là IP ví dụ dạng mẫu, còn log thật của bạn sẽ chứa IP của kẻ quét. Điều cần tìm là mẫu request, cụ thể là bất kỳ request nào tới file PHP nằm dưới wp-content/upgrade/ — bình thường không có người dùng thật nào truy cập vào đó cả.
6. Cập nhật lên WordPress 7.1.4 từng bước
Làm theo đúng thứ tự này, đừng bỏ qua bước sao lưu:
Bước 1: Sao lưu toàn bộ site. Sao lưu cả file và database, và kiểm tra xem bản sao lưu có khôi phục được không. Một bản sao lưu chưa từng thử khôi phục thì chưa thể gọi là sao lưu.
Bước 2: Cập nhật từ trang quản trị. Vào Dashboard > Updates, bấm Update to version 7.1.4. Nếu site của bạn đang ở nhánh cũ hơn và bạn muốn ở lại nhánh đó, hãy cập nhật lên bản vá bảo mật mới nhất của đúng nhánh đó (ví dụ 6.8.12, 6.9.11, 7.0.8).
Bước 3: Hoặc cập nhật bằng WP-CLI. Trên máy chủ, chạy:
wp core update # lên bản mới nhất (7.1.4)
wp core update --minor # ở lại nhánh hiện tại, ví dụ 6.8 -> 6.8.12
wp core update-db # nâng cấp database nếu được yêu cầuBước 4: Xác minh lại sau khi cập nhật. Vào lại Dashboard > Updates hoặc chạy wp core version để chắc chắn site đã ở 7.1.4 (hoặc bản vá của nhánh bạn). Đừng đoán — nhiều site bật cập nhật tự động nhưng vẫn kẹt ở bản cũ vì lỗi quyền ghi file hoặc plugin chặn cập nhật.
Bước 5: Chạy quét toàn site một lần. Nếu bạn dùng Wordfence, hãy chạy một lần quét sau khi cập nhật để phát hiện file core bị sửa đổi, file lạ, hay tài khoản bất thường. Nếu không dùng Wordfence, ít nhất hãy rà lại danh sách tài khoản quản trị và plugin trong trang quản trị.
Một lưu ý quan trọng cho lần cập nhật này: chính lúc bạn bấm cập nhật từ 7.1.3 lên 7.1.4 cũng là một lần cập nhật full-package — tức là cửa sổ tấn công mở ra một lần cuối cùng trước khi bản vá có hiệu lực. Vì vậy, nếu có thể, hãy chặn thư mục wp-content/upgrade/ trước rồi mới bấm cập nhật, theo hướng dẫn ở mục 7.
7. Chặn trước khi cập nhật và phòng thủ lâu dài
Ngay cả sau khi đã vá, chặn truy cập web vào thư mục tạm của trình cập nhật vẫn là một lớp phòng thủ sâu đáng giữ lại. Cách làm tùy theo web server bạn dùng.
Với nginx, thêm vào block server của site:
location ^~ /wp-content/upgrade/ {
deny all;
return 404;
}Với Apache, tạo hoặc sửa file .htaccess trong thư mục wp-content/upgrade/:
<FilesMatch "\.(php|phtml|php5)$">
Require all denied
</FilesMatch>Sau khi thêm quy tắc, nhớ kiểm tra lại bằng lệnh nginx -t (với nginx) rồi mới reload dịch vụ, và thử truy cập một URL giả dưới wp-content/upgrade/ để chắc chắn nó trả về 403 hoặc 404 thay vì chạy PHP.
Ngoài ra, nếu bạn dùng Wordfence, hãy kiểm tra xem tường lửa có đang ở chế độ Extended Protection hay không. Chế độ này quan trọng với đúng lỗ hổng này, vì request tấn công gọi trực tiếp tới file PHP tạm mà không tải WordPress lên trước — tường lửa chỉ chặn được nó khi chạy trước cả WordPress.
Cuối cùng, đừng quên bật cập nhật tự động cho core, xóa tài khoản Contributor/Author không còn dùng tới, và giữ plugin/theme ở bản mới nhất.
8. Dấu hiệu cho thấy site của bạn có thể đã bị nhắm tới
Hãy dành vài phút rà soát các dấu hiệu sau, đặc biệt nếu site của bạn vẫn ở phiên bản cũ trong những ngày từ 28/10 trở đi:
- Access log có request tới
wp-content/upgrade/: dùng lệnhgrep "wp-content/upgrade" access.logtrên máy chủ. Bất kỳ request nào tới file PHP dưới thư mục này cũng đáng điều tra, dù nó trả về 404. - Tài khoản quản trị lạ: vào Users trong trang quản trị, kiểm tra xem có tài khoản admin nào bạn không tạo ra không.
- Plugin hoặc theme lạ: plugin bạn không cài, theme bạn không nhận ra, đặc biệt là những cái xuất hiện quanh thời điểm cập nhật gần nhất.
- File PHP lạ trong thư mục upload hoặc thư mục tạm: file PHP không thuộc về theme/plugin nào, hoặc file mới xuất hiện trong
wp-content/uploads/(thư mục này bình thường chỉ chứa media). - Site chạy chậm bất thường hoặc bị chèn link lạ: có thể là dấu hiệu của webshell hoặc mã độc SEO đã nằm trên site từ trước.
Nếu bạn tìm thấy một trong các dấu hiệu trên, đừng chỉ xóa file lạ rồi cập nhật cho xong. Hãy coi đó là một sự cố bảo mật: sao lưu hiện trạng để điều tra, đổi toàn bộ mật khẩu quản trị, rà soát lại toàn bộ file, và nếu không chắc chắn, hãy nhờ người có chuyên môn kiểm tra trước khi đưa site trở lại hoạt động bình thường.
Kết luận
WordPress 7.1.4 không phải là một bản cập nhật tính năng để bạn cân nhắc “để tuần sau cũng được”. Nó vá một lỗ hổng mà kẻ tấn công đã hiểu rõ và đang quét với tốc độ gần 63.000 request mỗi ngày. Cửa sổ tấn công chỉ dài vài giây, nhưng kẻ tấn công có đủ kiên nhẫn để quét 14,5 giờ liên tục — và site của bạn chỉ cần cập nhật một lần đúng lúc đó là đủ.
Việc cần làm rất đơn giản và chỉ mất vài phút: kiểm tra phiên bản, sao lưu, chặn thư mục wp-content/upgrade/ nếu có thể, cập nhật lên 7.1.4, rồi xác minh lại. Làm xong hôm nay, bạn sẽ không còn nằm trong danh sách những site mà bot đang dò mỗi giờ nữa.
Câu hỏi thường gặp
Site của mình bật cập nhật tự động thì có cần làm gì không?
Vẫn cần kiểm tra. Cập nhật tự động có thể thất bại vì lỗi quyền file, hết dung lượng đĩa, hoặc plugin chặn cập nhật. Vào Dashboard > Updates và xác nhận site đã ở 7.1.4 rồi mới yên tâm.
Lỗi này có cần plugin độc hại hay theme lỗi mới khai thác được không?
Không. Lỗi nằm ở core WordPress, trong quy trình cập nhật core. Kẻ tấn công không cần tài khoản, không cần plugin hay theme nào cả — chỉ cần đúng thời điểm cập nhật.
62.969 lần tấn công có nghĩa là đã có 62.969 site bị hack không?
Không. Đó là số request tấn công bị Wordfence chặn trong 24 giờ, bao gồm cả những lần quét dò đường dẫn. Tính đến 31/10, chưa có vụ xâm nhập thành công nào từ lỗ hổng này được công bố. Nhưng số request bị chặn lớn như vậy chứng tỏ kẻ tấn công đang rất tích cực.
Site mình ở WordPress 4.6 thì cập nhật thế nào?
WordPress 4.6 trở về trước không còn nhận bản vá bảo mật, kể cả cho lỗi này. Bạn cần nâng cấp lên một nhánh còn được hỗ trợ, và nên làm việc này trong môi trường staging trước vì bước nhảy phiên bản lớn có thể làm vỡ theme/plugin cũ.
Dùng Wordfence Free thì đã được bảo vệ chưa?
Chưa đủ. Quy tắc chặn lỗ hổng này chỉ đến tay người dùng Wordfence Free vào 27/11/2026. Trước thời điểm đó, cập nhật core lên WordPress 7.1.4 là biện pháp bảo vệ chính, và bạn nên bật Extended Protection nếu dùng Wordfence.
Cập nhật lên 7.1.4 có làm vỡ site không?
WordPress 7.1.4 là bản vá bảo mật, không phải bản tính năng lớn, nên rủi ro tương thích thấp hơn nhiều so với nâng cấp phiên bản chính. Dù vậy, bạn vẫn nên sao lưu trước và kiểm tra lại các trang quan trọng sau khi cập nhật, đúng như mọi lần cập nhật core.
Nguồn tham khảo
- WordPress.org — Tài liệu phiên bản 7.1.4
- Wordfence — WordPress 7.1.4 vá lỗi RCE ở cửa sổ cập nhật, đã ghi nhận tấn công sau bản vá
- CVE.org — Hồ sơ CVE-2026-119977
- The Hacker News — Lỗ hổng RCE WordPress thu hút gần 63.000 lần tấn công trong 24 giờ
- Techaeris — Lỗ hổng RCE WordPress thu hút gần 63.000 lần tấn công
Bình luận (0)