2026.10.16 セキュリティ

Movable Typeの脆弱性CVE-2026-96408とは：版の確認コマンドとCGI遮断の手順

シックス・アパートは2026年10月7日、CMS「Movable Type」に2件の脆弱性があると公表しました。アップグレード用のmt-upgrade.cgiでは認証なしにPerlコードを実行されるおそれがあり（CVE-2026-96408）、サイト内検索のmt-search.cgiでは非公開データを含む情報をSQLで抜かれるおそれがあります（CVE-2026-103668）。本記事では、稼働中の版をサーバー上で読み取るコマンド、修正版の選び方、更新できない環境でCGIを止める設定、修正版の出ないEOL版の扱いを実装者の目線で順に整理します。記載内容は2026年10月16日時点の公開情報にもとづきます。

まとめ：Movable Typeは修正版へ上げ、すぐ上げられないなら3つのCGIを止める

対象はサポート中の全系列です。Movable Typeは9.0.9以前・8.8.5以前・8.0.12以前、Premiumは9.0.9以前と2.17以前が当たり、9.2系はクラウド版だけが対象です。更新先は系列ごとに9.3.0・9.0.10・8.8.6・8.0.13（Premiumは9.3.0・9.0.10・2.18）と決まっています。

当日中に版を上げられない環境では、mt-upgrade.cgi・mt-search.cgi・mt-ftsearch.cgiの3つを外から実行できない状態にします。CGIで動かしているならファイルの削除かアクセス制限、PSGIならmt-config.cgiのRestrictedPSGIAppです。PSGI環境ではファイルを消しても機能は止まりません。

4系から8.4系までのEOL版には修正版が出ません。緩和策でしのぐのは移行先が決まるまでの間に限り、サイト内検索を止めたまま何か月も運用する状態は避けてください。

CVE-2026-96408とCVE-2026-103668の内容と10月7日公表の対象

今回の2件は、どちらもJVN#91153973でまとめて公表されました。報告者はGMO Flatt SecurityのRyotaK氏です。

mt-upgrade.cgiのコードインジェクションとCVSS v3.0基本値9.4

CVE-2026-96408の型はCWE-94（コードインジェクション）です。JVNの評価はCVSS v3.0で9.4、v4.0で9.3となっています。v3.0のベクトルは AV:N/AC:L/PR:N/UI:N で始まり、ネットワーク越しに、特別な条件なしに、ログインも利用者の操作も要らずに成立する型と評価されています。

想定される影響は、任意のPerlコードやSQLクエリの実行です。Movable TypeはWebサーバーの実行ユーザーで動くので、コードが通ればそのユーザーが読めるmt-config.cgiのDB接続情報も、書き込めるサイトの公開ディレクトリも攻撃者の手に渡ります。ベクトルの各指標の読み方はCVSSv3の評価基準と計算式で確認できます。

mt-upgrade.cgiは、インストールや版の更新のときにDBの構造を書き換えるスクリプトです。普段の運用では開かないため、存在を忘れたまま公開ディレクトリに置かれている環境が多いはずです。

mt-search.cgiのSQLインジェクションで非公開データが出る経路

CVE-2026-103668はCWE-89（SQLインジェクション）で、CVSS v3.0の基本値は8.6です。シックス・アパートの告知は、不正なSQLが実行され、非公開データを含むデータが出力されるおそれがあるとしています。

サイト内検索は公開側の機能なので、ログイン画面をIPで絞っていても守れません。下書きや公開前の記事、会員向けのページをMovable Typeで管理しているなら、それらが外から読める状態だったと考えて影響を見積もります。EOL版の4系では、mt-search.cgiの問題は4.3以降が対象とされています。

どのパラメータがどう評価されてコードやSQLに届くのかは、公表資料に書かれていません。本記事でも手口の推測はしません。JVNとIPAの注意喚起には悪用の確認に関する記載がなく、10月15日付のCISAの既知の悪用脆弱性（KEV）カタログにも両CVEは載っていませんでした。

9.3.0で直ったCVE番号なしの修正内容と4月公表分のRCE

Movable Type 9.3.0のリリースノートを開くと、修正はCVEの2件にとどまりません。CVE番号の付いていないものとして、run-periodic-tasksのOSコマンドインジェクションのおそれ、復元アップロードでのXSSとRCE、管理画面検索での不正なSQL、権限チェック漏れ多数などが並んでいます。

