Movable Typeの検索・更新スクリプトに脆弱性！静的サイトでも入口を確認

シックス・アパートは2026年10月7日、Movable TypeとMovable Type Premiumのセキュリティ更新を公開しました。アップグレードスクリプトとサイト内検索に関する脆弱性が含まれます。静的HTMLを公開する構成であっても、CMSの実行部分へ到達できるかを別に確認する必要があります。

情報確認日は10月18日です。これは7日に公表された更新情報を未掲載の題材として整理した記事で、18日に新たな被害が起きたという速報ではありません。悪用や国内被害の有無は、今回確認した告知からは確定できません。以下では公式の対応情報と、本サイトが提案する構成点検を分けます。

出典：シックス・アパート：2026年10月7日のセキュリティ更新。

二つの問題は入口と影響が異なる

CVE-2026-96408は、アップグレードスクリプトmt-upgrade.cgiに関するコードインジェクションです。JVNは任意のPerlコードやSQLクエリが実行される可能性を示し、CVSS v4.0の基本値を9.3としています。

CVE-2026-103668はサイト内検索のSQLインジェクションで、提供元は非公開データを含む情報が出力されるおそれを説明しています。JVNのCVSS v4.0は8.8です。二つを一つの識別子や一つの影響条件として扱わず、検索の入口と更新用の入口をそれぞれ確認してください。

一般に、SQLの問題はデータベースへの問い合わせが意図しない形になること、コード実行の問題はプログラムの実行へ影響することを指します。ただし本記事は個別の攻撃手順を補足するものではありません。公式資料が示していない前提や被害を推測せず、該当する構成の特定を優先します。

関連する一次資料：JVN#91153973：Movable Typeにおける複数の脆弱性。

静的HTMLの公開とCMSの隔離は同じではない

以下は説明用の仮想例です。記事は静的HTMLとして別の公開領域へ出力している一方、検索フォームはCMSのCGIへ送信しているサイトを考えます。公開ページが動的に生成されなくても、その検索先が外部から呼べるなら、実行されるプログラムは残っています。

本サイトでは、トップページの配信方式だけで安全性を判断せず、検索フォームの送信先、更新用スクリプト、古い管理ディレクトリを一覧にする方法を勧めます。CMSの管理画面にアクセス制限があっても、すべてのCGIが同じ制限の対象とは限りません。実際の設定と許可された到達確認で確かめます。

逆に、外部からアクセスできないことだけで修正を不要と判断しないでください。社内や委託先からの接続、設定変更後の公開範囲も関わります。入口の制限は更新までの危険を小さくする手段として管理し、ソフトウェアの修正とは別の完了項目にします。

導入系列と製品名を修正版の表へ対応付ける

提供元が案内する修正版にはMovable Type 9.3.0、9.0.10、8.8.6、8.0.13と、Premiumの9.3.0、9.0.10、2.18があります。系列によって更新先が異なるため、単に数字の大きいものへ一律に置き換える手順ではありません。

保守担当には、Movable TypeかPremiumか、Advancedを含む構成か、現在の系列、クラウド・ソフトウェア・AMIなどの導入形態を確認します。提供元はサポートが終了した旧版も影響するとしています。普段更新している主環境だけでなく、移行後に残った古い設置先も対象に含めます。

台帳に残すのは「最新版へ更新済み」という一語ではなく、対象環境、更新前後の版、確認時刻、実行形態です。レンタルサーバーや保守会社へ委託している場合も、この情報なら担当が異なっていても作業の完了条件を共有できます。

すぐ更新できない場合は公式の緩和策を構成別に読む

提供元は、更新が難しい場合の緩和策として、mt-upgrade.cgi、mt-search.cgi、mt-ftsearch.cgiへのアクセス遮断や削除、PSGIの設定などを案内しています。実行形態や版によって方法が異なり、存在しないスクリプトもあるため、公式の該当する手順を確認してください。

検索を止めると、公開サイトの利用者が必要な情報へ到達できなくなることがあります。暫定措置を実施するなら、影響する検索フォームやリンク、代替案内を事前に洗い出します。ただし、使いやすさを維持するために危険な入口をそのまま残すという判断にはしません。

設定後は、管理画面でチェックが付いたことだけでなく、許可されない経路が実際に拒否されるか確かめます。外側のプロキシ、別ホスト名、古いURLのように、制限が及ばない経路がないかも確認します。自分が管理する範囲の試験にとどめ、攻撃用の要求を第三者環境へ送らないでください。

