wp2shell: vá gấp WordPress và lập inventory phần mềm

Câu trả lời nhanh

wp2shell là tên gọi của chuỗi hai lỗ hổng trong WordPress CORE (không phải plugin) cho phép một request HTTP ẩn danh chạy được mã trên máy chủ. Việc cần làm ngay là xác nhận phiên bản WordPress của MỌI site bạn đang sở hữu rồi đưa về 6.9.5 hoặc 7.0.2 trở lên. Việc cần làm sau đó quan trọng hơn: lập inventory phần mềm — vì bạn không thể vá thứ bạn không biết mình đang chạy.

Vì lỗ hổng nằm trong lõi WordPress, một bản cài trắng không có plugin nào cũng nằm trong tầm ảnh hưởng. Searchlight Cyber, đơn vị tìm ra lỗi, mô tả cuộc tấn công là không có điều kiện tiên quyết và thực hiện được bởi người dùng ẩn danh trên bản cài mặc định (dẫn theo SecurityWeek, 20/07/2026).

Điều đáng nói với người quản trị tài sản phần mềm không phải là kỹ thuật khai thác, mà là tốc độ. Từ lúc advisory ra tới lúc khai thác thực tế được xác nhận chỉ khoảng ba ngày. Trong khoảng thời gian đó, câu hỏi duy nhất mà một doanh nghiệp cần trả lời được là: chúng ta đang chạy bao nhiêu WordPress, phiên bản nào, ai chịu trách nhiệm vá từng cái. Doanh nghiệp nào không có sẵn danh sách đó thì mất phần lớn thời gian quý giá chỉ để đi hỏi nhau.

Disclaimer: Bài viết mang tính thông tin, KHÔNG phải tư vấn pháp lý cũng không phải hướng dẫn ứng cứu sự cố cho hệ thống cụ thể của bạn. Mọi mốc thời gian, số phiên bản và số liệu đều trích từ nguồn công khai đã kiểm chứng ngày 20/07/2026 (xem mục Nguồn cuối bài) — tình hình có thể thay đổi từng giờ. Hãy đối chiếu advisory gốc và tham vấn chuyên gia trước khi hành động.

• Hai CVE, không phải một: CVE-2026-63030 (nhầm lẫn định tuyến ở REST API batch endpoint) chain với CVE-2026-60137 (SQL injection trong core) cho phép chạy mã từ một request ẩn danh — The Hacker News, cập nhật 18/07/2026.
• Phiên bản dính: 6.9.0 đến 6.9.4 và 7.0.0 đến 7.0.1. Đã vá: 6.9.5, 7.0.2, và 7.1 Beta 2 — Rapid7, 17/07/2026 (cập nhật 20/07).
• Điểm số dễ gây hiểu lầm: GitHub Security Advisory xếp mức Critical, trong khi bản ghi CVE của CVE-2026-63030 chấm CVSS 7.5 — Rapid7.
• Điều kiện kích hoạt: đường code chỉ tới được khi site KHÔNG dùng persistent object cache — Cloudflare, dẫn theo Rapid7. Bản cài mặc định không có cache dạng này.
• Khai thác thực tế: ngày 20/07/2026, Patchstack, Hexastrike và WatchTowr đều xác nhận đang thấy khai thác ngoài đời — SecurityWeek. Trước đó, ngày 17/07 Rapid7 ghi nhận chưa có khai thác thực tế nào được xác nhận công khai.

1. wp2shell: chuyện gì đã xảy ra trong 72 giờ

Ngày 17/07/2026, một GitHub Security Advisory được công bố cho CVE-2026-63030 — lỗ hổng thực thi mã từ xa không cần xác thực trong WordPress Core; WordPress phát hành bản vá cùng ngày và bật cập nhật cưỡng bức qua hệ thống auto-update. Ba ngày sau, các hãng bảo mật xác nhận lỗ hổng đang bị khai thác thật. Bảng 1 dựng lại mốc thời gian theo đúng thứ tự nguồn công bố.