この並びは判断に直結します。緩和策で3つのCGIを止めても、CVE番号の無い修正分は塞がりません。緩和策は版を上げるまでのつなぎで、版を上げる作業そのものは省けないということです。

2026年4月8日にも、管理画面（mt.cgi）とData API（mt-data-api.cgi）が内部で使う仕組みのRCEとSQLインジェクション（CVE-2026-25776・CVE-2026-33088）が公表され、9.0.7・8.8.3・8.0.10などで修正されています。4月の更新を見送ったまま今回の版へ上げる場合は、その分の修正も一度に入ることになります。

稼働中のMovable Typeの版をサーバー上で確かめるコマンドと修正版の対応表

最初の作業は、どのサーバーのどのディレクトリにMovable Typeがあり、それが何版かを洗い出すことです。複数サイトを長く運用している組織ほど、移設や複製で忘れられた設置が残っています。

mt-upgrade.cgiの所在とlib/MT.pmの版番号行をgrepで読む手順

次のコマンドは読み取りだけで、設定を変えません。版番号はGitHubで公開されているlib/MT.pmの中で、$VERSIONに内部表記で書かれています。

# 1. サーバー内の Movable Type の設置場所を洗い出す（ファイル名で探す）
sudo find / -xdev -name 'mt-upgrade.cgi' 2>/dev/null

# 2. 見つかったディレクトリごとに版番号の行を読む
cd /var/www/cgi-bin/mt          # 1 で出たディレクトリに置き換える
grep -m1 "SCHEMA_VERSION ) = (" lib/MT.pm

# 出力例（9.3.0 の場合）
#     ( $VERSION, $SCHEMA_VERSION ) = ( '9.003000', '9.0003' );

内部表記は「主版.副版3桁＋修正版3桁」の形です。GitHubの各タグで確かめると、9.3.0は 9.003000、9.0.10は 9.000010、8.8.6は 8.008006 になっています。1で何も出ない場合でも、Movable Typeの設置時にCGIの名前を変えている環境があるため、lib/MT.pm を名前で探す方法も併せて使います。

Premiumの製品版番号（2.18など）は、管理画面のシステム情報で確かめてください。MT.pmに書かれた値とPremiumの番号の対応は、本記事では確認できていません。

修正版9.3.0・9.0.10・8.8.6・8.0.13とPremium 2.18

告知とJVNが示す対象と更新先を系列ごとに並べます。対象欄は影響を受ける版の上限です。

製品・系列	対象	更新先
MT 9.2系（クラウド版のみ）	9.2.1以前	9.3.0
MT 9.0系	9.0.9以前	9.0.10
MT 8.8系	8.8.5以前	8.8.6
MT 8.0系	8.0.12以前	8.0.13
Premium 9.0系	9.0.9以前	9.0.10
Premium 2系	2.17以前	2.18

Advancedの各製品も同じ版で対象と更新先が決まります。Premium 2.18には、8.8.6を土台にしたものと8.0.13を土台にしたものの2種類があります。Premium 2.18のリリースノートで、自社が使っている土台の系列を確かめてから入手してください。

同じ系列の中で上げるのが原則です。8.0系から9.0系への移行は動作確認の範囲が広がるため、今回の対応とは切り分けて計画します。

外部でmt-upgrade.cgiとmt-search.cgiの応答をcurlで確認する

サーバーに入れない環境や、CDNやリバースプロキシを挟んでいる環境では、外からの到達を確かめるのが早道です。下の例のドメインとパスは自社のものに置き換えます。

# 3つのCGIが外から実行できるかを HTTP ステータスで確認する
for f in mt-upgrade.cgi mt-search.cgi mt-ftsearch.cgi; do
  code=$(curl -s -o /dev/null -w '%{http_code}' "https://www.example.jp/mt/$f")
  echo "$f $code"
done

200が返るものは外から動く状態です。緩和策を入れた後は403か404になることを、この同じコマンドで確かめます。8系以降はmt-ftsearch.cgiを同梱していないため、その行は404で正常です。

Movable Type更新不可時のCGI削除とRestrictedPSGIApp設定

緩和策の書き方は、Movable TypeをCGIで動かしているか、PSGIで常駐させているかで分かれます。どちらで動いているか分からない場合は、前章のcurlで止まったことを確かめるまで作業を終えないでください。

CGI環境で3ファイルを止めるApacheとNginxの設定例

CGI環境では、3つのファイルを削除するか実行権限を外すのが最短です。ファイルを残したまま外からだけ止めたい場合は、Webサーバーの設定で拒否します。Apache 2.4ではmod_authz_coreの Require all denied を使います。