別ディレクトリへの更新で古い入口を残さない

提供元はソフトウェア版の更新について、DBのバックアップを取得した上で、上書きではなく別ディレクトリへインストールする方法を強く勧めています。実施する場合は、プログラムだけでなく設定とデータの整合性を確認し、公式の移行手順に沿って進めます。

本サイトの提案として、切り替え前には戻し先、DBの状態、公開物の出力先を対応付けます。新旧で同じDBを参照したまま、旧版のCGIを外部公開して残すと、「新しい方を更新した」という記録だけでは全体の状態を説明できません。退避ディレクトリも公開範囲を調べます。

ロールバックを行う場合も、脆弱な入口をそのまま復活させない計画が必要です。どの障害なら公開ページだけを戻し、どの障害ならCMSの利用を止めるかを決めておけば、緊急時に古い管理機能を全面公開してしまう事態を避けやすくなります。

検索と非公開データを別々に検証する

更新後の確認では、通常の検索語、検索結果の遷移、文字種、該当なしの表示を代表させます。非公開の記事や下書きについては、内容そのものを調査報告へコピーせず、テスト用のデータで公開範囲が守られることを確かめる方法を提案します。

再構築や予約公開を使う環境では、検索が動くだけで完了にしません。記事の更新、再構築、生成先への反映、必要なファイルの削除など、実際の運用経路を確認します。管理画面で新しい版が表示されても、公開側が旧設定を参照していないかを点検してください。

検証結果は正常系と制限する操作に分けて残します。緩和策で止めた検索を再開するときは、修正済み版の反映と再開の承認を確認します。暫定措置を解除する作業が、更新そのものより後になる場合もあります。

旧サイトを残す移行案件で確認すること

説明用に、旧CMSから静的ページを移し、旧環境を半年だけ保管する移行案件を考えます。利用者向けのリンクを消しても、旧ホスト名や管理用URLが外部から到達できれば、旧環境のプログラムは運用対象として残ります。本件でそのようなサイトが被害に遭ったという報告ではありません。

移行担当と保守担当は、旧環境を残す目的を、参照、再構築、緊急復旧などに分けて確認します。参照だけなら実行可能なCMSを公開したまま残す必要があるかを検討します。停止できない場合は、接続元、利用期間、更新責任者を明確にし、終了時の削除・隔離まで予定します。

サイト内検索だけ旧環境を参照しているケースでは、検索フォームの送信先を実際のHTMLと通信で確認します。管理者が想定した構成図と違えば、図を修正してから対策を選びます。外観を新しくしたことと、旧い実行経路を廃止したことを同一の完了報告にしないでください。

さらに、緩和策で検索を止めた場合の問い合わせやアクセス変化を確認します。検索の再開は利便性の作業であっても、修正済みプログラムを使うという条件から切り離しません。機能の所有者と保守の所有者が別なら、解除の合意を同じ記録へ残します。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
製品と系列	Premium・Advanced・導入形態	適合する修正版への更新を確認
実行経路	CGIかPSGIかと公開される入口	検索とアップグレードを別に点検
旧環境	退避先と以前のホスト名	新環境だけでなく残る入口も整理
暫定制限	停止した検索と解除条件	修正を確認してから必要な機能を再開
公開の試験	検索・再構築・生成先	画面表示だけでなく実際の反映まで確認

過去の情報流出は更新の成功だけで否定できない

参照した公式告知から、特定のサイトで非公開データが読まれたとは判断できません。一方、更新後に正常となったことは、それ以前の不正なアクセスがなかった証明にもなりません。不審な要求や設定変更がある場合は、ログの保存期間と調査範囲を担当者と確認します。

調査では、対象スクリプトへのアクセス、管理作業の申請、更新履歴を時間軸で照合します。単に検索要求が多かっただけで攻撃と断定せず、必要な情報を保全して専門担当へつなぎます。ログを十分に保持していない期間は、問題なしではなく未確認として扱います。

この更新を機に、静的な公開物とCMSの実行領域を区別して管理することが大切です。静的サイトという設計上の利点を保つには、残る検索や保守の入口を実際に把握し、修正版と接続制限の両方を稼働環境で確認する必要があります。