Về cơ chế, The Hacker News (bản cập nhật 18/07) mô tả wp2shell là hai lỗi nhỏ ghép lại. Lỗi thứ nhất nằm ở endpoint /wp-json/batch/v1 — nơi WordPress gom nhiều sub-request vào một lần gọi và theo dõi chúng bằng hai mảng song song; khi một sub-request lỗi, hai mảng lệch nhau một nhịp khiến một request bị chạy dưới handler của request khác, đi vòng qua danh sách cho phép của endpoint. Lỗi thứ hai là SQL injection ở tham số author__not_in của WP_Query: truyền vào một chuỗi thay vì một mảng thì phép kiểm tra vốn mong đợi mảng bị bỏ qua, giá trị thô rơi thẳng vào câu truy vấn.

Cũng theo The Hacker News, phần chèn SQL đi ngược tới tận nhánh 6.8, còn phần nhầm lẫn định tuyến — mảnh biến một lỗi chèn SQL có giới hạn thành RCE không cần đăng nhập — chỉ tồn tại từ 6.9 trở đi. Endpoint batch bản thân nó đã có mặt từ WordPress 5.6 năm 2020; thứ mới là cách nó bị làm cho lệch nhịp. Lỗi batch được Adam Kues (Assetnote, thuộc Searchlight Cyber) báo qua chương trình HackerOne của WordPress; phần SQL injection do nhóm khác báo riêng.

Về quy mô, TechCrunch (20/07) dẫn thống kê chính thức của WordPress cho biết có hơn 400 triệu website đang chạy các phiên bản dính, đồng thời lưu ý con số này nhiều khả năng chưa phản ánh các site vừa được vá. Cùng bài, chuyên gia Daniel Card cho biết đã soi một mẫu khoảng 3.500 website WordPress và ước tính dưới 15% còn dính; chiếu tỉ lệ đó lên tổng thể thì vẫn còn khoảng 90 triệu site. Đây là ước tính của một chuyên gia trên một mẫu, không phải số liệu đo đếm toàn mạng — hãy đọc nó như một bậc độ lớn.

2. Bạn có đang chạy phiên bản dính không?

Câu trả lời phụ thuộc đúng một con số: phiên bản WordPress core của từng site. Theo Rapid7, chuỗi RCE ảnh hưởng 6.9.0 đến 6.9.4 và 7.0.0 đến 7.0.1, được vá ở 6.9.5 và 7.0.2, và bản vá cũng có trong 7.1 Beta 2; các nhánh trước 6.9 không dính CVE-2026-63030. Bảng 2 gộp cả thông tin nhánh 6.8 mà The Hacker News bổ sung, vì phần SQL injection có tầm với rộng hơn phần RCE.

Có một cái bẫy đúng kiểu quản trị tài sản. WordPress đã bật cập nhật cưỡng bức, nhưng The Hacker News lưu ý rằng WordPress chưa nói rõ đợt đẩy cưỡng bức đó có tới được các site đã tắt auto-update hay không — nghĩa là bạn phải kiểm tra thực tế mình đang chạy gì, thay vì mặc định rằng bản vá đã tự đáp xuống. Với các site do bên thứ ba dựng rồi bàn giao, xác suất auto-update bị tắt là khác không.

Một điều kiện nữa cần hiểu cho đúng: theo Cloudflare (dẫn theo Rapid7), đường code dẫn tới thực thi mã chỉ tới được khi site không dùng persistent object cache. Một bản cài mặc định không có cache dạng đó, nên bản cài mặc định vẫn nằm trong tầm ảnh hưởng. The Hacker News nhấn mạnh thêm rằng nếu site của bạn có Redis hay Memcached làm persistent object cache thì đó là tác dụng phụ may mắn chứ không phải bản vá, và nó không che được phần SQL injection.

3. Không thể vá thứ bạn không biết mình đang chạy

Với hầu hết doanh nghiệp Việt, nút thắt trong ba ngày vừa rồi không phải kỹ thuật vá — chạy một lệnh cập nhật là xong — mà là không biết phải chạy nó ở đâu. Một công ty tầm trung thường có nhiều WordPress hơn họ nghĩ: site chính, blog tuyển dụng, vài landing page chiến dịch cũ, site chi nhánh, bản staging quên xoá, và một site do agency dựng ba năm trước rồi ngừng hợp đồng. Mỗi cái là một cửa mở ra Internet, và cái không ai nhớ mới là cái nguy hiểm nhất.