# Apache 2.4（Movable Type のディレクトリの設定か .htaccess に追記）
<FilesMatch "^mt-(upgrade|search|ftsearch)\.cgi$">
    Require all denied
</FilesMatch>

# Nginx（server ブロックに追記。CGI へ渡す location より前に書く）
location ~ /mt-(upgrade|search|ftsearch)\.cgi$ {
    deny all;
}

Nginxの正規表現のlocationは、設定ファイルに書いた順に照合されます（ngx_http_core_moduleのlocation）。CGIへ渡す既存の location ~ \.cgi$ より後ろに書くと、そちらが先に一致して拒否が効きません。設定を反映したら、前章のcurlで403を確かめます。

PSGI環境のmt-config.cgiにRestrictedPSGIAppを3行追記

PSGIで動かしている場合、RestrictedPSGIAppのリファレンスにあるとおり、CGIファイルの名前を変えたり消したりしても、その機能は止まりません。mt-config.cgiに次の3行を足します。

# mt-config.cgi に追記（MT 6.2 以降・クラウド版）
RestrictedPSGIApp upgrade
RestrictedPSGIApp new_search
RestrictedPSGIApp ft_search    # 6.2.4 以降で指定できる

# MT 6.0・6.1 の PSGI 環境は RestrictedPSGIApp が無いため、
# 次の2つに推測できない十分に長い文字列を設定する
UpgradeScript  （推測できない長い文字列）
SearchScript   （推測できない長い文字列）

リファレンスでは、upgradeはアップグレード機能、new_searchは記事・ウェブページのサイト内検索、ft_searchは全文検索にあたります。常駐プロセスに設定を読み込ませるため、追記後はPSGIのプロセスを再起動し、前章のcurlで止まったことを確かめます。

サイト内検索とアップグレード機能を止めたときの利用者と更新作業への影響

mt-search.cgiを止めると、サイトの検索窓は動かなくなります。検索結果ページに飛ぶフォームを置いているなら、緩和策を入れる前にフォームを外すか、外部の検索サービスへ一時的に切り替える告知を出します。

もう1つの影響は、アップグレード機能自体が止まることです。修正版へ上げる作業では、新しい版のファイルで上書きしたうえでDBの更新が走ります。作業の間だけ制限を外し、更新が終わったら版の確認と外からの到達確認をやり直す、という順番で計画します。

Movable Typeの侵害有無の点検とEOL版の継続・移行を決める判断基準

修正版を当てても、公表前後にすでに入り込まれていたかどうかは分かりません。版を上げる前後で痕跡を確かめ、そのうえで今後もMovable Typeを使い続けるかを決めます。

アクセスログで3つのCGIへの外部からのリクエストを洗い出す

最初に見るのは、Webサーバーのアクセスログです。普段は誰も開かないmt-upgrade.cgiへのアクセスが外部から来ていれば、それだけで調べる理由になります。

# ローテート済みの圧縮ログも含め、3つのCGIへのアクセスを接続元ごとに数える
sudo zgrep -hE "mt-(upgrade|search|ftsearch)\.cgi" /var/log/httpd/access_log* \
  | awk '{print $1, $9, $7}' | sort | uniq -c | sort -rn | head -50

# Webサーバーの実行ユーザーが書き込めるサイト配下で、直近14日に変わったファイル
sudo find /var/www -xdev -type f -mtime -14 \( -name '*.cgi' -o -name '*.php' -o -name '*.pl' \)

ログの場所はディストリビューションと構成で変わるので、存在するパスに置き換えてください。検索窓を置いているサイトではmt-search.cgiへのアクセスが大量に出るのが普通です。見るべきは、検索語とは思えない長い引数や、同じ接続元からの短時間の連続アクセスです。

見覚えのないCGIやPHPのファイルが出たら、消さずに保全を優先します。サイトの公開ディレクトリに置かれたWebシェルは、Movable Typeを直した後も裏口として残るためです。証拠を壊さずに調べる進め方はデジタルフォレンジックの調査の流れにまとめています。

修正版の出ない4系〜8.4系とPremium 1系で緩和策を恒久化しない理由

告知によれば、4.0から4.38、5系、6系、7系、8.4系、Premium 1系はすべて影響を受け、修正版は提供されません。EOL版で取れる手段は、前章の緩和策だけです。

