WordPress CVE-2026-60137 và CVE-2026-63030: Cập nhật ngay

Nội dung

WordPress vừa vá hai lỗ hổng core có thể kết hợp thành chuỗi thực thi mã từ xa. Đây là cách kiểm tra phiên bản, cập nhật an toàn và xử lý nếu website có dấu hiệu bị xâm nhập.

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.
CVE-2026-63030 WordPress và quy trình cập nhật khẩn cấp
Hai lỗ hổng WordPress core yêu cầu quản trị viên kiểm tra và cập nhật ngay.

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.

Sơ đồ chuỗi lỗ hổng SQL Injection dẫn tới thực thi mã từ xa
Hai lỗ hổng có thể kết hợp thành chuỗi tấn công nghiêm trọng.

Phiên bản WordPress nào bị ảnh hưởng?

Nhánh WordPressRủi roPhiên bản cần cập nhật
Trước 6.8WordPress.org cho biết không bị ảnh hưởng bởi hai lỗi nàyNên tiếp tục theo nhánh được hỗ trợ phù hợp
6.8.xBị ảnh hưởng bởi CVE-2026-601376.8.6 trở lên
6.9.xBị ảnh hưởng bởi cả hai lỗ hổng6.9.5 trở lên
7.0.xBị ảnh hưởng bởi cả hai lỗ hổng7.0.2 trở lên
7.1 betaBản beta đầu bị ảnh hưởng7.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.

  1. 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.
  2. 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.
  3. Đặt phiên bản đích: mở Settings → WP Downgrade, nhập chính xác 6.9.5 vào ô phiên bản WordPress đích rồi lưu thay đổi.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Quy trình năm bước cập nhật bản vá WordPress an toàn
Quy trình cập nhật nên bao gồm backup và kiểm thử, không chỉ bấm Update.

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.

Phòng thủ nhiều lớp cho WordPress gồm bản vá WAF và giám sát
WAF hỗ trợ giảm thiểu rủi ro nhưng không thay thế bản vá core.

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.

  1. Cô lập website hoặc bật maintenance mode phù hợp.
  2. Giữ lại log web server, WAF, authentication và file integrity để điều tra.
  3. Đổi credential WordPress, hosting, database, SFTP/SSH và API key liên quan.
  4. Quét malware, kiểm tra user admin, mu-plugin, cron, theme và plugin.
  5. Khôi phục từ backup sạch nếu không thể xác định đầy đủ phạm vi xâm nhập.
  6. 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.

Quy trình ứng phó sự cố WordPress sau lỗ hổng RCE
Website nghi bị khai thác cần đi theo quy trình ứng phó sự cố đầy đủ.

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 đó.

Nguồn tham khảo

  1. WordPress.org — WordPress 7.0.2 Release
  2. Wordfence — WordPress core RCE vulnerability chain
  3. Cloudflare — WAF protection for WordPress vulnerabilities
  4. NVD — CVE-2026-60137
  5. NVD — CVE-2026-63030
  6. WordPress.org — WP Downgrade | Specific Core Version
Tú Anh

Cây bút chính tại VietnamTutor

Bài viết cùng chuyên mục

Audit bảo mật WordPress hàng tháng trong 30 phút

Bài viết hướng dẫn bạn chạy audit bảo mật WordPress hàng tháng trong 30 phút, tập trung vào những việc dễ bỏ sót nhưng ảnh hưởng

Cách quét mã độc WordPress: Checklist phát hiện và xử lý sớm

Scan malware WordPress cần kết hợp file integrity, user, redirect và cảnh báo lỗ hổng theo lịch rõ ràng.

Làm gì khi website bị hack? 10 bước cần xử lý ngay trong 24 giờ

Website bị hack cần được cô lập, sao lưu hiện trạng và làm sạch theo quy trình. Đây là checklist xử lý an toàn trong 24

Security headers WordPress: Cách cấu hình HTTP headers bảo mật

Security headers là lớp bảo vệ HTTP giúp browser chặn tấn công. Hướng dẫn cấu hình 6 headers quan trọng cho WordPress.

WAF WordPress là gì? Cách chọn và cấu hình phù hợp

WAF (Web Application Firewall) là lớp bảo vệ quan trọng nhất cho website WordPress. Hướng dẫn chi tiết cách cài đặt và cấu hình WAF năm

Query Monitor dính lỗ hổng XSS CVE-2026-4267: Cách kiểm tra

Lỗ hổng XSS (CVE-2026-4267) được phát hiện trong Query Monitor plugin WordPress. Tìm hiểu cách kiểm tra và bảo vệ website của bạn ngay hôm nay.

OWASP Top 10 2026: 10 lỗ hổng bảo mật web cần biết

OWASP Top 10 2026 liệt kê 10 lỗ hổng bảo mật web nguy hiểm nhất mà developer và doanh nghiệp cần phòng tránh. Bài viết giải

Báo cáo bảo mật WordPress 2026: Vì sao cần đổi cách update plugin?

Báo cáo State of WordPress Security 2026 cho thấy lỗ hổng WordPress tăng 42%, thời gian khai thác chỉ còn 5 giờ. Chủ website cần đổi

Bảo mật WordPress: 10 bước thực hành chống tấn công

Hướng dẫn bảo mật WordPress toàn diện 2026: 10 bước thực chiến giúp website chống lại 99% cuộc tấn công từ plugin lỗi thời, brute-force đến

Mã độc VS Code, Go, npm, Rust: Nguy cơ đánh cắp dữ liệu dev

Mã độc trong VS Code extensions, gói Go, npm, Rust đang âm thầm đánh cắp dữ liệu dev. Tìm hiểu cách bảo vệ thông tin cá

Lỗ hổng RCE (CVE-2025-55182) trên React, Next.js?

Cảnh báo khẩn cấp: React2Shell (CVE-2025-55182) gây RCE nghiêm trọng cho React/Next.js. Nắm cơ chế, dấu hiệu & phòng thủ cấp bách để bảo vệ ứng