WordPress vừa phát hành bản vá khẩn cấp cho hai lỗ hổng trong core: CVE-2026-60137 và CVE-2026-63030. Khi kết hợp, chuỗi lỗ hổng có thể dẫn tới thực thi mã từ xa mà không cần đăng nhập. Nếu website đang chạy WordPress 6.8, 6.9 hoặc 7.0, việc cần làm ngay không phải là đọc hết phân tích kỹ thuật, mà là kiểm tra phiên bản, tạo bản sao lưu và cập nhật. Cảnh báo CVE-2026-63030 WordPress đã được WordPress.org công bố trong bản phát hành bảo mật ngày 17/07/2026 [1].
Tóm tắt nhanh:
- WordPress 6.8.x cần cập nhật tối thiểu lên 6.8.6.
- WordPress 6.9.x cần cập nhật tối thiểu lên 6.9.5.
- WordPress 7.0.x cần cập nhật tối thiểu lên 7.0.2.
- Không nên chỉ dựa vào auto-update; hãy xác nhận phiên bản thực tế và kiểm tra website sau cập nhật.
- WAF là lớp giảm thiểu rủi ro trong lúc cập nhật, không thay thế bản vá WordPress core.
Nội dung chính

CVE-2026-63030 WordPress và CVE-2026-60137 là gì?
CVE-2026-60137 là lỗ hổng SQL Injection liên quan đến cách WordPress xử lý tham số author__not_in trong WP_Query. Theo NVD, rủi ro xuất hiện khi plugin hoặc theme truyền dữ liệu không đáng tin cậy vào tham số này mà không kiểm soát đúng cách.
CVE-2026-63030 liên quan đến sự không đồng bộ giữa bước kiểm tra và bước điều phối request trong REST API batch route. Wordfence đánh giá lỗ hổng này ở mức nghiêm trọng, CVSS 9.8 [2]. Khi kết hợp với SQL Injection, kẻ tấn công có thể tiến tới thực thi mã trên máy chủ mà không cần tài khoản. Khi tìm thông tin về CVE-2026-63030 WordPress, bạn nên ưu tiên advisory chính thức thay vì thử các đoạn mã khai thác đang được chia sẻ công khai.
Điểm đáng chú ý là đây là lỗ hổng trong WordPress core, không phải một plugin ít người dùng. Vì vậy, website ít plugin hoặc đã cài plugin bảo mật vẫn cần cập nhật core.

