wp2shell: lỗ hổng WordPress core bị khai thác thực tế — chain 2 CVE, vá 6.9.5 / 7.0.2 ngay

Ngày 17/07/2026, WordPress phát hành bản vá khẩn cho hai lỗ hổng nằm trong chính mã lõi — không phải plugin, không phải theme. Ghép lại, chúng cho phép một request HTTP ẩn danh chạy được mã trên máy chủ. Bộ đôi này được đặt tên wp2shell. Ba ngày sau, ngày 20/07, nhiều hãng bảo mật xác nhận nó đang bị khai thác thực tế. Bài này dựng lại mốc thời gian, giải thích cơ chế chain hai CVE, chỉ rõ ai dính và đưa checklist doanh nghiệp Việt phải chạy trong 24 giờ.

Chuyện gì đã xảy ra?

Ngày 17/07/2026, WordPress phát hành bản 7.0.2 để xử lý một lỗi mức critical và một lỗi mức high, đồng thời khuyến cáo cập nhật ngay lập tức. Thông báo phát hành do John Blackbourn ký tên nói rõ: vì mức độ nghiêm trọng, đội WordPress.org đã bật cập nhật cưỡng bức qua hệ thống auto-update cho các site đang chạy phiên bản dính.

Nhóm tìm ra lỗ hổng là Searchlight Cyber, qua bộ phận nghiên cứu Assetnote. Trong bài công bố ngày 17/07, nhà nghiên cứu Adam Kues mô tả đây là lỗi thực thi mã từ xa tiền xác thực trong WordPress core, và nhấn mạnh rằng cuộc tấn công không có điều kiện tiên quyết nào — kẻ ẩn danh khai thác được trên một bản WordPress cài mặc định, không plugin. Nhóm này cố tình không công bố chi tiết kỹ thuật để người quản trị có thời gian vá, chỉ đưa ra một công cụ kiểm tra công khai tại wp2shell.com.

Khoảng lặng đó không kéo dài. Trong vòng một ngày, cơ chế đầy đủ đã được các nhà nghiên cứu khác dựng lại từ chính bản vá — vì WordPress là mã nguồn mở, bản phát hành nêu rõ những file đã đổi — và một mã khai thác chạy được (PoC) xuất hiện công khai trên GitHub. Đến 20/07, TechCrunch và SecurityWeek đồng loạt đưa tin lỗ hổng đang bị khai thác thực tế.

Đọc bảng theo đúng trình tự là thấy bài học: khoảng cách từ "đã vá" đến "đang bị đánh" chỉ còn ba ngày. Trao đổi với SecurityWeek, ông Benjamin Harris — CEO watchTowr — nhận xét rằng PoC xuất hiện trong vài giờ sau công bố, trong khi trước đây thường mất từ 24 giờ trở lên, và cho rằng khoảng trống giữa công bố và khai thác đã co lại đáng kể.

Chain hai CVE hoạt động thế nào?

wp2shell không phải một lỗi, mà là hai lỗi nhỏ ghép lại: một lỗi SQL injection bị "khoá" sau lớp xác thực, và một lỗi nhầm lẫn định tuyến giúp mở khoá đó cho người dùng ẩn danh. Tách riêng, mỗi lỗi khó khai thác. Ghép lại, chúng biến một request HTTP không đăng nhập thành quyền chạy mã trên máy chủ.

Mảnh thứ nhất — SQL injection (CVE-2026-60137). Theo mô tả chính thức trên NVD, WordPress không làm sạch đúng tham số author__not_in của WP_Query, dẫn tới SQL injection khi một plugin hoặc theme truyền dữ liệu không tin cậy vào tham số này. Bản chất là một tham số vốn được kỳ vọng nhận mảng, nhưng khi nhận vào một chuỗi thì lớp kiểm tra bị bỏ qua.

Mảnh thứ hai — nhầm lẫn định tuyến ở batch endpoint (CVE-2026-63030). Cũng theo NVD, WordPress 6.9.x trước 6.9.5 và 7.0.x trước 7.0.2 dính lỗi nhầm lẫn tuyến ở REST API batch endpoint; kết hợp với lỗi SQL injection nói trên thì kẻ tấn công có thể thực hiện SQL injection và đạt tới thực thi mã từ xa. Batch endpoint là tính năng cho phép gộp nhiều request con vào một lời gọi /wp-json/batch/v1. Cơ chế được The Hacker News mô tả: hệ thống theo dõi các request con bằng hai mảng song song, và khi một request con lỗi thì hai mảng bị lệch nhau một nhịp — hệ quả là một request bị xử lý bởi handler của request khác, đi vòng qua danh sách cho phép của endpoint.