緩和策を恒久策にしない理由は、9.3.0のリリースノートの並びにあります。CVE番号の無いRCEや権限チェック漏れは、3つのCGIを止めても残ったままです。4月の管理画面とData APIのRCEも、EOL版には同じく修正が届いていません。止めた3つ以外の入口が開いている前提で、移行の期限を決めます。

移行先は、サポート中の9.0系へ上げるか、別のCMSへ移るかの2択です。テンプレートやプラグインの改修が少ないなら9.0系への移行を選びます。独自プラグインが多く、どのみち作り直しになるなら、CMSの種類と選び方を踏まえて移行先を比べる段階です。

半年で2度のRCE修正を受けた更新体制の点検項目と見直しの条件

2026年はすでに4月と10月の2回、RCEを含む修正版が出ています。どちらも公表と同時に修正版が出ており、製品側の対応が遅れたわけではありません。差が出るのは利用者側の更新体制です。

次のどれかに当たる環境は、Movable Typeを使い続けるかどうかより先に、更新の担当と手順を整えるべき状態です。

4月の修正版（9.0.7・8.8.3・8.0.10など）を、今回の告知を見るまで当てていなかった
サーバーにある設置の数と版を、前章のコマンドで初めて把握した
保守契約が切れていて、制作会社に更新を頼む窓口が無い

同じ構図はCMS全般に共通する更新体制の問題です。WordPressでもwp2shell（認証不要のRCE）が公表されましたし、同じG30で扱ったSiteGuardの脆弱性のように、サイトを守る側の製品が入口になる例もあります。複数のサイトとサーバーにまたがって点検するなら、脆弱性診断・セキュリティ診断で外から到達できるCGIと導入製品の版を棚卸しすると、更新の優先順位を付けやすくなります。

Movable Typeの脆弱性CVE-2026-96408対応でよく受ける質問と回答

今回の脆弱性の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

サイト内検索を使っていなければ更新しなくてもよいですか？

更新は必要です。検索窓を置いていなくても、mt-search.cgiのファイルが公開ディレクトリにあれば外から直接呼び出せます。もう1件のmt-upgrade.cgiは検索機能と関係なく、すべての設置に含まれるスクリプトです。さらに9.3.0などの修正版には、CVE番号の無いRCEや権限チェック漏れの修正も入っています。検索を使っていないことは、mt-search.cgiを止めても困らない理由にはなりますが、版を上げなくてよい理由にはなりません。

MovableType.netやMovable Typeクラウド版の利用者も作業が必要ですか？

クラウド版は設定次第です。告知によれば、自動アップデートを有効にしている環境はすでに更新を終えています。自動アップデートを無効にしている場合は、利用者による早めの更新が必要です。管理画面で自動アップデートを有効にすると、翌日に更新が実行されると案内されています。作業の後は管理画面の版表示が9.3.0になったことを確かめてください。MovableType.netについては、10月7日の告知に影響の記載がありません。2026年10月16日時点で、本記事では対象かどうかを判断できていません。

mt-upgrade.cgiを削除するとMovable Typeの更新はできなくなりますか？

修正版のファイル一式で上書きすれば、新しい版のmt-upgrade.cgiが戻ります。ただしアクセス制限をWebサーバー側で掛けている場合や、PSGIでRestrictedPSGIAppにupgradeを入れている場合は、そのままだとアップグレード機能も動きません。更新作業の間だけ制限を外し、DBの更新が終わったら制限を戻すかどうかを決めます。作業の前後でlib/MT.pmの版番号を読み、上がったことを記録に残してください。

CISAのKEVに載っていなければ急がなくてもよいですか？

急ぐべきです。KEVは米国の機関が悪用を確認した脆弱性の一覧で、日本国内が中心の製品は登録が遅れる、または登録されないことがあります。CVE-2026-96408はCVSS v3.0で9.4、評価上はログインも利用者の操作も要らない型です。公表から時間がたつほど、修正版との差分から攻撃の手掛かりを探される余地が広がります。KEVの有無ではなく、外から到達できるかどうかで優先度を決めてください。

EOLの7系を使っていますが、9.0系へ上げるまでの間はどうすればよいですか？

まず3つのCGIを止め、外からのcurlで403か404になることを確かめます。7系をPSGIで動かしているなら、RestrictedPSGIAppに3行を足す設定が必要です。そのうえで、アクセスログで過去の不審なアクセスを洗い、移行の期限を決めます。7系には今回の分も4月の分も修正が届かないため、緩和策を入れた状態でも安全とは言えません。移行の見積もりは、テンプレートと独自プラグインの数で大きく変わります。