WordPress vá lỗ hổng nằm im gần 10 năm, và câu trấn an trong cảnh báo mới là thứ đáng lo nhất

Mấy hôm nay trong các nhóm WordPress Việt Nam đang lan truyền một cảnh báo bảo mật: lỗ hổng nghiêm trọng, CVSS 9.2, ảnh hưởng mọi phiên bản từ 4.7.0 đến 7.1.1, cập nhật ngay.

Tôi sẽ nói một điều mà tôi rất hiếm khi được nói về loại tin này: cảnh báo đó đúng. Gần như toàn bộ. Trong một lĩnh vực mà 90% tin bảo mật lan truyền trên mạng xã hội là phóng đại hoặc chép sai số, đây là ngoại lệ đáng khen.

Nhưng có một câu trong đó sai — và trớ trêu thay, đó lại là câu khiến người đọc thở phào rồi để việc cập nhật sang tuần sau:

"Hiện chưa ghi nhận vụ tấn công thực tế nào."

Câu đó đúng về mặt chữ nghĩa. Và nó là lý do tệ nhất để trì hoãn. Tôi sẽ giải thích bằng một mốc giờ cụ thể.

Chuyện gì đã xảy ra, theo đúng mốc thời gian

Hãy đặt các sự kiện vào đúng ngày của chúng — vì ở tin bảo mật, thứ tự thời gian chính là mức độ rủi ro.

• Tháng 7/2026 — nhà nghiên cứu Robert Ressl báo cáo lỗ hổng một cách kín đáo qua HackerOne (The Hacker News).
• Ngày 17/9/2026 — WordPress 7.1.1 ra mắt với "17 bug fixes on Core, 19 bug fixes for the Block Editor, and 11 security fixes". Lỗ hổng này không nằm trong số đó (WordPress.org).
• Ngày 22/9/2026 — WordPress 7.1.2 phát hành, chỉ một nội dung duy nhất: vá CVE-2026-87902 (WordPress.org).
• 22/9/2026, 17:44 UTC — chưa đầy 5 tiếng sau khi bản vá được công bố, hệ thống giám sát của Patchstack ghi nhận những lượt dò tìm đầu tiên (Patchstack).
• Cũng trong ngày 22/9 — Hadrian công bố một bản tái hiện (PoC) chạy được, chứng minh hành vi truy xuất file ngoài thư mục theme (Hadrian).

Đọc lại hai dòng cuối. Bản vá và đợt dò quét đầu tiên cách nhau chưa tới một buổi chiều.

Lỗ hổng này thật ra là gì

Nói bằng ngôn ngữ của người vận hành, không phải của kỹ sư bảo mật.

WordPress quyết định dùng file giao diện nào để hiển thị một trang thông qua hàm get_page_template() trong wp-includes/template.php. Patchstack mô tả điểm sai rất gọn: WordPress có kiểm tra đường dẫn cho một nhánh, nhưng quên nhánh còn lại — "The page template slug on the first line is passed through validate_file(), WordPress's own traversal check, before it's accepted. The candidate built from pagename never was." (Patchstack)

Dịch sang tiếng người: có hai cửa dẫn vào cùng một căn phòng. WordPress lắp khoá cho một cửa, và để cửa kia không khoá gần mười năm — lỗ hổng ảnh hưởng từ nhánh 4.7.0 đến 7.1.1, được phân loại CWE-98.

Kẻ tấn công không cần tài khoản, không cần đăng nhập, không cần upload gì cả. Chỉ cần một URL được dựng khéo, kèm đồng thời hai tham số pagename và page_id — thiếu một trong hai thì không ăn.

"Chưa có tấn công thực tế" nghĩa là gì — và không nghĩa là gì

Đây là phần tôi muốn bạn đọc kỹ nhất.

Patchstack nói thẳng: những gì họ thấy cho đến giờ là trinh sát, chưa phải khai thác. Mọi request họ ghi nhận đều trỏ tới các file lõi vô hại của WordPress — wp-links-opml.php, wp-includes/functions.php, wp-cron.php — dùng như một phép thử: nếu nội dung của những file đó bị trả về từ một URL trang bình thường, nghĩa là site đó dính.

Lưu lượng dò tìm đến từ một cụm nhỏ: chủ yếu hai địa chỉ IPv4 sát nhau (169.58.48.193, 169.58.48.195), phần lớn mang user agent Go-http-client/1.1. Kỹ thuật vượt bộ lọc: mã hoá URL hai lớp (%252e%252e thay cho ..), độ sâu traversal từ ba đến bảy cấp, cả GET lẫn POST.

Bạn thấy điều gì ở đó? Đó không phải một vụ tấn công. Đó là một cuộc khảo sát thị trường. Ai đó đang lập danh sách những website thoả điều kiện, để dùng sau.

Và đây là điểm mấu chốt về mặt chiến lược: giai đoạn "chưa có tấn công" không phải là lúc để yên tâm. Nó là khoảng thời gian duy nhất bạn còn kịp làm gì đó. Khi tin tức chuyển thành "đã ghi nhận tấn công thực tế", bạn không còn đọc tin nữa — bạn đang đọc log của chính mình.

Cảnh báo lan truyền viết câu đó với thiện ý là "đừng chủ quan". Nhưng phần lớn người đọc chỉ nhớ nửa đầu.

Đừng hoảng sai chỗ: bị đọc file và bị chiếm server là hai mức khác nhau

Nói cho công bằng và chính xác — vì đây là chỗ cảnh báo lan truyền hơi gộp.

