Cập nhật WordPress an toàn: Quy trình 7 bước sau lỗ hổng CVE-2026-119977

Wecanadmin  /  Twitter 10.11.2026

Lời khuyên quen thuộc nhất về bảo mật website là “hãy cập nhật WordPress thường xuyên”. Nhưng cuối tháng 10/2026, giới quản trị web đã phải đối mặt với một tình huống trớ trêu: lỗ hổng CVE-2026-119977 nằm ngay trong quá trình cập nhật WordPress. Chính những phút website đang cập nhật lại là lúc kẻ tấn công có thể chiếm quyền quản trị mà không cần tài khoản. Ngày 03/11/2026, Cơ quan An ninh mạng và Hạ tầng Hoa Kỳ (CISA) xác nhận lỗ hổng này đang bị khai thác thực tế. Sau lỗ hổng PHP2Shell, đây là lời nhắc tiếp theo rằng website doanh nghiệp cần một quy trình vận hành, không chỉ một cú bấm.

Bài viết dưới đây của Wecan Group giải thích ngắn gọn lỗ hổng này hoạt động ra sao, website nào cần hành động ngay, và đưa ra quy trình 7 bước cập nhật WordPress an toàn kèm checklist để chủ doanh nghiệp và đội kỹ thuật cùng áp dụng lâu dài.

Lưu ý: Thông tin kỹ thuật trong bài được tổng hợp từ các nguồn công khai tính đến ngày 05/11/2026 và mang tính tham khảo. Vui lòng đối chiếu thông báo mới nhất của WordPress.org và nhà cung cấp hosting trước khi thao tác.

1. Lỗ hổng CVE-2026-119977: Vì sao lúc cập nhật lại là lúc nguy hiểm nhất?

Khi bạn bấm “Cập nhật ngay”, WordPress tải bộ cài đặt mới về và giải nén tạm vào thư mục wp-content/upgrade/. Theo phân tích của Picus Security – đơn vị phát hiện lỗ hổng – thư mục tạm này có đường dẫn dễ đoán và truy cập được từ Internet trên nhiều máy chủ. Trong đó có file cài đặt setup-config.php “tưởng” website chưa được cấu hình.

Kẻ tấn công liên tục dò đường dẫn này. Nếu trúng đúng vài phút website đang cập nhật, chúng có thể ghi đè file cấu hình wp-config.php, trỏ website sang cơ sở dữ liệu rỗng, tự tạo tài khoản quản trị rồi cài plugin độc hại để chạy mã trên máy chủ.

Một số mốc và số liệu chính:

• 28/10/2026: WordPress phát hành bản 7.1.4, vá 22 lỗ hổng, trong đó có lỗi race condition trong quá trình cập nhật core (WordPress.org).
• Mức độ: CVSS 8.1; ảnh hưởng WordPress từ 4.7 đến 7.1.3.
• Quy mô tấn công: Wordfence chặn 62.969 lượt tấn công nhắm vào lỗ hổng này chỉ trong 24 giờ (The Hacker News, 30/10/2026).
• 03/11/2026: CISA đưa CVE-2026-119977 vào danh mục lỗ hổng đang bị khai thác (KEV), yêu cầu cơ quan liên bang Mỹ khắc phục trước 06/11/2026 (Qualys).

Chỗ đáng lo nhất: theo Picus Security, lần cập nhật đầu tiên lên 7.1.4 vẫn chạy bằng bộ cập nhật cũ. Nghĩa là nếu chỉ bấm cập nhật như mọi khi, website vẫn có một “khe cửa” mở ra trong lúc nâng cấp. Vì vậy thứ tự thao tác quan trọng không kém việc có cập nhật hay không.

2. Website nào cần hành động ngay?

Hãy ưu tiên xử lý nếu website của doanh nghiệp rơi vào một trong các trường hợp sau:

• Đang chạy WordPress từ 4.7 đến 7.1.3 và chưa lên bản vá (7.1.4, hoặc bản vá cùng nhánh như 7.0.8, 6.9.11, 6.8.12…).
• Đang chạy WordPress 4.6 trở về trước: các nhánh này không còn được vá, cần nâng cấp lên phiên bản còn được hỗ trợ.
• Dùng hosting chia sẻ, không rõ nhà cung cấp có tự cập nhật hay chặn thư mục wp-content/upgrade/ hay không.
• Website bàn giao xong không ai phụ trách cập nhật, hoặc tắt tính năng tự cập nhật vì sợ lỗi giao diện.
• Website có form thu thập dữ liệu khách hàng, thanh toán hoặc tài khoản thành viên – thiệt hại khi bị chiếm quyền sẽ lớn hơn nhiều.

3. Quy trình 7 bước cập nhật WordPress an toàn

Quy trình dưới đây áp dụng cho lần cập nhật khẩn cấp lên 7.1.4 và cho mọi lần cập nhật về sau.

Bước 1: Kiểm kê phiên bản, hosting và quyền truy cập

Trước khi làm gì, cần biết mình đang có gì:

• Phiên bản WordPress hiện tại (xem ở Bảng tin → Cập nhật, hoặc lệnh wp core version nếu có WP-CLI).
• Phiên bản PHP, danh sách plugin và theme đang dùng, plugin nào đã lâu không được tác giả cập nhật.
• Loại hosting (chia sẻ, VPS, managed WordPress) và ai có quyền cấu hình web server.

Nhiều doanh nghiệp phát hiện ra mình không nắm tài khoản hosting đúng vào lúc cần vá khẩn cấp. Nếu đang chưa rõ, hãy rà soát lại quyền quản trị hosting và mã nguồn trước.

Bước 2: Sao lưu – và thử khôi phục

Sao lưu đủ hai phần: toàn bộ mã nguồn (bao gồm wp-content và wp-config.php) và cơ sở dữ liệu. Lưu bản sao ra ngoài máy chủ đang chạy website.

Bước hay bị bỏ qua là thử khôi phục. Một bản sao lưu chưa từng được khôi phục thử thì chưa thể coi là an toàn. Nếu có môi trường staging (bản sao của website để thử nghiệm), hãy khôi phục bản sao lưu lên đó và chạy thử cập nhật trước.

Bước 3: Chặn truy cập thư mục wp-content/upgrade/ trước khi cập nhật

Đây là bước mới, dành riêng cho lỗ hổng lần này. Patchstack và Picus Security cùng khuyến nghị chặn truy cập web vào wp-content/upgrade/ ngay tại web server. Tường lửa dạng plugin chạy bên trong WordPress không chặn được kiểu tấn công này (Webhosting.Today).

Ví dụ cấu hình tham khảo (để kỹ thuật viên hoặc nhà cung cấp hosting thực hiện):

• Nginx: thêm khối location ^~ /wp-content/upgrade/ { deny all; } vào cấu hình site.
• Apache (có quyền sửa virtual host): khối <Directory> trỏ tới thư mục wp-content/upgrade với Require all denied.
• Chỉ có quyền sửa .htaccess: thêm RedirectMatch 403 ^/wp-content/upgrade/ vào file .htaccess ở thư mục gốc, đặt phía trên khối # BEGIN WordPress.

Không đặt file .htaccess bên trong wp-content/upgrade/, vì bộ cập nhật cũ xóa nội dung thư mục này trước khi giải nén. Sau khi cấu hình, mở thử đường dẫn /wp-content/upgrade/ trên trình duyệt và xác nhận trả về lỗi 403 rồi mới cập nhật. Patchstack khuyên giữ quy tắc này lâu dài, vì “cửa sổ cập nhật” xuất hiện lại ở mọi lần cập nhật, kể cả cập nhật tự động. Đây cũng là một hạng mục nên bổ sung vào danh sách tối ưu bảo mật WordPress của doanh nghiệp.

Bước 4: Cập nhật theo đúng thứ tự, từng phần một

Chọn khung giờ ít truy cập và có người trực. Sau đó:

1. Cập nhật WordPress core lên 7.1.4 (hoặc bản vá cùng nhánh). Với WP-CLI có thể dùng wp core check-update rồi wp core update --minor để lấy bản vá bảo mật cùng nhánh; Picus Security lưu ý dùng WP-CLI cũng không tự tránh được lỗ hổng, nên vẫn phải làm Bước 3 trước.
2. Cập nhật plugin từng cái, bắt đầu từ plugin bảo mật, form, thanh toán. Không chọn “cập nhật tất cả” cùng lúc: khi có lỗi sẽ khó biết plugin nào gây ra.
3. Cập nhật theme (nên dùng child theme để không mất phần tùy biến).
4. Ghi lại phiên bản trước và sau của từng thành phần vào nhật ký bảo trì.

Nếu website bật cập nhật tự động, WordPress sẽ tự lên 7.1.4. Tuy vậy vẫn cần vào kiểm tra phiên bản thực tế, vì cập nhật tự động có thể thất bại mà không báo lỗi (Tech Insider). Dùng managed hosting thì nên xin xác nhận bằng văn bản rằng nhà cung cấp đã cập nhật.

Bước 5: Kiểm tra sau cập nhật – cả chức năng lẫn dấu hiệu xâm nhập

Về chức năng, kiểm tra những phần tạo ra khách hàng: trang chủ, trang dịch vụ, form liên hệ (gửi thử và xem email có về không), giỏ hàng, thanh toán, chatbot, giao diện trên điện thoại. Có thể dùng lại checklist test website khi nghiệm thu.

Về bảo mật, theo khuyến nghị từ Wordfence và các báo cáo liên quan:

• Chạy wp core verify-checksums để phát hiện file lõi bị sửa.
• Rà danh sách tài khoản quản trị (wp user list --role=administrator hoặc mục Thành viên), xóa tài khoản lạ.
• Tìm plugin lạ và file PHP bất thường, đặc biệt trong wp-content/upgrade/.
• Xem log truy cập có request tới setup-config.php trong thư mục upgrade hay không.
• Kiểm tra website có bất ngờ hiện màn hình cài đặt WordPress hay không.

Nếu thấy dấu hiệu bất thường, hãy chuyển sang quy trình xử lý website WordPress bị hack thay vì tiếp tục cập nhật.