Điểm cần nhớ với người vận hành: đây là lỗi trong mã lõi. Bạn không cần cài thêm gì để "rước" nó về. Ảnh minh hoạ dưới đây nhắc lại đúng điều đó — vấn đề nằm ở dòng code lõi, không phải ở kho plugin.

Có một điều kiện thu hẹp phạm vi, và cần hiểu cho đúng: đường thực thi mã chỉ đi được khi site không dùng persistent object cache. Chi tiết này do Cloudflare nêu ra và được Rapid7 lẫn The Hacker News dẫn lại. Vấn đề là một bản cài WordPress mặc định vốn không có cache kiểu đó, nên rủi ro với cài đặt mặc định vẫn nguyên vẹn. Nếu site của bạn đang chạy Redis hay Memcached làm persistent object cache, bạn có thể nằm ngoài đường tấn công cụ thể này — nhưng đó là tác dụng phụ, không phải bản vá, và nó hoàn toàn không che chắn cho lỗi SQL injection.

Ai dính, ai không?

Nếu site của bạn chạy WordPress 6.9.0–6.9.4 hoặc 7.0.0–7.0.1, bạn dính đủ cả chain RCE. Nếu chạy 6.8.0–6.8.5, bạn chỉ dính lỗi SQL injection chứ không dính chain thực thi mã, vì mảnh nhầm lẫn định tuyến chỉ tồn tại từ 6.9 trở đi. Bản trước 6.8 không bị ảnh hưởng bởi cả hai. Đây là điểm mà nhiều bản tin tóm tắt sai — nên bảng dưới tách riêng từng CVE.

*Cách đọc: cột "Bản đã vá" là phiên bản tối thiểu cần đạt tới trên chính nhánh bạn đang chạy. Không cần nhảy nhánh — site 6.9.4 chỉ cần lên 6.9.5. Lưu ý bài công bố của Searchlight Cyber liệt kê "≤ 6.8.5: không ảnh hưởng" khi nói riêng về chain RCE, trong khi thông báo phát hành của WordPress ghi rõ nhánh 6.8 vẫn dính lỗi SQL injection và được vá ở 6.8.6 — hai cách diễn đạt không mâu thuẫn, chỉ khác phạm vi đang nói.

Vì sao mỗi nơi ghi một điểm CVSS khác nhau?

Bạn sẽ thấy cùng một lỗ hổng bị chấm 9,8 ở chỗ này và 7,5 ở chỗ khác — không ai sai cả, đơn giản là bản ghi NVD chứa hai bộ điểm từ hai bên chấm độc lập: WPScan (đơn vị cấp mã CVE cho hai lỗi này) và CISA-ADP (chương trình bổ sung dữ liệu của CISA). Điều thú vị: hai bên xếp hạng ngược nhau về việc lỗi nào nặng hơn.

Hệ quả thực tế: nếu công cụ quản lý lỗ hổng của bạn chỉ lọc theo ngưỡng "≥ 9,0" trên một nguồn điểm duy nhất, bạn có thể bỏ sót đúng cái CVE quan trọng. Nhìn vào vector mới thấy gốc của chênh lệch ở CVE-2026-60137: ba trong bốn bộ điểm ghi AC:L (độ khó thấp), riêng WPScan chấm lỗi này ở AC:H — độ khó cao — và chỉ tính mất tính bí mật (C:H/I:N/A:N), nên ra 5,9; CISA-ADP chấm cùng lỗi đó ở AC:L kèm cả mất tính toàn vẹn (C:H/I:H/A:N), nên ra 9,1. Đó chính là chỗ 5,9 và 9,1 tách nhau, chứ không phải một bên "chấm nhầm".

Phần thật sự chung của cả bốn bộ điểm là AV:N, PR:N, UI:N: tấn công qua mạng, không cần tài khoản, không cần người dùng bấm gì. Đó mới là dữ kiện đáng dùng để xếp ưu tiên, chứ không phải con số cuối cùng.

Cũng nên biết: bản danh mục KEV (Known Exploited Vulnerabilities) của CISA mà chúng tôi tải ngày 21/07/2026 có catalogVersion 2026.07.16 với 1.647 mã, và chưa chứa hai CVE này. KEV chỉ thêm lỗ hổng khi có bằng chứng khai thác đã xác nhận, và danh mục cập nhật theo nhịp riêng — vắng mặt trong KEV không có nghĩa là an toàn, nhất là khi các hãng bảo mật đã báo tấn công thực tế từ 20/07.

Cập nhật cưỡng bức là gì, và vì sao vẫn phải tự kiểm?

