Lỗ hổng WordPress CVE-2026-119977 đang bị khai thác: doanh nghiệp cần kiểm tra gì ngay hôm nay

Tóm tắt nhanh: CVE-2026-119977 là lỗ hổng trong cơ chế cập nhật lõi WordPress, cho phép kẻ tấn công không cần đăng nhập chen vào đúng lúc website đang cập nhật để chạy mã PHP trên máy chủ. Bản vá có trong WordPress 7.1.4 (phát hành 28/10/2026) và được đưa ngược về các nhánh cũ đến 4.7. Ngày 3/11/2026, Cơ quan An ninh mạng và Cơ sở hạ tầng Hoa Kỳ (CISA) đưa lỗ hổng vào danh mục KEV, tức danh sách lỗ hổng đã có bằng chứng bị khai thác thực tế. Nếu doanh nghiệp bạn có website WordPress, hãy kiểm tra phiên bản ngay trong hôm nay.

WordPress đang vận hành một phần rất lớn website doanh nghiệp tại Việt Nam, từ trang giới thiệu công ty, trang tuyển dụng đến cửa hàng trực tuyến. Vì vậy mỗi lỗ hổng ở phần lõi đều đáng chú ý. Điểm khiến lỗ hổng lần này khác thường là nó nằm đúng trong quy trình mà ai cũng được khuyên làm thường xuyên: cập nhật website.

Lỗ hổng hoạt động như thế nào

Khi WordPress cập nhật lõi bằng gói đầy đủ, hệ thống giải nén bộ mã mới vào một thư mục tạm bên trong wp-content/upgrade/, sau đó mới chép các tệp sang vị trí chính thức. Trong vài giây đó, thư mục tạm chứa cả các tệp cài đặt như wp-admin/setup-config.php.

Theo phân tích của Wordfence và Patchstack, vấn đề nằm ở ba điểm cộng lại:

Thư mục wp-content/upgrade/ nằm trong vùng web công khai, nên trình duyệt có thể gọi trực tiếp các tệp PHP trong đó.
Tên thư mục tạm có thể đoán được.
Tệp cài đặt nằm trong thư mục tạm có thể bị gọi trước khi WordPress dọn dẹp.

Kẻ tấn công liên tục gửi yêu cầu đến đường dẫn đoán trước. Nếu trúng đúng thời điểm website đang cập nhật, họ có thể tương tác với trình cài đặt, trỏ nó về cơ sở dữ liệu do họ kiểm soát, từ đó tạo tài khoản quản trị mới và cài plugin độc hại để chạy mã PHP. Đây là kiểu lỗi “kiểm tra một lúc, sử dụng lúc khác” (race condition, CWE-367).

Một chi tiết quan trọng: yêu cầu tấn công đi thẳng vào tệp PHP mà không tải WordPress. Vì vậy các plugin bảo mật chạy bên trong WordPress có thể không nhìn thấy cuộc tấn công. Nhật ký của máy chủ web mới là nơi đáng tin cậy để kiểm tra.

Mức độ nghiêm trọng: vì sao có hai cách đánh giá

Nhóm WordPress đánh giá lỗ hổng ở mức thấp vì cửa sổ tấn công chỉ kéo dài vài giây. Wordfence, đơn vị cấp mã CVE, chấm CVSS 3.1 là 8.1 (Cao) vì hậu quả khi khai thác thành công là chiếm toàn quyền website. Cả hai đều có lý. Với doanh nghiệp, cách nghĩ thực tế là: xác suất trúng mỗi lần thấp, nhưng kẻ tấn công dùng công cụ tự động thử liên tục hàng nghìn website, và chỉ cần trúng một lần.

Số liệu từ Wordfence cho thấy điều đó: hơn 18.500 yêu cầu dò tìm trong 21 giờ đầu sau khi bản vá phát hành, có nguồn kiên trì “canh” một nhóm nhỏ website trong khoảng 14,5 giờ. Ngày 4/11, mã khai thác minh hoạ (proof of concept) đã xuất hiện công khai trên GitHub, nghĩa là rào cản kỹ thuật đã thấp hơn nhiều.

Dòng thời gian

