Lỗ hổng Movable Type JVN#91153973: cập nhật và biện pháp tạm thời

Ngày 7/10/2026, IPA và JPCERT/CC (Nhật Bản) công bố các lỗ hổng (JVN#91153973) trong Movable Type, phần mềm dùng để làm website. Lỗ hổng nghiêm trọng nhất có mức độ 9.4 (nghiêm trọng): có nguy cơ người chưa đăng nhập cũng chạy được chương trình trên máy chủ.

Thêm vào đó, ngày 5/11 Movable Type nhánh 8.0 đã hết hỗ trợ bảo mật. Bài viết này dành cho các công ty đang vận hành website bằng Movable Type: cách xem phiên bản, các bước cập nhật, cách tạm thời giảm rủi ro khi chưa cập nhật ngay được, và cách tìm dấu vết bị tấn công. Website đang giao hẳn cho đơn vị làm website cũng thuộc diện này.

Lỗ hổng này là gì, nguy hiểm ra sao?

Đợt sửa lần này xoay quanh hai vấn đề dưới đây. Cả hai đều được đánh giá là có thể bị tấn công từ Internet mà không cần đăng nhập.

Ngoài ra, nhiều vấn đề bảo mật khác cũng đã được sửa. Người báo cáo là RyotaK của công ty GMO Flatt Security.

Phiên bản bị ảnh hưởng và bản cần lên

Trước hết, hãy xác định website của công ty đang ở nhánh nào.

※ Bản cloud bật cập nhật tự động theo mặc định; nếu không tắt, website đã được cập nhật xong. Nếu đã tắt, hãy cập nhật sớm.

※ Để dùng bản mới nhất của bản phần mềm, hợp đồng bảo trì hằng năm phải còn hiệu lực. Nếu đã hết hạn, hãy xem hướng dẫn của Six Apart.

Diễn biến

• 8/4/2026
  Công bố JVN#66473735. Điểm yếu ở màn hình quản trị và Data API, mức độ 9.8 (nghiêm trọng). Bản vá gồm 9.0.7, 8.8.3, 8.0.10…
• 7/10/2026
  Công bố JVN#91153973. Phát hành 9.3.0, 9.0.10, 8.8.6, 8.0.13
• 26/10/2026
  Phát hành 9.3.1, 9.0.11, sửa các vấn đề phát hiện ở 9.3.0 và 9.0.10
• 5/11/2026
  Nhánh 8.0 hết hỗ trợ bảo mật

6 bước kiểm tra và xử lý

1. Xác định ai đang quản lý website

   Người phụ trách trong công ty, đơn vị làm website hay đơn vị bảo trì? Nếu chưa rõ, hãy tìm hợp đồng máy chủ hoặc email từ thời làm website.

2. Xem phiên bản

   Đăng nhập màn hình quản trị; phiên bản thường hiện ở khu vực phía dưới màn hình hoặc tương tự. Nếu không thấy, hãy hỏi đơn vị đang quản lý website.

3. Sao lưu

   Trước khi cập nhật, lưu lại cả file của website và cơ sở dữ liệu.

4. Cập nhật lên bản vá

   Six Apart đặc biệt khuyến nghị cài bản mới vào một vị trí riêng rồi chuyển sang, thay vì ghi đè lên bản cũ. Sau khi cập nhật, hãy kiểm tra các trang chính, biểu mẫu liên hệ và chức năng tìm kiếm trong website có hoạt động không.

5. Nếu chưa cập nhật ngay được, áp dụng biện pháp tạm thời

   Làm theo mục "Biện pháp tạm thời khi chưa cập nhật được" bên dưới. Các bản cũ không có bản vá cũng vậy.

6. Tìm dấu vết bị tấn công

   Xem các mục kiểm tra bên dưới. Nếu có điểm khả nghi, hãy đổi mật khẩu quản trị và trao đổi với đơn vị chuyên môn.

Biện pháp tạm thời khi chưa cập nhật được

Six Apart hướng dẫn các cách sau như biện pháp tạm thời khi chưa cập nhật ngay được. Muốn khắc phục triệt để thì vẫn phải cập nhật.

• Nếu chạy bằng CGI (mọi phiên bản): xóa mt-upgrade.cgi, mt-search.cgi, mt-ftsearch.cgi, hoặc giới hạn truy cập để không chạy được từ bên ngoài
• Nếu chạy bằng PSGI (6.2 trở lên, bản cloud): đặt upgrade, new_search, ft_search cho RestrictedPSGIApp trong mt-config.cgi (ft_search dành cho 6.2.4 trở lên)
• Nếu chạy bằng PSGI (6.0, 6.1): đặt cho UpgradeScript và SearchScript một chuỗi đủ dài, không thể đoán trước

※ Khi tắt chương trình tìm kiếm, chức năng tìm kiếm trong website sẽ không dùng được. Chương trình nâng cấp thì khôi phục lại vào lần cập nhật tiếp theo.

※ Với các phiên bản cũ hơn bản vá của lỗ hổng tháng 4 (9.0.7, 8.8.3, 8.0.10…), hãy áp dụng cả biện pháp tạm thời được hướng dẫn khi đó (như xóa mt-data-api.cgi). Biện pháp này chỉ chặn được tấn công đi qua Data API, nên vẫn cần cập nhật.

Cách tìm dấu vết bị tấn công

JVN và Six Apart chưa công bố dấu hiệu mang tính quyết định nào, chẳng hạn địa chỉ IP nguồn tấn công. Hãy kiểm tra các mục sau.

• Trong log truy cập có truy cập nào tới mt-upgrade.cgi vào thời điểm công ty không tự cập nhật không?
• Các truy cập tới mt-search.cgi có từ khóa tìm kiếm là chuỗi dài bất thường hoặc chứa ký hiệu lạ không?
• Có tài khoản quản trị lạ, hoặc tài khoản bị thay đổi quyền không?
• Template hoặc các file đã đăng có thay đổi, hay file lạ nào không?

Log có truy cập không có nghĩa là đã bị xâm nhập. Hãy xem đó là một manh mối và đánh giá cùng các mục khác.

Nếu đang dùng phiên bản cũ (nhánh 8.4, 7…)

Phiên bản đã hết hỗ trợ sẽ không có bản vá, nên biện pháp tạm thời chỉ là giải pháp chữa cháy. Có hai hướng chính.

• Nâng lên phiên bản Movable Type mới hơn: kiểm tra giấy phép và hợp đồng bảo trì hằng năm, rồi chuyển sang nhánh 8.8 hoặc 9. Cần kiểm tra plugin và template có chạy được trên bản mới không.
• Chuyển sang hệ thống khác: tùy quy mô website và cách cập nhật nội dung, làm lại có khi rẻ hơn về lâu dài.

Hướng nào tốt hơn tùy vào tình trạng máy chủ và số lượng plugin. Nếu nền tảng máy chủ cũng đã cũ, hãy xem thêm bài "Bảo mật hệ thống cũ: bắt đầu từ đâu?"; nếu không liên lạc được với đơn vị làm website, hãy xem thêm bài "Tiếp nhận bảo trì hệ thống cũ không có tài liệu". Nếu công ty cũng có website WordPress, bài "Lỗ hổng WordPress CVE-2026-119977" cũng có thể hữu ích.

Nếu website đang do đơn vị làm website quản lý

Dù giao website cho đơn vị làm website, chủ sở hữu website vẫn là công ty bạn. Nên hỏi họ những điều sau:

• Movable Type của chúng tôi đang ở phiên bản nào? Đã lên bản vá JVN#91153973 chưa?
• Lỗ hổng JVN#66473735 hồi tháng 4 cũng đã xử lý xong chưa?
• Hợp đồng bảo trì hằng năm còn hiệu lực không? Đứng tên ai?
• Trong các plugin đang dùng, có cái nào đã ngừng phát triển không?
• Chúng tôi có thể nhận thông tin đăng nhập màn hình quản trị và máy chủ không?

Để nguyên hay xử lý ngay?

Digi Dinos có thể giúp gì?

Digi Dinos là công ty hỗ trợ DX, bảo mật, vận hành và bảo trì hệ thống, có văn phòng tại Nhật Bản và Việt Nam. Trong 8 năm, chúng tôi đã thực hiện hơn 150 dự án, với đội ngũ làm việc được bằng tiếng Nhật.

• Cập nhật và rà soát Movable Type: kiểm tra phiên bản, sao lưu, biện pháp tạm thời, cập nhật, kiểm tra dấu vết.
• Tiếp nhận bảo trì website có sẵn: tiếp nhận cả website đã ngừng cập nhật hoặc do công ty khác làm.
• Chuyển sang hệ thống mới: tìm hiểu nên nâng cấp từ bản cũ hay làm lại, rồi đề xuất chi phí và thời gian.
• Không có tài liệu cũng không sao: kể cả khi nhà cung cấp cũ đã không còn và không ai hiểu hệ thống, chúng tôi tự đọc mã nguồn, dựng lại tài liệu và đề xuất kế hoạch hoàn chỉnh.
• Bảo hành vĩnh viễn: nếu phát hiện lỗi ở phần chúng tôi đã sửa, chúng tôi chịu trách nhiệm sửa, không giới hạn thời gian chừng nào hợp đồng bảo trì còn tiếp tục.

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