Phiên bản WordPress nào bị ảnh hưởng?
| Nhánh WordPress | Rủi ro | Phiên bản cần cập nhật |
|---|---|---|
| Trước 6.8 | WordPress.org cho biết không bị ảnh hưởng bởi hai lỗi này | Nên tiếp tục theo nhánh được hỗ trợ phù hợp |
| 6.8.x | Bị ảnh hưởng bởi CVE-2026-60137 | 6.8.6 trở lên |
| 6.9.x | Bị ảnh hưởng bởi cả hai lỗ hổng | 6.9.5 trở lên |
| 7.0.x | Bị ảnh hưởng bởi cả hai lỗ hổng | 7.0.2 trở lên |
| 7.1 beta | Bản beta đầu bị ảnh hưởng | 7.1 beta 2 trở lên |
WordPress.org đã bật cơ chế cập nhật bắt buộc qua hệ thống auto-update cho các phiên bản bị ảnh hưởng. Dù vậy, môi trường hosting, quyền ghi file, cấu hình Git hoặc chính sách tắt cập nhật tự động có thể khiến một website không nhận bản vá như kỳ vọng.
Nếu quản lý website cho khách hàng, hãy lập danh sách theo từng domain gồm phiên bản core, trạng thái backup, thời điểm cập nhật và kết quả kiểm thử. Với đội có nhiều site, đây là cách tránh tình trạng một website staging đã được vá nhưng production vẫn còn phơi nhiễm. Cảnh báo CVE-2026-63030 WordPress nên được xử lý như một change request khẩn cấp, có người chịu trách nhiệm và thời hạn hoàn thành rõ ràng.
Cách kiểm tra và cập nhật WordPress an toàn
1. Xác nhận phiên bản đang chạy
Đăng nhập Dashboard, mở Dashboard → Updates và ghi lại phiên bản hiện tại. Nếu quản lý nhiều website, hãy kiểm tra từng site thay vì suy đoán từ cấu hình chung của hosting.
2. Tạo backup có thể khôi phục
Backup cả database và file trước khi cập nhật. Một file ZIP đơn lẻ chưa đủ nếu bạn chưa từng thử restore. Quy trình backup và diễn tập khôi phục WordPress giúp bạn biết bản sao lưu có thực sự dùng được hay không.
3. Cập nhật core lên phiên bản đã vá
Trong Dashboard, chọn Update Now. Nếu website dùng quy trình deployment bằng Git hoặc Composer, hãy cập nhật theo pipeline hiện có để tránh tạo chênh lệch giữa production và repository.
Không thấy bản vá cùng nhánh? Cập nhật bằng WP Downgrade
Một số website đang chạy WordPress 6.x không hiển thị bản vá bảo mật cùng nhánh trong Dashboard → Updates, mà chỉ đề nghị nâng thẳng lên WordPress 7.x. Ví dụ, site đang ở 6.9.4 cần lên đúng 6.9.5 để vá hai CVE nhưng màn hình cập nhật lại chỉ hiện phiên bản major mới. Trong trường hợp này, bạn có thể dùng tạm plugin WP Downgrade | Specific Core Version để yêu cầu routine cập nhật core cài đúng phiên bản 6.9.5.
Tên plugin có chữ “Downgrade”, nhưng tài liệu của plugin cho biết phiên bản đích có thể thấp hơn hoặc cao hơn phiên bản hiện tại [6]. Vì vậy, thao tác từ 6.9.4 lên 6.9.5 thực chất vẫn là một bản nâng cấp bảo mật trong cùng nhánh.
- Backup file và database: không bỏ qua bước này. Việc thay core luôn có rủi ro và sẽ ghi đè các file WordPress mặc định.
- Cài plugin: vào Plugins → Add New Plugin, tìm “WP Downgrade | Specific Core Version”, cài đặt rồi kích hoạt.
- Đặt phiên bản đích: mở Settings → WP Downgrade, nhập chính xác
6.9.5vào ô phiên bản WordPress đích rồi lưu thay đổi. - Mở màn hình cập nhật: dùng nút chuyển tới cập nhật core của plugin hoặc vào Dashboard → Updates.
- Kiểm tra trước khi bấm: màn hình phải ghi rõ sẽ cài hoặc cài lại WordPress 6.9.5. Nếu vẫn hiện 7.x, dừng lại và không tiếp tục.
- Chạy cập nhật: bấm nút cập nhật/cài lại, chờ hoàn tất và không đóng trình duyệt giữa quá trình.
- Xác nhận kết quả: kiểm tra footer Dashboard hoặc Dashboard → Updates phải hiển thị WordPress 6.9.5, sau đó chạy lại các bước kiểm thử website.
Quan trọng: sau khi cập nhật thành công, hãy xóa giá trị phiên bản đích trong WP Downgrade hoặc tắt và gỡ plugin. Nếu để plugin hoạt động với 6.9.5 được ghim cố định, WordPress có thể tiếp tục coi 6.9.5 là phiên bản mong muốn và không đề xuất bản bảo mật kế tiếp như bạn kỳ vọng.
Trang WordPress.org hiện cảnh báo WP Downgrade chưa được kiểm thử với ba major WordPress mới nhất và phiên bản plugin 1.2.6 đã lâu chưa cập nhật [6]. Vì vậy, đây nên là giải pháp ngắn hạn để chọn đúng bản vá, không phải thành phần vận hành lâu dài. Nếu plugin không hiện nút update/reinstall, nguyên nhân có thể là cấu hình WP_AUTO_UPDATE_CORE, custom filter, plugin khác, theme hoặc mu-plugin của hosting đang chặn kiểm tra update. Không nên xóa các cấu hình này trên production khi chưa hiểu vai trò; hãy kiểm tra staging hoặc nhờ nhà cung cấp hosting hỗ trợ.
4. Kiểm tra chức năng sau cập nhật
Mở trang chủ, trang đăng nhập, form liên hệ, checkout nếu có WooCommerce, tác vụ cron và REST API mà hệ thống đang dùng hợp lệ. Kiểm tra error log để phát hiện lỗi PHP hoặc xung đột plugin.
5. Ghi nhận thay đổi
Lưu thời điểm cập nhật, phiên bản trước và sau, người thực hiện, kết quả kiểm tra và sự cố phát sinh. Với website doanh nghiệp, nhật ký thay đổi giúp xử lý nhanh hơn nếu vài ngày sau mới xuất hiện lỗi.
6. Kiểm tra cache và bản sao website
Sau khi cập nhật, hãy xóa cache ứng dụng, object cache và CDN theo quy trình của hệ thống. Đồng thời kiểm tra subdomain, bản staging, website cũ và môi trường clone. Những bản sao ít được chú ý vẫn có thể chạy phiên bản dễ bị tấn công, đặc biệt khi chúng cùng dùng credential hoặc kết nối tới tài nguyên production.