WordPress.org đã bật cập nhật cưỡng bức qua hệ thống auto-update cho các site chạy phiên bản dính — nghĩa là bản vá được đẩy xuống mà không chờ quản trị viên bấm nút. Đây là biện pháp hiếm khi dùng, và nó đã cứu rất nhiều site. Nhưng nó không phải một lời bảo đảm, vì ba lý do cụ thể.

Một: cơ chế này đi qua hệ thống auto-update, nên site đã tắt auto-update là một dấu hỏi — The Hacker News ghi nhận WordPress chưa nói rõ liệu đợt đẩy cưỡng bức có với tới nhóm này hay không, và khuyên hãy kiểm tra thực tế đang chạy phiên bản nào thay vì mặc định là đã vá. Hai: chính Rapid7 khuyến nghị quản trị viên vẫn phải xác minh từng website hướng ra Internet đã lên 6.9.5, 7.0.2 hay bản đã vá phù hợp với nhánh của nó. Ba: cập nhật thành công không xoá dấu vết của một vụ xâm nhập đã xảy ra trước khi vá — nếu site bạn hở trong khoảng 17→20/07, vá xong vẫn phải rà.

Mặt tích cực: hạ tầng phía trên cũng đã vào cuộc. Cloudflare triển khai luật WAF phát hiện và chặn chain này cho khách hàng đứng sau họ. Về phía nhà cung cấp hosting, người phát ngôn của Automattic nói với TechCrunch rằng toàn bộ site do Automattic vận hành — gồm WordPress.com, Pressable, WPVIP và các đối tác WP.cloud — đã được bảo vệ ngay cả trước khi bản vá phát hành, và mã cập nhật được triển khai ngay khi công bố. Nếu bạn thuê hosting quản trị, câu hỏi đầu tiên nên hỏi họ chính là: site của tôi đã lên phiên bản nào, lúc mấy giờ?

Doanh nghiệp Việt phải làm gì trong 24 giờ?

Việc số một, làm trong một giờ đầu, là mở trang quản trị của từng website WordPress và đọc con số phiên bản thật — không hỏi ai, không suy đoán từ "chắc hosting lo rồi". Nếu chưa đạt 6.9.5 / 7.0.2 / 6.8.6 tuỳ nhánh, cập nhật ngay. Bảng dưới sắp việc theo mức khẩn, tổng hợp từ khuyến nghị của WordPress.org, Searchlight Cyber và Rapid7.

*Lưu ý về các biện pháp tạm: chính Searchlight Cyber cảnh báo rằng chặn REST API hay chặn batch endpoint có thể làm hỏng các tích hợp hợp lệ của site, và chỉ nên coi là biện pháp khẩn cấp tạm thời cho tới khi cập nhật được. Rapid7 thì khuyến nghị không dùng workaround thay cho việc vá.

Một góc nhìn cho lãnh đạo doanh nghiệp: sự cố này cho thấy rủi ro không nằm ở việc bạn cài thêm gì, mà ở việc bạn cập nhật nhanh đến đâu. Một website marketing tưởng như "không có gì để mất" vẫn là một máy chủ có quyền chạy mã, thường nằm chung hạ tầng, chung tài khoản email, chung khoá API với hệ thống khác. Nếu tổ chức bạn đang xây các hệ thống nội bộ nhạy cảm hơn — chẳng hạn hệ AI nội bộ xử lý tài liệu công ty — thì kỷ luật vá lỗi trên những tài sản "phụ" như website chính là tuyến phòng thủ đầu tiên.

wp2shell là lỗ hổng trong mã lõi WordPress, nên một site cài trắng không plugin vẫn dính: nếu bạn đang chạy WordPress 6.9.0–6.9.4 hoặc 7.0.0–7.0.1, hãy tự mở trang quản trị kiểm tra và cập nhật lên 6.9.5 hoặc 7.0.2 ngay hôm nay, đừng chờ cập nhật cưỡng bức làm hộ.

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

Lưu ý: Bài viết tổng hợp từ nguồn công khai tại thời điểm 21/07/2026 và phản ánh tình hình tại thời điểm đó — đây là sự việc đang diễn biến, thông tin có thể thay đổi. Các con số ước tính quy mô ảnh hưởng là ước tính của bên thứ ba, đã ghi rõ nguồn và phạm vi. Điểm CVSS và trạng thái danh mục KEV là ảnh chụp lúc tra cứu. Thông tin mang tính tham khảo, không thay thế cho đánh giá của đội ngũ bảo mật phụ trách hệ thống của bạn và không phải tư vấn pháp lý.