Đây chính là bài toán trung tâm của quản trị tài sản phần mềm (SAM). Inventory không phải là một file Excel liệt kê tên phần mềm; nó là bản ghi trả lời được ba câu trong vòng một giờ khi có tin nóng: chúng ta đang chạy phiên bản nào, ở đâu, và ai có quyền cùng trách nhiệm vá nó. Bảng 3 là bộ trường tối thiểu Dzo.software đề xuất cho mỗi web asset — đây là khuyến nghị nội bộ của chúng tôi, không phải chuẩn của một tổ chức tiêu chuẩn nào.

Một chi tiết dễ bỏ qua nhưng quyết định tốc độ phản ứng: cột chủ sở hữu phải là một con người có tên, không phải một phòng ban. Khi trường đó ghi "phòng Marketing", việc vá sẽ trôi qua ba lượt chuyển tiếp email trước khi có ai bấm nút. Khi nó ghi tên một người kèm người dự phòng, đồng hồ SLA mới thực sự chạy.

4. SLA vá lỗi theo mức CVSS — và vì sao đừng thờ điểm số

Inventory chỉ có giá trị khi gắn với một cam kết thời gian: lỗ hổng mức nào thì phải vá trong bao lâu. Bảng 4 là khung SLA Dzo.software đề xuất để một doanh nghiệp vừa và nhỏ có thể áp ngay — xin nhấn mạnh đây là đề xuất nội bộ của chúng tôi để bạn tham chiếu và điều chỉnh, không phải chuẩn ban hành bởi bất kỳ tổ chức tiêu chuẩn nào.

Ca wp2shell là minh hoạ tốt cho lý do không nên gắn cứng SLA vào riêng con số CVSS. Rapid7 chỉ ra một nghịch lý: advisory chính thức của GitHub xếp lỗ hổng ở mức Critical, trong khi bản ghi CVE lại chấm 7.5. The Hacker News phân tích thêm rằng cách chấm điểm thưởng cho tầm với trực tiếp vào cơ sở dữ liệu của lỗi chèn SQL và xem phần nhầm lẫn định tuyến, khi đứng một mình, chỉ như một lỗi phân tích dữ liệu — và khuyên nên theo dõi cả hai CVE thay vì nhìn nhãn của một cái.

Kết luận thực dụng: hãy để điểm CVSS làm sàn, còn ba yếu tố sau đẩy mức ưu tiên lên trần — lỗ hổng có khai thác được mà không cần tài khoản không, đã có PoC công khai chưa, và tài sản có phơi ra Internet không. Với wp2shell, cả ba đều đúng chỉ trong vòng 24 giờ sau khi advisory ra.

5. Web bị chiếm quyền: góc pháp lý và bản quyền phần mềm

Một website bị chiếm quyền không chỉ là sự cố kỹ thuật, nó chạm vào hai nhóm nghĩa vụ khác nhau của doanh nghiệp: nghĩa vụ với dữ liệu người dùng, và nghĩa vụ với chính phần mềm mình đang dùng. Nhóm thứ hai thường bị bỏ quên nhưng lại nằm gọn trong phạm vi quản trị tài sản phần mềm.

Về bản quyền, pháp luật Việt Nam bảo hộ chương trình máy tính như tác phẩm văn học, dù được thể hiện dưới dạng mã nguồn hay mã máy (khoản 1 Điều 22 Luật Sở hữu trí tuệ số 50/2005/QH11, đã được sửa đổi, bổ sung năm 2009, 2019 và 2022 — bản đang có hiệu lực là bản sửa đổi theo Luật số 07/2022/QH15, hiệu lực từ 01/01/2023; câu định nghĩa trên được giữ nguyên trong bản sửa đổi này). Còn cái mà thị trường quen gọi là "license" thì bản chất là chuyển quyền sử dụng: chủ sở hữu quyền cho phép tổ chức, cá nhân khác sử dụng có thời hạn một, một số hoặc toàn bộ các quyền được luật quy định (khoản 1 Điều 47 cùng luật, cũng đã được sửa đổi bởi Luật số 07/2022/QH15). Nói cách khác, quyền dùng phần mềm luôn có biên — hết hạn, sai phạm vi, hoặc dùng bản không rõ nguồn gốc đều là ra ngoài biên đó.