Câu "tất cả phiên bản từ 4.7.0 đến 7.1.1 đều dính" là đúng với phần đọc file trái phép (LFI). Nhưng để đi tiếp tới chiếm quyền thực thi mã (RCE), phải hội đủ thêm mấy điều kiện xếp chồng lên nhau:

1. Theme đang chạy phải có một thư mục cấp cao bắt đầu bằng page- (ví dụ page-templates).
2. PHP phải bật register_argc_argv — Patchstack lưu ý cấu hình này "is on by default in the official PHP Docker images and in cPanel environments on PHP below 8.5".
3. Server phải có pearcmd.php của PEAR truy cập được.

Những theme được nêu tên: các theme mặc định đời cũ Twenty Twelve, Twenty Fourteen, cùng một số theme bên thứ ba phổ biến như Neve, Hestia, Sydney (securityonline.info).

Chính Hadrian cũng nhấn mạnh giới hạn của bản PoC họ công bố: "Our reproduction confirms the traversal and inclusion behavior, not an RCE chain."

Vậy nên cách đọc đúng là: hầu hết website đối mặt với rủi ro rò rỉ file. Một nhóm nhỏ hơn đối mặt với rủi ro mất trắng server. Vấn đề là — bạn có biết mình thuộc nhóm nào không? Nếu câu trả lời là không, thì trên thực tế bạn phải hành xử như nhóm thứ hai.

Và không, "em bật auto-update rồi" chưa phải câu trả lời

Đây là niềm tin phổ biến nhất mà tôi muốn thách thức.

Auto-update của WordPress thật sự có hiệu lực, và WordPress.org nói rõ: site bật cập nhật nền tự động sẽ được cập nhật. Nhưng ba tình huống rất thường gặp làm nó không xảy ra:

• Site đang chạy nhánh cũ (6.6, 6.7, 6.8…). WordPress đã backport bản vá về gần như mọi nhánh còn hỗ trợ — 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9 và lùi tới tận nhánh 4.7. Nhưng site của bạn có nhận được không là chuyện khác.
• Auto-update bị tắt — rất phổ biến ở site do agency bàn giao, vì sợ cập nhật làm vỡ giao diện.
• Site bị khoá file (DISALLOW_FILE_MODS) hoặc quản lý qua Git/deploy pipeline — cập nhật tự động không chạy được về mặt kỹ thuật.

Thêm một điểm nữa: bản vá này ra chỉ 5 ngày sau 7.1.1. Nếu bạn vừa cập nhật tuần trước và nghĩ "mới update rồi, khỏi lo" — đó chính xác là cái bẫy.

Và về câu "không có cách nào tạm khác" trong cảnh báo: có, nhưng chỉ là băng gạc. Patchstack nêu phương án chặn tạm nếu chưa vá được ngay — chặn các chuỗi traversal trong tham số pagename ở tầng WAF. Nó câu giờ cho bạn, không thay thế việc cập nhật.

Việc cần làm, theo đúng thứ tự

1. Cập nhật ngay hôm nay. Dashboard → Updates. Nếu đang ở nhánh cũ, lên bản vá của đúng nhánh đó (7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9). Đừng chờ cuối tuần.
2. Xác nhận bằng số phiên bản, không bằng cảm giác. Mở /wp-admin → "At a Glance", đọc đúng con số. "Chắc là đã tự cập nhật rồi" không phải là xác nhận.
3. Kiểm tra theme đang chạy có thư mục nào bắt đầu bằng page- không. Đây là điều kiện cấu trúc quyết định bạn ở nhóm rủi ro nào. Một câu hỏi duy nhất cho đội kỹ thuật.
4. Soát log truy cập. Dấu hiệu rõ nhất theo Patchstack: tham số pagename chứa %252e%252e, hoặc giá trị bắt đầu bằng templates%252f, hoặc pagename và page_id xuất hiện cùng nhau ở trang gốc. Nếu thấy, bạn đã bị đưa vào danh sách.
5. Rà lại các site "bỏ quên". Landing page cũ, bản staging, site chi nhánh, site của chương trình khuyến mãi năm ngoái. Đây luôn là nơi bị chọc thủng đầu tiên, vì không ai nhớ nó còn tồn tại.

---

Điều tôi muốn bạn mang về không phải một CVE. Sang năm sẽ có cái khác.

Điều đáng nhớ là nhịp độ: lỗ hổng nằm im gần mười năm, được vá trong một ngày, và bị dò tìm trong vòng năm tiếng. Khoảng cách giữa "an toàn" và "có tên trong danh sách mục tiêu" không còn tính bằng tuần nữa. Nó tính bằng buổi.

Nếu quy trình xử lý bản vá của bạn hiện là "khi nào rảnh thì làm", thì bản thân quy trình đó mới là lỗ hổng lớn nhất — chứ không phải get_page_template().

Không chắc website của mình đang chạy phiên bản nào, hay ai chịu trách nhiệm cập nhật? Nhắn cho chúng tôi một câu — kiểm tra mất mười lăm phút, và rẻ hơn rất nhiều so với việc khôi phục một site đã bị chiếm.

Nguồn

• WordPress 7.1.2 Release — WordPress.org News (22/9/2026)
• WordPress 7.1.1 Maintenance and Security Release — WordPress.org News (17/9/2026)
• WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE — Patchstack
• Attackers Started Probing WordPress Sites Hours After the Patch — Patchstack
• WordPress Issues Patch for Critical Flaw That Can Enable Code Execution on Some Servers — The Hacker News
• CVE-2026-87902: A Working PoC for WordPress's Critical Path Traversal — Hadrian
• CVE-2026-87902: Critical WordPress RCE Flaw Fixed in Version 7.1.2 — securityonline.info