Ngày 12 tháng 8 năm 2026, WordPress chính thức phát hành phiên bản 7.0.4 — một bản cập nhật bảo mật khẩn cấp vá một lỗ hổng Remote Code Execution (RCE) đặc biệt nguy hiểm: kẻ tấn công có tài khoản Author có thể thực thi mã tùy ý trên máy chủ thông qua việc upload một file ảnh độc hại, trên những site dùng extension Imagick kết hợp với Ghostscript.
Đây là bản vá quan trọng tiếp theo sau bản 7.0.3 hồi đầu tháng 8, và được khuyến nghị cập nhật ngay lập tức. Bài viết này tổng hợp chi tiết về lỗ hổng CVE-2026-65640, mức độ nguy hiểm, ai đang bị ảnh hưởng, và cách kiểm tra + cập nhật an toàn.
Tổng quan WordPress 7.0.4
WordPress 7.0.4 là bản security release do đội ngũ WordPress Core phát hành, được dẫn dắt bởi John Blackbourn với sự đóng góp của Dennis Snell và Jeremy Felt. Bản vá này sửa đúng một lỗ hổng bảo mật được báo cáo có trách nhiệm bởi đội ngũ pwn.ai:
| Mục | Chi tiết |
|---|---|
| Mã lỗ hổng | CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w |
| Loại lỗ hổng | Remote Code Execution (RCE) qua file upload |
| Điều kiện khai thác | Cần tài khoản Author trở lên (có quyền upload_files) |
| Yêu cầu server | Dùng Imagick (ImageMagick) + Ghostscript |
| Mức độ | High — CVSS 8.8 |
| Người báo cáo | pwn.ai |
| Phiên bản ảnh hưởng | Từ 4.7.0 đến 7.0.3 |
CVE-2026-65640: Lỗ hổng RCE nguy hiểm nhất
Lỗ hổng này thuộc lớp CWE-434 (unrestricted upload of a file with a dangerous type). Về bản chất, nó biến quyền “upload một file media” thành khả năng chạy mã trên máy chủ. Đây là cùng họ lỗ hổng với chuỗi ImageTragick nổi tiếng từ gần một thập kỷ trước.
Cơ chế hoạt động
Vấn đề nằm ở sự không khớp giữa cách nhận diện file:
- ImageMagick quyết định loại file dựa trên nội dung thực tế (sniff nội dung), không phải phần mở rộng.
- WordPress (trước bản vá) lại quyết định cách xử lý file dựa trên phần mở rộng của tên file.
Khai thác điển hình: kẻ tấn công upload một file tên vô hại như holiday.png, nhưng bên trong thực chất là mã PostScript. File này vượt qua kiểm tra upload vì WordPress tin vào phần mở rộng .png. Khi được đưa vào Imagick, ImageMagick nhận diện nội dung PostScript thật sự và chuyển cho Ghostscript — một trình thông dịch ngôn ngữ lập trình đầy đủ — để render. Chính tại đây, mã độc được thực thi.
Đáng chú ý, luồng upload media tiêu chuẩn không phải là điểm yếu — WordPress có chạy kiểm tra nội dung ở luồng này. Điểm hở nằm ở các đường upload bỏ qua kiểm tra: phương thức upload qua XML-RPC và quy trình trích xuất ảnh bìa (cover art) cho file MP3 — cả hai đều ghi byte trực tiếp xuống đĩa mà không kiểm tra nội dung.
Ai đang thực sự bị ảnh hưởng?
Điểm đặc biệt của CVE-2026-65640 là nó cần cả hai điều kiện cùng xảy ra. Nếu thiếu một trong hai, rủi ro thực tế giảm rõ rệt (dù vẫn nên cập nhật):
- Server dùng Imagick + Ghostscript — đây là câu hỏi về cấu hình máy chủ, không phải cài đặt WordPress. Hầu hết chủ site chưa từng kiểm tra điều này.
- Có tài khoản Author trở lên (hoặc bất kỳ vai trò nào có quyền
upload_files) — mặc định gồm Administrator, Editor, Author. Contributor và Subscriber thì không.
Vì vậy, đây không phải tấn công không cần xác thực (drive-by). Nhưng rủi ro thực tế phụ thuộc rất nhiều vào ai đang giữ tài khoản trên site của bạn. Các site nhiều tác giả, nền tảng membership, marketplace, hoặc site khách hàng có nhiều tài khoản freelance/biên tập viên đang đối mặt rủi ro thực sự — vì bất kỳ Author nào cũng có thể thử upload file “ngụy trang thành ảnh”.
Điều quan trọng cần nhớ: kẻ tấn công không cần được cấp tài khoản Author — chúng chỉ cần chiếm được một tài khoản. Một mật khẩu dùng lại, một Contributor bị phishing, hoặc một vụ credential stuffing vào tài khoản cũ đều đưa chúng tới đó. Lỗ hổng này biến một “chỗ đứng” nhỏ thành một vụ chiếm quyền toàn bộ máy chủ.
Cách kiểm tra site của bạn
Bạn có thể kiểm tra cả hai điều kiện trong vài phút:
1. Kiểm tra Imagick + Ghostscript
Cách nhanh nhất là vào Tools → Site Health → Info → Media Handling. Mục này liệt kê active editor, phiên bản ImageMagick, GD và Ghostscript. Nếu active editor là Imagick và có phiên bản Ghostscript, cả hai nửa điều kiện đã hội đủ.
Nếu có SSH, bạn có thể kiểm tra trực tiếp:
wp eval 'echo extension_loaded( "imagick" ) ? "imagick: yes" : "imagick: no";'
which ghostscriptLưu ý: các nền tảng managed hosting khác nhau về việc có Imagick/Ghostscript hay không, và có thể khác nhau giữa các gói, phiên bản PHP, và container image. Đừng đoán theo marketing của host — hãy kiểm tra Site Health trên site thực tế.
2. Kiểm tra ai có thể upload
Liệt kê người dùng và vai trò của họ:
wp user list --fields=ID,user_login,user_email,roles --format=tableCâu hỏi thực sự không phải “site tôi có Author không” mà là “có bao nhiêu tài khoản trên site có thể đưa file vào thư viện media, và tôi tin tưởng từng người đến đâu”. Các plugin membership, LMS, marketplace, form có trường upload file, và custom role editor đều có thể cấp quyền upload cho những vai trò bạn tưởng là quyền thấp.
Bản vá sửa lỗi như thế nào
Theo phân tích của Patchstack, bản vá (commit 7daaa50) viết lại hàm kiểm tra để kiểm tra nội dung thực tế của file trước khi tạo đối tượng Imagick. Cụ thể, nó:
- Chặn file mang chữ ký (signature) PostScript / EPS, dù theo phần mở rộng hay theo nội dung
- Chặn file giả danh PDF không thực sự bắt đầu bằng marker PDF
- Chặn các định dạng nén (gzip, bzip2) mà ImageMagick có thể âm thầm giải nén
- Xử lý thủ thuật prefix format specifier (ví dụ
msl:) mà attacker có thể thêm vào tên file để ép ImageMagick dùng decoder nguy hiểm — đồng thời tránh nhầm lẫn với drive letter trên Windows - Áp dụng kiểm tra tương tự cho filename đến từ URL và stream
Bài học thiết kế đáng giữ lại ngay cả sau khi đã cập nhật: phần mở rộng file chỉ là một nhãn mà người upload chọn, không phải sự thật về file. Bất kỳ thành phần nào phía sau sniff nội dung thay vì tin nhãn đều có thể mâu thuẫn với kiểm tra của bạn — và chính sự mâu thuẫn đó là nơi những lỗ hổng này sinh sống.
Hướng dẫn cập nhật WordPress 7.0.4
Như mọi security release, hãy cập nhật ngay lập tức, đừng gộp vào kế hoạch nâng cấp WordPress 7.1 (dự kiến 19/8). Các cách cập nhật:
- Qua WordPress Admin: Dashboard → Updates → Update to 7.0.4
- Qua WP-CLI:
wp core update - Qua RunCloud: Web Application → Settings → PHP & WordPress → Update WordPress
Trước khi cập nhật:
- Backup database và files — xem hướng dẫn Backup WordPress với RunCloud
- Kiểm tra tương thích plugin/theme với PHP 8.x
- Dùng môi trường staging để test trước nếu có thể
Sau khi cập nhật:
- Xóa bộ nhớ cache:
wp litespeed-purge all(nếu dùng LiteSpeed) - Kiểm tra các chức năng chính: đăng nhập, bài viết, upload media
- Verify không có lỗi PHP trong error log
Nếu bạn đang chạy một branch cũ (ví dụ 5.x, 6.x): WordPress đã backport bản vá xuống mọi branch từ 4.7, nên hãy cập nhật lên bản vá của branch đó thay vì nhảy major trong lúc áp lực. Sau đó lên kế hoạch nâng cấp major đàng hoàng.
Nếu thực sự chưa thể cập nhật ngay: biện pháp giảm thiểu đã được ghi nhận lâu nay cho ImageMagick là vô hiệu hóa nhóm coder PostScript-family trong file policy.xml của ImageMagick. Tuy nhiên, đây chỉ là biện pháp tạm thời và kém hơn hẳn việc cập nhật.
Kết luận
WordPress 7.0.4 là bản vá bảo mật quan trọng với một lỗ hổng RCE (CVE-2026-65640, CVSS 8.8) cho phép Author thực thi mã qua file upload trên server dùng Imagick + Ghostscript. Dù chưa ghi nhận khai thác thực tế (in-the-wild) tại thời điểm viết bài, đây là một con số có thể thay đổi bất cứ lúc nào — và phạm vi ảnh hưởng lên tới gần một thập kỷ release (từ 4.7.0 đến 7.0.3) khiến nó không nên bị trì hoãn.
Trong quá trình triển khai bảo mật và bảo trì cho khách hàng tại Code Tốt, chúng tôi luôn nhấn mạnh rằng cập nhật WordPress kịp thời là yếu tố sống còn — đặc biệt khi các lỗ hổng RCE kiểu này chỉ cần một tài khoản Author bị chiếm là có thể leo thang thành chiếm quyền toàn bộ máy chủ. Hãy tham khảo bài viết WordPress 7.0.3: 12 lỗ hổng bảo mật được vá để nắm bối cảnh các bản vá gần đây, và đọc thêm Tự động hóa WordPress với WP-CLI để cập nhật hàng loạt site nhanh chóng.
Nguồn: WordPress.org — WordPress 7.0.4 Release | Patchstack — WordPress 7.0.4 analysis | SecurityWeek — WordPress 7.0.4 Patches RCE | MagicWP — CVE-2026-65640: What to Do