Kiểm tra chức năng và bảo mật ngay sau khi cập nhật

Bước 6: Chuẩn bị sẵn kế hoạch quay lại (rollback)

Trước khi cập nhật, cần trả lời được ba câu: nếu website lỗi thì ai quyết định quay lại, khôi phục từ bản sao lưu nào, và mất bao lâu. Lưu ý: quay lại bản WordPress cũ cũng là quay lại lỗ hổng. Vì vậy khi một plugin xung đột với 7.1.4, ưu tiên tắt hoặc thay plugin đó, giữ nguyên bản vá core.

Bước 7: Lập lịch cập nhật định kỳ và phân công người chịu trách nhiệm

Riêng bản 7.1 đã có bốn bản vá trong sáu tuần, vá tổng cộng 41 vấn đề bảo mật (Webhosting.Today). Nhịp đó cho thấy cập nhật không thể là việc “khi nào nhớ thì làm”. Doanh nghiệp nên có lịch cố định (ví dụ mỗi tuần kiểm tra bản cập nhật, vá bảo mật trong 24–48 giờ khi có cảnh báo), ghi rõ ai làm trong hợp đồng bảo trì website sau bàn giao.

4. Checklist cập nhật WordPress an toàn

Trước khi cập nhật

• ☐ Biết phiên bản WordPress, PHP, plugin, theme hiện tại
• ☐ Có tài khoản hosting và người có quyền sửa cấu hình web server
• ☐ Sao lưu mã nguồn + cơ sở dữ liệu, lưu ngoài máy chủ
• ☐ Đã thử khôi phục bản sao lưu (lý tưởng là trên staging)
• ☐ /wp-content/upgrade/ trả về lỗi 403

Trong khi cập nhật

• ☐ Cập nhật core trước, rồi plugin từng cái, cuối cùng là theme
• ☐ Ghi lại phiên bản trước/sau

Sau khi cập nhật

• ☐ Phiên bản thực tế là 7.1.4 hoặc bản vá cùng nhánh
• ☐ Form, giỏ hàng, thanh toán, chatbot, giao diện mobile hoạt động
• ☐ Không có tài khoản quản trị, plugin hay file PHP lạ
• ☐ File lõi khớp checksum
• ☐ Giữ quy tắc chặn wp-content/upgrade/ cho các lần sau

5. Doanh nghiệp, hosting và đơn vị bảo trì: Ai chịu trách nhiệm phần nào?

Sự cố thường xảy ra ở khoảng trống giữa các bên, khi ai cũng nghĩ người khác đã làm.

Một số câu hỏi thường gặp

Có nên hoãn cập nhật WordPress vì sợ bị tấn công trong lúc cập nhật không? Không. Bản 7.1.4 còn vá 21 lỗ hổng khác, hoãn lại là để website tiếp tục mở với các lỗ hổng đó. Cách đúng là chặn thư mục wp-content/upgrade/ trước rồi cập nhật ngay.

Làm sao biết website đã an toàn với CVE-2026-119977? Phiên bản thực tế phải là 7.1.4 hoặc bản vá cùng nhánh (7.0.8, 6.9.11, 6.8.12…), và đường dẫn /wp-content/upgrade/ trả về lỗi 403.

Website đang bật tự động cập nhật thì có cần làm gì không? Có. Vẫn cần kiểm tra phiên bản thực tế và chặn thư mục upgrade, vì cửa sổ tấn công xuất hiện cả trong lúc cập nhật tự động.

Plugin bảo mật như Wordfence có đủ để chặn lỗ hổng này không? Không nên chỉ dựa vào plugin. Patchstack cho rằng tường lửa chạy trong WordPress không chặn được kiểu tấn công này; theo Tech Insider, quy tắc cho bản Wordfence miễn phí đến 27/11/2026 mới có. Chặn ở web server vẫn là bước cần thiết.

Website chạy WordPress 4.x cũ thì sao? Nhánh 4.7–4.9 có bản vá (4.7.39, 4.8.34, 4.9.35). Bản 4.6 trở về trước không còn được vá và cần nâng cấp; với website quá cũ, nên cân nhắc làm lại thay vì vá từng phần.

Nếu nghi ngờ website đã bị xâm nhập thì làm gì trước? Không tiếp tục cập nhật. Sao lưu hiện trạng để điều tra, đổi mật khẩu quản trị, hosting, cơ sở dữ liệu, rồi liên hệ đơn vị kỹ thuật để làm sạch trước khi vá.

Wecan Group – Dịch vụ bảo trì và bảo mật website WordPress

Cập nhật WordPress an toàn không khó, nhưng cần đúng thứ tự, đúng người và được làm đều đặn. Wecan Group hỗ trợ doanh nghiệp rà soát phiên bản, thiết lập sao lưu, cấu hình chặn thư mục nhạy cảm và xây dựng quy trình cập nhật định kỳ trong gói bảo trì website sau bàn giao.

Nếu doanh nghiệp chưa chắc website của mình đã lên bản vá hay chưa, hãy liên hệ Wecan Group để được kiểm tra và tư vấn phương án phù hợp.