WAF có bảo vệ được website chưa cập nhật không?
Cloudflare đã triển khai hai rule để phát hiện request liên quan đến CVE-2026-60137 và CVE-2026-63030 [3]. Khách hàng gói Free được bảo vệ qua Free Ruleset; các gói Pro, Business và Enterprise cần bảo đảm Managed Rules đang bật và action của rule không bị đổi từ Block sang Log. Đây là lớp giảm thiểu đáng dùng trong thời gian xử lý CVE-2026-63030 WordPress.
Nếu đang dùng Wordfence, bạn cũng cần hiểu độ trễ của rule theo từng gói. Theo thông báo ngày 17/07/2026, nhóm khách hàng trả phí nhận rule ngay, còn Wordfence Free dự kiến nhận rule sau 30 ngày. Thông tin này có thể thay đổi, nên hãy kiểm tra trạng thái rule thực tế trong dashboard.
WAF là lớp phòng thủ bổ sung. Nó giúp giảm cửa sổ phơi nhiễm khi đội kỹ thuật chưa thể cập nhật ngay, nhưng không sửa mã nguồn đang có lỗi. Khuyến nghị của mình vẫn là: patch core trước, sau đó dùng WAF để tăng phòng thủ chiều sâu.

Nếu nghi website đã bị khai thác thì làm gì?
Nếu phát hiện tài khoản admin lạ, file PHP mới, cron bất thường, redirect, spam SEO, thay đổi cấu hình hoặc request đáng ngờ tới REST API, đừng chỉ cập nhật rồi xem như đã xong. Bản vá chặn đường vào mới nhưng không tự xóa backdoor đã tồn tại.
- Cô lập website hoặc bật maintenance mode phù hợp.
- Giữ lại log web server, WAF, authentication và file integrity để điều tra.
- Đổi credential WordPress, hosting, database, SFTP/SSH và API key liên quan.
- Quét malware, kiểm tra user admin, mu-plugin, cron, theme và plugin.
- Khôi phục từ backup sạch nếu không thể xác định đầy đủ phạm vi xâm nhập.
- Cập nhật toàn bộ hệ thống rồi giám sát sau sự cố.
Đừng xóa log hoặc cài lại vội trước khi lưu bằng chứng cần thiết. Nếu website xử lý đơn hàng, thông tin khách hàng hoặc tích hợp hệ thống nội bộ, phạm vi đánh giá không nên dừng ở WordPress. Hãy kiểm tra API key, webhook, tài khoản cloud và các máy chủ liên quan. Tác động của CVE-2026-63030 WordPress phụ thuộc vào quyền mà tiến trình web có trên hạ tầng thực tế.
Bạn có thể dùng checklist xử lý 24 giờ đầu khi website bị hack và quy trình scan malware WordPress để không bỏ sót bước quan trọng.

Bạn đang đọc bài viết thuộc chuyên mục Bảo mật website của VietnamTutor — nơi mình chia sẻ các quy trình bảo vệ và vận hành website doanh nghiệp theo hướng thực tế, có thể kiểm tra.
Kết luận
CVE-2026-60137 và CVE-2026-63030 là tình huống không nên trì hoãn. Hãy xác nhận website đã lên 6.8.6, 6.9.5 hoặc 7.0.2 tùy nhánh; kiểm tra lại chức năng; bật WAF phù hợp; và điều tra sâu nếu có dấu hiệu bất thường. Sau khi xử lý CVE-2026-63030 WordPress, nên đưa bước kiểm tra phiên bản core vào quy trình audit bảo mật WordPress hàng tháng.
Câu hỏi thường gặp
WordPress 6.8 có bị CVE-2026-63030 không?
Theo WordPress.org, nhánh 6.8 chỉ bị ảnh hưởng bởi lỗ hổng SQL Injection CVE-2026-60137, không bị lỗi RCE CVE-2026-63030. Bạn vẫn cần cập nhật lên ít nhất 6.8.6.
Cài plugin bảo mật rồi có cần cập nhật WordPress không?
Có. Plugin bảo mật hoặc WAF chỉ là lớp giảm thiểu. Chúng không thay thế bản vá trong WordPress core.
Làm sao biết auto-update đã thành công?
Mở Dashboard → Updates và kiểm tra số phiên bản thực tế. Sau đó kiểm thử trang chủ, đăng nhập, form, checkout, cron và error log.
Cập nhật xong có cần scan malware không?
Nếu website từng phơi nhiễm hoặc có dấu hiệu bất thường, nên scan malware và kiểm tra log. Bản vá không tự loại bỏ backdoor đã được cài trước đó.
