Ngày 22/09/2026, WordPress phát hành bản vá khẩn cấp 7.1.2 cho một lỗ hổng nghiêm trọng trong lõi (core): CVE-2026-87902. Chỉ ít giờ sau khi bản vá lên mạng, những yêu cầu tấn công đầu tiên đã gõ vào tường lửa. Trong quá trình vận hành hệ thống khách hàng, đội kỹ thuật Net Solutions ghi nhận đúng kiểu tấn công này nhắm vào một số website đang quản lý — và đã xử lý.
Bài viết này giải thích lỗ hổng theo cách người không chuyên vẫn nắm được, tổng hợp nguồn tham khảo từ nhiều hãng bảo mật, nói rõ Net Solutions đã làm gì cho toàn bộ khách hàng, và bạn cần kiểm tra gì ngay — dù website của bạn có phải do chúng tôi vận hành hay không.
CVE-2026-87902 là gì
Đây là lỗ hổng chèn/nạp file cục bộ (local file inclusion — LFI) nằm ngay trong lõi WordPress, không phải ở một plugin hay giao diện lỗi nào. Nói cách khác: một website WordPress cài mặc định, không thêm gì, vẫn có thể dính.
| Hạng mục | Chi tiết |
|---|---|
| Mã lỗ hổng | CVE-2026-87902 (còn được tham chiếu là GHSA-7hp8-65ch-5whp) |
| Loại lỗi | File inclusion / path traversal — phân loại CWE-98 |
| Vị trí | Hàm get_page_template() trong wp-includes/template.php |
| Mức độ | CVSS 4.0 = 9.2 — Nghiêm trọng |
| Điều kiện | Không cần đăng nhập, không cần tài khoản |
| Phiên bản dính | WordPress 4.7.0 → 7.1.1 (gần một thập kỷ phát hành) |
| Vá trong | 7.1.2 và các bản backport về tận 4.7.37 |
| Công bố | 22/09/2026 — người báo cáo: Robert Ressl |
Điểm khiến lỗ hổng này đáng ngại: nó nằm ở lõi, không cần đăng nhập, và ảnh hưởng gần một thập kỷ phiên bản. Một kẻ tấn công tự động có thể quét hàng loạt website mà không cần biết trước bạn dùng theme hay plugin gì.
Lỗi nằm ở đâu trong mã nguồn
Khi WordPress hiển thị một trang, nó phải chọn file khuôn (template) để dựng giao diện. Với trang thường, nó lấy tham số pagename trên URL rồi ghép thành tên file dạng page-{pagename}.php.
Vấn đề: một nhánh của hàm get_page_template() gọi thêm urldecode() lên pagename, biến chuỗi đã mã hoá thành đường dẫn đi lùi thư mục thật sự (../../). Một nhánh mã bên cạnh có gọi validate_file() để chặn kiểu đi lùi này — nhưng nhánh pagename thì không. Thế là WordPress nạp một file PHP nằm ngoài thư mục giao diện.
Vì sao phải là theme có thư mục bắt đầu bằng page-? Vì tên file được ghép cứng theo khuôn page-{...}.php. PHP không chuẩn hoá được page-.. nếu thành phần đầu (page-templates/) không có thật trên đĩa — nên chỉ những giao diện có sẵn thư mục kiểu đó (rất nhiều theme phổ biến) mới mở được đường đi lùi.
Bản thân việc nạp file chưa chiếm được quyền. Để lên tới chạy mã từ xa (remote code execution — RCE), cần thêm hai điều kiện ở phía máy chủ:
- Có một file
.phpđọc được và làm việc “hữu ích” khi bị nạp — ứng viên kinh điển làpearcmd.phpcủa thư viện PEAR, thứ nhiều image PHP để sẵn. - PHP bật
register_argc_argv— mặc định bật trên nhiều image Docker PHP chính thức và máy chủ cPanel PHP đời cũ. Khi đó kẻ tấn công ghép được lệnh đểpearcmd.phpghi một webshell vào/tmprồi chạy nó.
Website nào nằm trong vùng nguy hiểm
Site của bạn dễ bị khai thác trọn chuỗi khi hội đủ cả hai điều kiện dưới đây. Thiếu một, chuỗi khai thác không chạy hết — nhưng đây không phải lý do để hoãn cập nhật, vì lỗ nạp file vẫn tồn tại và có thể ghép với lỗ khác trong tương lai.
Các hãng bảo mật nêu tên một số giao diện có thư mục page- phổ biến như Twenty Twelve, Twenty Fourteen, Neve, Hestia, Sydney. Nhưng danh sách này không đầy đủ, và phần lớn chủ website không dễ tự kiểm cấu hình máy chủ. Vì vậy khuyến nghị chung của cộng đồng vẫn là: cập nhật ngay, đừng dừng lại để đoán site mình có dính hay không.
Không phải cảnh báo lý thuyết: đã bị khai thác thật
Đây không phải một lỗ hổng “trên giấy”. Theo Patchstack, yêu cầu tấn công đầu tiên chạm tường lửa lúc 11:49 UTC ngày 22/09/2026 — cùng ngày bản vá 7.1.2 ra mắt. Đến 15:34 UTC cùng ngày đã ghi nhận nỗ lực ghi file xuống đĩa qua pearcmd. Sang ngày thứ hai, lưu lượng tấn công tăng hơn mười lần, và công cụ quét công khai (kể cả mẫu Nuclei có tên) bắt đầu lưu hành.
The Hacker News dẫn dữ liệu từ mạng honeypot ghi nhận các đợt khai thác từ 23/09, với dải địa chỉ tấn công phân tán trên vài trăm IP. Kịch bản tấn công đi theo ba giai đoạn khá rõ: dò lỗ hổng qua các file lõi vô hại (như wp-links-opml.php) → tìm pearcmd.php ở các vị trí quen thuộc → ghi file PHP vào /tmp hoặc /var/tmp.
Chính trên hệ thống Net Solutions vận hành, chúng tôi cũng đọc được đúng dấu vết đó trong nhật ký — những yêu cầu POST mang tham số pagename chứa chuỗi đi lùi thư mục đã mã hoá hai lớp, đi kèm các payload config-create đặc trưng của pearcmd. Đây là cơ sở thực tế để chúng tôi hành động sớm thay vì chờ.
Net Solutions đã làm gì cho khách hàng
Khi dấu hiệu khai thác xuất hiện, đội kỹ thuật của chúng tôi xử lý theo bốn bước, và quan trọng nhất: chặn đường tấn công và vá chính lỗ hổng là hai việc khác nhau — chúng tôi làm cả hai.
- Phát hiện qua giám sát nhật ký. Các yêu cầu bất thường gửi đúng vào đường khai thác, đúng dấu vết kỹ thuật của công cụ tấn công.
- Chặn ngay đường tấn công ở tầng máy chủ trên toàn hệ thống khách hàng đang quản lý, siết thêm luật khi phát hiện biến thể mã hoá còn lọt — không chờ đến khi vá gốc xong.
- Rà soát và dọn dấu vết: gỡ các file lạ bị rải vào thư mục tải lên, rà và xử lý những tài khoản quản trị phát sinh trong lúc bị tấn công trên các site có dấu hiệu bị chạm tới.
- Vá tận gốc trên nền tảng. Chúng tôi nâng WordPress core lên 7.1.2 cho toàn bộ website khách hàng đang vận hành, đồng thời tắt
register_argc_argvvà gỡ hẳnpearcmdkhỏi image nền tảng WebCloud. Kể cả khi một lỗ nạp file mới xuất hiện trong tương lai, công cụ để biến nó thành ghi file cũng không còn nằm sẵn trên máy chủ.
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ì đã bị chặn kịp. 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 được thông báo và xử lý 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 làm các việc sau:
- Cập nhật WordPress core lên bản mới nhất ngay lập tức. Bản vá là 7.1.2, và đã được backport cho các nhánh cũ (7.0.6, 6.9.9, 6.8.10… về tận 4.7.37). Vào Trang tổng quan → Cập nhật để nâng, hoặc hỏi đơn vị vận hành site.
- Đừng chỉ tin màn hình Cập nhật — đối chiếu số phiên bản. Mở
api.wordpress.org/core/stable-check/1.0/, tìm đúng bản site bạn đang chạy: insecure là phải nâng ngay, outdated là an toàn về bảo mật nhưng chưa mới nhất. - 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 chưa nâng core được ngay, giảm bề mặt tấn công tạm thời: đặt
register_argc_argv = Offtrongphp.ini, gỡ các file PEAR không dùng, siết quyền ghi thư mục (755 cho thư mục, 644 cho file). Đây chỉ là biện pháp tạm — không thay cho việc nâng core. - Sao lưu định kỳ để luôn có đường lùi nếu phát hiện bất thường.
Nguồn tham khảo
Bài viết này tổng hợp và đối chiếu từ nhiều nguồn công khai. Với thông tin bảo mật, nên đọc chéo nhiều nguồn thay vì tin một chỗ:
- Thông báo phát hành chính thức: WordPress 7.1.2 Release — WordPress.org News
- Phân tích kỹ thuật cơ chế lỗi và bản vá: Patchstack — Unauthenticated LFI to RCE
- Diễn biến khai thác thực tế: Patchstack — Attackers started probing hours after the patch
- Cảnh báo khai thác diện rộng: The Hacker News
- Tổng quan bản vá: Help Net Security · SOCRadar
- Hai điều kiện quyết định mức độ ảnh hưởng: Wordify
- Nguồn tiếng Việt tham khảo ban đầu: DPS Media
Đọc thêm về bảo mật website
- Lỗ hổng WordPress WP2Shell đang bị khai thác diện rộng — Net Solutions đã phát hiện và xử lý
- Bot Attacks là gì? Các loại bot tấn công và cách ngăn chặn hiệu quả
- Hướng dẫn đổi mật khẩu quản trị website chi tiết từ A–Z
Website của bạn đang chạy WordPress và bạn không chắc mình có nằm trong vùng ảnh hưởng? Net Solutions nhận kiểm tra miễn phí. Gọi hoặc Zalo 0906.207.001 — hoặc email sales@netsolutions.vn.