Ngày (2026)	Sự kiện
28/10	WordPress phát hành 7.1.4 và các bản vá cho nhánh cũ đến 4.7. Wordfence triển khai luật tường lửa cho khách trả phí; yêu cầu tấn công đầu tiên xuất hiện 9 phút sau
29/10	WordPress công bố khuyến cáo bảo mật; CERT-FR (Pháp) ra cảnh báo
31/10	Mã CVE-2026-119977 được công bố
3/11	CISA đưa vào danh mục KEV, yêu cầu cơ quan liên bang Mỹ xử lý trước 6/11
4/11	Mã khai thác minh hoạ xuất hiện công khai
27/11	Theo kế hoạch, người dùng Wordfence miễn phí nhận luật tường lửa

Phiên bản bị ảnh hưởng và phiên bản đã vá

Nhánh	Phiên bản đã vá
7.1	7.1.4
7.0	7.0.8
6.9	6.9.11
6.8	6.8.12
6.7	6.7.11
6.6	6.6.11
6.5	6.5.14
6.4	6.4.14
4.7 đến 6.3	Có bản vá riêng cho từng nhánh
4.6 trở về trước	Không có bản vá, cần nâng cấp

Nếu website của bạn bật cập nhật tự động cho bản bảo mật (mặc định của WordPress), rất có thể nó đã lên bản vá. Nhưng đừng giả định. Nhiều website doanh nghiệp tắt cập nhật tự động vì sợ hỏng giao diện, hoặc được agency bàn giao rồi không ai theo dõi.

Việc cần làm ngay: 5 bước theo thứ tự

Bước 1: Kiểm tra phiên bản

Vào Bảng tin → Cập nhật trong trang quản trị, hoặc nếu có quyền truy cập máy chủ, chạy wp core version. So với bảng phiên bản đã vá ở trên.

Bước 2: Chặn truy cập web vào thư mục upgrade trước khi cập nhật

Các chuyên gia khuyến nghị chặn truy cập công khai vào wp-content/upgrade/ trước khi bấm cập nhật, vì chính lần cập nhật lên bản vá vẫn chạy bộ mã cũ. Với máy chủ Apache hoặc LiteSpeed, có thể đặt tệp .htaccess trong thư mục wp-content/upgrade/:

# Chặn mọi truy cập web vào thư mục tạm khi cập nhật
Require all denied

Với Nginx, thêm vào cấu hình site:

location ^~ /wp-content/upgrade/ {
    deny all;
}

Sau đó thử mở https://tên-miền/wp-content/upgrade/ trên trình duyệt, kết quả đúng là lỗi 403. Đồng thời kiểm tra tính năng liệt kê thư mục (directory listing) đang tắt. Một lựa chọn khác là cập nhật thủ công: tải gói từ wordpress.org và chép đè ngoài vùng web, thay vì dùng trình cập nhật tích hợp. Lưu ý lệnh wp core update của WP-CLI cũng dùng cùng trình cập nhật, nên vẫn cần chặn thư mục trước.

Bước 3: Cập nhật lên bản vá

Sao lưu toàn bộ mã nguồn và cơ sở dữ liệu, cập nhật lên phiên bản vá của nhánh bạn đang dùng, rồi kiểm tra lại số phiên bản. Với website còn ở nhánh 4.6 trở về trước, đây là lúc lập kế hoạch nâng cấp thật sự, vì không còn bản vá bảo mật cho các nhánh này.

Bước 4: Kiểm tra dấu hiệu bị xâm nhập

Hiện chưa có bộ chỉ dấu (IoC) chính thức như địa chỉ IP hay mã băm. Những gì nên rà soát:

Nhật ký máy chủ web: tìm yêu cầu tới các tệp PHP bên dưới wp-content/upgrade/, đặc biệt setup-config.php, tập trung vào thời điểm website từng cập nhật lõi.
Tài khoản quản trị: vào Thành viên, lọc vai trò Quản trị viên, đối chiếu danh sách với những người thực sự cần quyền.
Plugin lạ: plugin bạn không cài, đặc biệt plugin có tên chung chung hoặc không có trong kho chính thức.
Tệp PHP lạ trong wp-content/upgrade/ và wp-content/uploads/.

Ví dụ lệnh tìm nhanh trong nhật ký truy cập (đường dẫn nhật ký tuỳ máy chủ):