Về chế tài, Nghị định số 341/2025/NĐ-CP quy định xử phạt vi phạm hành chính về quyền tác giả, quyền liên quan được Chính phủ ban hành ngày 26/12/2025 và có hiệu lực từ 15/02/2026, thay cho khung cũ tại Nghị định 131/2013/NĐ-CP; mức tiền phạt tối đa trong lĩnh vực quyền tác giả, quyền liên quan là 250 triệu đồng đối với cá nhân và 500 triệu đồng đối với tổ chức (theo bài giới thiệu Nghị định trên cổng thông tin của Cục Bản quyền tác giả). Chúng tôi không suy diễn điều khoản cụ thể áp cho từng hành vi — đó là việc của luật sư trên hồ sơ thật.

Về dữ liệu cá nhân, bài viết này cố ý KHÔNG nêu số điều khoản cụ thể. Lý do rất đơn giản và cũng là nguyên tắc biên tập của chúng tôi: khung pháp luật về bảo vệ dữ liệu cá nhân đang trong giai đoạn thay đổi, và chúng tôi chỉ trích dẫn những gì đối chiếu được với văn bản gốc còn hiệu lực tại thời điểm viết. Nếu sự cố của bạn có dấu hiệu lộ dữ liệu cá nhân, hãy đối chiếu văn bản gốc còn hiệu lực và tham vấn luật sư ngay từ giờ đầu tiên, thay vì tin vào một con số điều khoản đọc được trên blog.

Điểm nối giữa hai nhóm nghĩa vụ này chính là inventory. Không có danh sách tài sản, bạn không biết site nào có form thu dữ liệu, không biết phần mềm nào còn hạn giấy phép, và cũng không chứng minh được mình đã làm gì trước khi sự cố xảy ra. Hồ sơ inventory được cập nhật đều đặn là thứ dễ trưng ra nhất khi cần thể hiện sự cẩn trọng — với hãng phần mềm khi bị audit, và với đối tác khi bị chất vấn sau sự cố.

Lưu ý: Bài viết mang tính tham khảo, không thay thế tư vấn pháp lý. Vui lòng đối chiếu văn bản luật gốc (ipvietnam.gov.vn, cov.gov.vn) cùng các luật sửa đổi còn hiệu lực và tham vấn chuyên gia trước khi ra quyết định.

6. Việc cần làm trong 48 giờ tới

Nếu bạn chỉ có thời gian cho một danh sách, đây là thứ tự chúng tôi đề xuất — ba việc đầu là chữa cháy, năm việc sau là để lần tới không phải chữa cháy nữa.

• 1. Liệt kê mọi WordPress bạn sở hữu. Kể cả site staging, landing page chiến dịch cũ, blog chi nhánh, và site do agency dựng rồi bàn giao. Cái không ai nhớ là cái rủi ro nhất.
• 2. Kiểm tra phiên bản THẬT của từng site. Đừng giả định cập nhật cưỡng bức đã đáp xuống: The Hacker News lưu ý WordPress chưa nói rõ đợt đẩy đó có tới các site đã tắt auto-update hay không.
• 3. Đưa mọi site về 6.9.5 / 7.0.2 trở lên (hoặc 6.8.6 nếu đang ở nhánh 6.8, để vá phần SQL injection).
• 4. Nếu chưa vá được ngay, chặn tạm ở lớp biên. Theo The Hacker News, các biện pháp Searchlight đưa ra đều xoay quanh việc chặn người gọi ẩn danh tới endpoint batch — và phải chặn cả đường /wp-json/batch/v1 lẫn đường qua tham số truy vấn rest_route, vì chặn một đường thì đường kia vẫn mở. Đây là biện pháp tạm và có thể làm hỏng tích hợp hợp lệ.
• 5. Soát log của cửa sổ 17–20/07. Khai thác thực tế đã được xác nhận ngày 20/07; nếu site của bạn chạy phiên bản dính trong khoảng đó thì mặc định coi là cần điều tra, không mặc định coi là an toàn.
• 6. Dựng inventory theo Bảng 3. Bắt đầu bằng một bảng tính cũng được, miễn có đủ trường phiên bản và chủ sở hữu là tên người.
• 7. Chốt SLA vá theo Bảng 4 và gắn tên người chịu trách nhiệm cho từng mức. SLA không có tên người là SLA không chạy.
• 8. Đặt lịch rà định kỳ. Mỗi quý một lần đối chiếu inventory với thực tế đang chạy; sau mỗi lần bàn giao website từ bên thứ ba thì rà ngay, không đợi tới quý.

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

