Lỗ hổng WordPress WP2Shell đang bị khai thác diện rộng — Net Solutions đã phát hiện và xử lý trên hệ thống khách hàng

Nếu website của bạn đang chạy WordPress, đây là điều nên đọc ngay, không đợi đến cuối tuần.

Giữa tháng 7/2026, giới bảo mật công bố một chuỗi khai thác có tên WP2Shell, nhắm thẳng vào lõi (core) của WordPress — không cần plugin lỗi, không cần đăng nhập, không cần cấu hình đặc biệt. Nhiều hãng bảo mật ước tính hơn 500 triệu website WordPress trên toàn cầu nằm trong vùng ảnh hưởng. Trong quá trình vận hành hệ thống khách hàng, đội kỹ thuật Net Solutions đã phát hiện dấu hiệu tấn công theo đúng kỹ thuật này nhắm vào một số website đang được chúng tôi quản lý, và đã xử lý.

Bài viết này tổng hợp: lỗ hổng là gì, ai bị ảnh hưởng, Net Solutions đã làm gì, và bạn cần kiểm tra gì ngay bây giờ — dù website của bạn có phải do chúng tôi vận hành hay không.

WP2Shell là gì

WP2Shell là tên gọi chung cho chuỗi hai lỗ hổng trong WordPress core, được công bố công khai từ 17/07/2026 và đang bị khai thác tích cực trên diện rộng:

Kết hợp lại, hai lỗi này cho phép người lạ — không cần tài khoản, không cần mật khẩu — gửi một yêu cầu tới website và tạo ngay một tài khoản quản trị viên (administrator) mới. Từ đó họ có toàn quyền trên site: chèn nội dung lạ, cài mã độc, đổi trang, hoặc bán lại quyền truy cập cho bên khác.

Ai bị ảnh hưởng: mọi website WordPress chạy phiên bản lõi trong khoảng 6.9.0 – 6.9.4 hoặc 7.0.0 – 7.0.1 — không phân biệt đang dùng theme hay plugin gì, kể cả một site WordPress cài mặc định không thêm gì. Muốn biết site của bạn đang ở bản nào, vào Trang tổng quan → Cập nhật trong khu vực quản trị, hoặc hỏi đơn vị đang vận hành site.

Chuỗi WP2Shell được vá trong 6.9.5, 7.0.2 và 6.8.6 — nhưng đừng dừng ở đó. Tính đến 10/09/2026, chính WordPress.org đang gắn nhãn insecure cho cả ba bản vừa nêu, cùng 6.8.7, 6.9.6 và 7.0.3: sau WP2Shell còn nhiều đợt vá bảo mật nữa. Ba bản không còn bị gắn nhãn đó là 6.8.8, 6.9.7 và 7.0.4.

Con số ở trên sẽ cũ đi, nên đây mới là cách kiểm đúng ở bất kỳ thời điểm nào — trang này do WordPress.org phát hành, ai cũng mở được:

https://api.wordpress.org/core/stable-check/1.0/

Tìm phiên bản site bạn đang chạy trong danh sách đó. insecure là phải nâng ngay; outdated là an toàn về bảo mật nhưng chưa phải bản mới nhất. Riêng lỗi SQL injection (CVE-2026-60137) còn ảnh hưởng cả nhánh 6.8.0 – 6.8.5, nhưng ở nhánh đó nó không ghép được thành chuỗi chiếm quyền, vì lỗi định tuyến chỉ xuất hiện từ 6.9 trở đi.

Net Solutions đã làm gì

Khi dấu hiệu khai thác WP2Shell xuất hiện trên hệ thống đang quản lý, đội kỹ thuật của chúng tôi đã:

1. Phát hiện qua giám sát nhật ký truy cập — các yêu cầu bất thường gửi đúng vào endpoint bị khai thác, đúng dấu vết kỹ thuật của công cụ tấn công.
2. Chặn ngay đường tấn công trên toàn bộ hệ thống khách hàng đang quản lý, không chờ đến khi vá gốc xong.
3. Rà soát và dọn sạch các tài khoản quản trị viên lạ phát sinh trong lúc bị tấn công, trên những site có dấu hiệu bị chạm tới.
4. Đóng đường khai thác ở tầng nền tảng. Bản vá nền tảng WebCloud 4.2.7 gỡ hẳn endpoint bị khai thác khỏi mã nguồn, đồng thời REST API được đóng với khách vãng lai trên toàn bộ hệ thống khách hàng — chặn cả hai đường gọi /wp-json/batch/v1 và /?rest_route=/batch/v1.
5. Nâng WordPress core lên bản vá chính thức. Bản nền tảng WebCloud 4.2.8 đưa lõi WordPress lên 6.9.7 — không phải 6.9.5, vì đến thời điểm dựng bản này thì 6.9.5 đã bị chính WordPress.org gắn nhãn insecure. Đây là bản thay lõi đầy đủ chứ không phải đổi con số phiên bản: đối chiếu với danh sách tệp chính chủ của WordPress cho bước 6.9.4 → 6.9.7 thì đủ cả 20 tệp, trong đó có đúng những tệp chứa hai lỗi nêu ở bảng trên — class-wp-query.php (lỗi SQL) và rest-api.php cùng class-wp-rest-server.php (lỗi định tuyến).
6. Sửa nguyên nhân khiến hệ thống không tự thấy bản vá. Đây là phần khó chịu nhất và chúng tôi nói thẳng: một tuỳ chọn tối ưu tốc độ trên nền tảng của chính chúng tôi đã chặn website gọi ra api.wordpress.org, nên cơ chế kiểm tra bản vá của WordPress im lặng báo “đã ở bản mới nhất” trong khi lõi vẫn là bản cũ. Không có lỗi nào hiện ra. Bản 4.2.8 mở lại đúng các địa chỉ mà WordPress dùng để hỏi và tải bản cập nhật, giữ nguyên phần chặn còn lại.

Việc nâng lõi được triển khai theo đợt, và bạn không cần tin lời chúng tôi. Tính đến rạng sáng 11/09/2026, các website chúng tôi đo lại đã đứng ở 6.9.7; đợt triển khai vẫn đang chạy nốt phần còn lại của hệ thống. Nếu website của bạn do Net Solutions vận hành, mở tenmiencuaban.com/feed/ và tìm dòng có wordpress.org/?v= — con số ở đó là lõi đang chạy thật, không phải con số chúng tôi nói. Suốt thời gian triển khai, thứ giữ cửa vẫn là hai lớp chặn ở mục 4: chúng tôi đã đo lại, cả hai đường gọi tới endpoint bị khai thác đều bị từ chối. Chặn đường khai thác và vá chính lỗ hổng là hai việc khác nhau — chúng tôi làm cả hai, và không nói việc nào đã xong khi nó còn đang chạy.

Không phải mọi website chúng tôi quản lý đều bị chiếm quyền — phần lớn chỉ ghi nhận các yêu cầu tấn công không thành công vì đã được chặn kịp thời. Với những trường hợp có dấu hiệu bị chạm tới thật sự, khách hàng liên quan đã và đang được thông báo trực tiếp.

Bạn cần làm gì ngay

Nếu website của bạn KHÔNG do Net Solutions vận hành, hãy tự kiểm tra hoặc yêu cầu đơn vị đang quản lý site kiểm tra các mục sau:

• Cập nhật WordPress core lên phiên bản mới nhất ngay lập tức. Lưu ý: một vài bản vá phát hành ngay sau đợt công bố ban đầu sau đó cũng bị chính WordPress.org đánh dấu là chưa thật sự an toàn — luôn cập nhật lên bản mới nhất tại đúng thời điểm kiểm tra, đừng dừng lại ở bản đầu tiên nghe nói là “đã vá”.
• Kiểm tra danh sách tài khoản quản trị viên (Người dùng → Tất cả người dùng, lọc vai trò Administrator) — có tài khoản lạ nào bạn không tạo ra không.
• Nếu đơn vị vận hành trả lời “đã chặn /wp-json rồi”, hỏi thêm một câu. Cùng một endpoint của WordPress còn gọi được bằng đường thứ hai: /?rest_route=/batch/v1 — dạng tham số trên trang chủ, nên mọi luật chặn viết theo đường dẫn đều không chạm tới nó. Chặn một dạng là mới xong một nửa, và nửa còn lại không báo lỗi gì cả. Đây cũng chính là chỗ chúng tôi phải sửa lại luật chặn của mình trong đợt này.
• Kiểm tra xem tính năng tự động cập nhật có THẬT SỰ hoạt động không — đây là mục dễ bị bỏ qua nhất. Một số plugin bảo mật hoặc tối ưu tốc độ chặn website gọi ra api.wordpress.org ở tầng ứng dụng. Khi đó WordPress không hỏi được bản vá mới, và màn hình Cập nhật báo “đã ở bản mới nhất” trong khi site đang chạy một bản dính lỗi. Không có cảnh báo nào cả — cơ chế phát hiện bản vá đã câm từ trước đó rất lâu.
• Đừng tin màn hình Cập nhật, hãy đối chiếu số phiên bản. Xem site đang chạy bản nào (Trang tổng quan → Cập nhật), rồi tra chính con số đó trong danh sách api.wordpress.org/core/stable-check/1.0/. Hai nguồn khớp nhau thì mới yên tâm. Đây đúng là cách chúng tôi phát hiện ra một phần hệ thống của chính mình đang đứng im ở bản cũ mà mọi màn hình đều báo bình thường. Nếu không vào được khu vực quản trị, phần lớn website WordPress vẫn để lộ số phiên bản ở địa chỉ tenmiencuaban.com/feed/ — mở lên và tìm dòng có wordpress.org/?v=.
• Sao lưu định kỳ, để có đường lùi nếu phát hiện dấu hiệu bất thường.

Bài này đã được cập nhật

Cập nhật 10/09/2026. Bản đăng đầu tiên nói chuỗi WP2Shell “đã được vá ở 6.9.5 / 7.0.2” và dừng ở đó — đúng theo các bản tin bảo mật hồi tháng 7/2026, nhưng không còn đúng vào tháng 9. Khi rà lại bằng bảng trạng thái sống của WordPress.org, chính ba bản đó đang mang nhãn insecure. Bài đã được sửa ở ba chỗ:

• Con số bản an toàn: mốc cần nâng tới là 6.8.8 / 6.9.7 / 7.0.4, không phải 6.9.5 / 7.0.2 / 6.8.6. Bài nay dẫn thẳng bảng trạng thái của WordPress.org để bạn tự tra ở bất kỳ thời điểm nào, thay vì chỉ in ra một con số sẽ cũ đi.
• Phần “Net Solutions đã làm gì”: nói rõ bản nền tảng nào làm việc gì, và nói rõ việc nâng lõi đang chạy theo đợt chứ chưa phủ hết — thay cho cách viết cũ dễ đọc thành đã xong.
• Bổ sung nguyên nhân gốc khiến hệ thống không tự thấy bản vá, gồm cả phần xảy ra trên nền tảng của chính chúng tôi và cách đã sửa.

Bài viết về bảo mật có hai loại thông tin trông giống hệt nhau: loại đúng mãi mãi (lỗ hổng nào, ai công bố ngày nào) và loại hết hạn theo tuần (bản nào đang an toàn). Chúng tôi giữ lại ghi chú này thay vì sửa im lặng, vì nếu bạn đã đọc bản đầu và làm theo, chỗ cần làm lại nằm đúng ở đây.

Nếu bạn không chắc website của mình có bị ảnh hưởng hay không, hoặc muốn được kiểm tra miễn phí, liên hệ Net Solutions để được hỗ trợ.