grep -E "wp-content/upgrade/.*\.php" /đường-dẫn/access.log

Bước 5: Nếu thấy dấu hiệu bất thường

Đừng chỉ xoá tài khoản lạ rồi coi như xong. Một khi kẻ tấn công đã chạy được mã PHP, họ có thể để lại cửa hậu ở nhiều nơi. Quy trình tối thiểu: cô lập website (bật chế độ bảo trì hoặc chặn truy cập), đổi toàn bộ mật khẩu quản trị, mật khẩu cơ sở dữ liệu, khoá bí mật trong wp-config.php, khoá API của các dịch vụ kết nối, rồi khôi phục từ bản sao lưu sạch trước thời điểm bị xâm nhập. Nếu website có dữ liệu khách hàng, cần đánh giá nghĩa vụ thông báo theo Luật Bảo vệ dữ liệu cá nhân có hiệu lực từ 1/1/2026.

Bài học dài hạn cho website doanh nghiệp

Lỗ hổng này nhắc lại vài nguyên tắc mà nhiều doanh nghiệp bỏ qua vì website “chỉ là trang giới thiệu”:

Có người chịu trách nhiệm cập nhật. Website không có chủ là website dễ bị bỏ quên nhất. Ghi rõ ai theo dõi cảnh báo bảo mật và ai bấm cập nhật.
Cập nhật tự động cho bản bảo mật nên được bật, kèm sao lưu tự động hằng ngày để có đường lui nếu bản cập nhật gây lỗi.
Nhật ký máy chủ phải được giữ lại. Không có nhật ký, bạn không thể trả lời câu hỏi “đã bị xâm nhập chưa”.
Tối giản plugin và tài khoản quản trị. Mỗi plugin, mỗi tài khoản admin là một cánh cửa.
Theo dõi danh mục KEV của CISA. Đây là nguồn miễn phí, cập nhật hằng ngày, cho biết lỗ hổng nào đang bị khai thác thật, để ưu tiên vá trước.

Câu hỏi thường gặp

Website của tôi dùng hosting có quản lý, có cần làm gì không?

Nhiều nhà cung cấp hosting WordPress có quản lý tự cập nhật và tự chặn đường dẫn nguy hiểm, nhưng mức độ khác nhau. Hãy hỏi nhà cung cấp hai câu: website đã lên bản vá chưa, và họ có chặn truy cập web vào wp-content/upgrade/ không.

Tôi đã cài plugin bảo mật thì có an toàn không?

Không hoàn toàn. Như đã giải thích, yêu cầu tấn công đi thẳng vào tệp PHP mà không qua WordPress, nên plugin chạy trong WordPress có thể không phát hiện. Tường lửa ở cấp máy chủ và bản vá vẫn là lớp bảo vệ chính.

Website đã tự cập nhật lên 7.1.4 thì còn cần làm gì không?

Website đã an toàn trước lỗ hổng này cho các lần cập nhật sau. Tuy nhiên, chính lần cập nhật lên 7.1.4 vẫn chạy bộ mã cũ, và kẻ tấn công đã dò tìm từ ngay ngày 28/10. Rủi ro thấp, nhưng nên dành vài phút rà soát nhật ký quanh thời điểm cập nhật và danh sách tài khoản quản trị.

Kết luận

CVE-2026-119977 không phải lỗ hổng dễ khai thác, nhưng đã có mã khai thác công khai và bằng chứng tấn công thực tế. Việc cần làm không phức tạp: chặn thư mục upgrade, cập nhật lên bản vá, rà soát nhật ký và tài khoản. Doanh nghiệp nên làm trong hôm nay thay vì chờ đến lần bảo trì định kỳ.

Nếu doanh nghiệp bạn cần thiết lập quy trình theo dõi cảnh báo và tự động hoá việc sao lưu, kiểm tra website, đội ngũ Kết Nối Số có thể hỗ trợ qua dịch vụ Tư vấn giải pháp Automation AI hoặc liên hệ trực tiếp.

Nguồn tham khảo

Thông tin kiểm tra ngày 10/11/2026. Bài viết mang tính tham khảo, không thay thế đánh giá của chuyên gia bảo mật cho hệ thống cụ thể của bạn.