1. wp2shell là gì? Là tên gọi của chuỗi hai lỗ hổng trong WordPress core: CVE-2026-63030 (nhầm lẫn định tuyến ở REST API batch endpoint) và CVE-2026-60137 (SQL injection). Ghép lại, chúng cho phép một request ẩn danh chạy mã trên máy chủ (The Hacker News, 18/07/2026).

2. Site tôi cài trắng, không plugin nào, có dính không? Có. Lỗ hổng nằm trong lõi WordPress. Searchlight Cyber mô tả cuộc tấn công không có điều kiện tiên quyết và thực hiện được bởi người dùng ẩn danh trên bản cài mặc định không plugin (dẫn theo SecurityWeek, 20/07/2026).

3. Tôi phải nâng lên phiên bản nào? 6.9.5 nếu đang ở nhánh 6.9, 7.0.2 nếu đang ở nhánh 7.0; bản vá cũng có trong 7.1 Beta 2 (Rapid7). Nếu đang ở nhánh 6.8 thì 6.8.6 vá phần SQL injection (The Hacker News).

4. WordPress đã bật cập nhật cưỡng bức rồi, tôi còn phải làm gì? Vẫn phải tự kiểm tra. WordPress bật cập nhật cưỡng bức cho các site có auto-update, nhưng The Hacker News lưu ý chưa rõ đợt đẩy đó có tới được site đã tắt auto-update hay không. Rapid7 cũng khuyến nghị quản trị viên xác minh từng website hướng Internet đã lên bản vá.

5. Có bao nhiêu website đang gặp rủi ro? Không ai đo được chính xác. TechCrunch (20/07) dẫn thống kê chính thức của WordPress: hơn 400 triệu website chạy các phiên bản dính, kèm lưu ý con số này chưa phản ánh các site vừa vá; chuyên gia Daniel Card soi mẫu khoảng 3.500 site và ước tính dưới 15% còn dính, tương đương khoảng 90 triệu trên tổng thể. Hãy đọc các con số này như bậc độ lớn, không phải kết quả đo đếm.

6. Bài học quản trị tài sản phần mềm ở đây là gì? Là tốc độ phản ứng phụ thuộc vào việc bạn có sẵn danh sách hay không. Từ advisory (17/07) tới khai thác thực tế được xác nhận (20/07) chỉ khoảng ba ngày. Doanh nghiệp có inventory trả lời được trong một giờ; doanh nghiệp không có thì dành hết ba ngày đó để đi hỏi nhau xem ai giữ website nào.

Lưu ý: Bài viết mang tính tham khảo, không phải tư vấn pháp lý và không phải hướng dẫn ứng cứu sự cố cho hệ thống cụ thể. Hãy đối chiếu advisory gốc và tham vấn chuyên gia.

Kết luận

wp2shell rồi sẽ được vá xong ở phần lớn website, và trong vài tháng nữa sẽ có một tên gọi khác thế chỗ nó trên mặt báo. Thứ không đổi là bài kiểm tra mà mỗi lần như vậy đặt ra cho doanh nghiệp: bạn mất bao lâu để biết mình có dính hay không. Ba ngày từ advisory tới khai thác thực tế là khoảng thời gian quá ngắn để bắt đầu đi tìm xem công ty mình có bao nhiêu website.

Inventory phần mềm, SLA vá theo mức nghiêm trọng, và một cái tên người gắn với mỗi tài sản — ba thứ đó không tốn tiền bản quyền, chỉ tốn kỷ luật. Chúng cũng chính là nền của mọi việc khác trong quản trị tài sản phần mềm: kiểm soát chi phí, chứng minh tuân thủ, và giảm bề mặt tấn công.

Bạn không thể vá thứ bạn không biết mình đang chạy — nên tài sản đầu tiên cần bảo vệ không phải là máy chủ, mà là danh sách.