SHIRASAGIのコマンド実行と広告XSSを修正 v1.21.1への更新で確認する点

自治体サイトなどで使われるCMS「SHIRASAGI」の脆弱性2件が、2026年11月5日にJVNで公表されました。修正版はv1.21.1です。オープンデータの取り込みを管理できる利用者がサーバー上で任意のOSコマンドを実行し得るCVE-2026-118869と、広告を編集できる利用者が公開ページの閲覧者のブラウザーでスクリプトを実行し得るCVE-2026-117679です。運用者は配備中の版を確認し、対象なら更新してください。更新後は、取り込みと広告表示の両方が正しく動き、意図しない入力を処理しないことを確認します。

JVN#55454512では、コマンドインジェクションをCVSS 4.0で8.7、3.0で8.8と評価しています。XSSは4.0で5.1、3.0で5.4です。以下ではコマンド実行を主題とし、同じ更新で直る広告の問題も扱います。いずれも開発元が攻撃条件を説明していますが、今回確認した公表資料では、実際のサイトでの悪用は確認できません。公表日は、個別のサイトが侵害された日や修正版を適用した日とは別です。

オープンデータの取り込みを使うサイトを先に確認する

SHIRASAGI Projectの脆弱性告知によると、コマンド実行の対象はv1.19.0からv1.21.0です。対象のサイトではオープンデータ機能が構築され、ログインした利用者がデータセットとハーベストを管理できることが前提です。ハーベストは外部のデータを取り込むための機能です。攻撃者は取り込み設定のURL欄に細工した値を保存し、その後インポートを実行することで、CMSが稼働するシステム上で任意のOSコマンドを実行できる可能性があります。公開ページを未ログインで閲覧するだけで成立するものとしては案内されていません。

データセットを公開できる人と、取り込み元を登録して実行できる人は、同じとは限りません。初動ではCMSの管理者一覧だけを見るのではなく、オープンデータの機能が有効なサイトと、取り込み設定を変更できるアカウントを対応付けます。庁内の部署、保守会社、データ提供を担当する委託先などがそれぞれ別のアカウントを使う環境では、各アカウントの現在の権限と業務上の必要性を見ます。公開ページを編集しない担当者にも、データ取り込みのための権限が残っている場合があります。

開発元はv1.18.2以前について、ハーベスト機能がないか、存在しても安全な実装であるため、今回のコマンドインジェクションはないと説明しています。この説明は広告のXSSには当てはまりません。反対に、対象版でオープンデータを運用していない場合も、機能を使っていないという台帳の記載だけで済ませず、サイト設定や権限を確認して優先順位を決めます。使っていないサイトが確認できたら、取り込みを日常的に行い、外部委託先にも編集権限を付与しているサイトを先に点検できます。

コマンドが実行された場合に何が読まれ、書き換えられるかは、CMSのプロセスに与えた権限に左右されます。たとえば公開用ファイルだけを更新できる構成と、同じ実行環境からデータベースや外部連携の秘密情報を読み出せる構成では、調べる対象が違います。開発元の勧告はシステム上で任意のコマンドを実行できる可能性を示しますが、すべての環境で管理者権限を得られるとまでは説明していません。対応担当者は、実際のサービスアカウントとファイル・ネットワークの権限から影響範囲を絞ります。

広告は編集権限と公開画面でのクリックが関係する

XSSの影響版は、開発元が示す二つの経路で異なります。広告ページの追加属性を経由する経路はv1.12.0からv1.21.0、広告ページまたは広告バナーパーツのリンク表示設定を経由する経路はv1.19.0からv1.21.0です。両方とも、広告を管理する権限を持つ利用者が変更を保存し、公開ページで閲覧者が対象広告をクリックすることが攻撃条件です。管理画面で編集したときだけの問題ではなく、その内容を受け取る公開ページが確認対象です。

運用上は、広告ページだけでなく、複数の公開ページで使い回している広告バナーパーツも確認します。ある広告を一つのトップページでだけ点検しても、共通のパーツが別サイトや下層ページで使われていると、表示の違いを見逃す可能性があります。現在公開中の広告、公開予約のある広告、共通パーツから表示される広告を分け、どの設定がどの公開ページに出力されるかを把握します。ブラウザーに実際に渡されたリンク属性を確認すると、管理画面の入力欄だけを見る場合よりも、設定の影響を追いやすくなります。

正規の広告担当者が設定を変更したという記録は、その変更が安全だったことの証明にはなりません。身に覚えのない編集が見つかった場合は、公開ページを直す前に、対象広告、変更時刻、確認できる編集履歴、影響するページを記録します。閲覧者が実際にクリックしたかは、CMSの編集記録からは分かりません。アクセス記録を確認できる場合も、広告の表示、クリック、ブラウザー上でのスクリプト実行を区別します。記録のない項目について、発生したとも発生しなかったとも断定しません。

v1.21.1への更新と旧版からの移行を切り分ける

開発元の案内では、両方ともv1.21.1で修正されています。対応の起点は、管理している全サイトで実際に稼働している版をそろえて確認することです。同じサーバーで複数サイトを配信している場合は、共通のCMSを参照しているサイトと、個別に配備したサイトを区別します。Webを受け付ける実行環境と、データ取り込みを実行する環境を分けているなら、片方だけが旧版のまま残っていないかも点検します。管理画面の表示や配備記録の一方だけを根拠に更新完了と扱わず、実際に処理する構成を確認します。

とくにv1.14.2以前から更新する場合、開発元はv1.15.0でCMSに重大な非互換があると注意しています。古い環境に対して、修正版が出たという理由だけで本番を直接入れ替えると、公開ページの表示や更新業務に影響が出ても切り分けが難しくなります。本稿では、設定とコンテンツを控え、同じ構成に近い検証環境で管理画面、公開ページ、独自テンプレート、データ取り込みを点検したうえで本番へ反映することを勧めます。更新前の控えは取得するだけでなく、復元できる手順と担当者も確認します。

すぐにバージョンアップできない場合、開発元は個別告知に挙げた修正コミットを反映する方法も案内しています。XSS側は複数のコミットが指定されているため、一つだけ適用して両経路を塞いだと扱わないでください。コマンド実行側の修正も別です。独自改修がある環境では、保守担当者が適用対象と衝突箇所を確認し、どの修正が本番の配備物に入ったかを記録します。コミット反映は、今後の更新でその差分が失われないよう配備元にも反映し、後日、修正版に移行する予定と切り分けます。

更新までの間、業務に不要な取り込み権限や広告管理権限を見直すことには意味があります。利用を一時停止できる機能があるなら、影響を業務担当者と確認したうえで止めることも考えられます。ただし、これらは本サイトの露出低減の提案です。対象のコードを修正したことにはなりません。また、公開ページへの入口だけを制限しても、既に編集権限を持つアカウントや保存された広告の内容までは確認できません。いつまで暫定措置を続けるかと、修正版を入れる担当を別に決めます。

正常な取り込みと公開広告を検証環境で確認する

取り込み機能は、管理者が用意した無害なデータセットを使い、URLの保存からインポート結果の表示までを通します。次に、組織の運用で許可しない形式の入力を与えたとき、想定どおり拒否されるかを確認します。試験の目的は、通常業務を止めずに入力が適切に扱われることを確かめることです。本番で勧告に載っている攻撃例を実行する必要はありません。URLの接続先が停止しているだけの場合と、入力の制限で処理されなかった場合を区別するため、正常系と拒否側の結果を一緒に残します。

広告側では、通常の広告リンクが公開画面に表示され、クリック時に想定した遷移をするかを確認します。そのうえで、追加属性とリンク表示を別々に確認し、管理画面の見た目にかかわらず意図しない属性が公開画面に出力されないかを見ます。公開キャッシュを使う構成では、更新直後にCMS側で確認したページと、閲覧者が受け取るページに違いがないことも点検します。異常があれば、CMSの版、保存済み設定、テンプレート、キャッシュのどこに原因があるかを順に切り分けます。

編集や取り込みの成功だけでは、低い権限の利用者が本来できない作業を実行できないことは分かりません。検証環境に権限の違う担当者を用意し、データセットや広告の管理を許可する役割と、閲覧または一般のコンテンツ編集だけを許可する役割で結果を比較します。これは修正版の動作確認とあわせて、自組織の役割設定が想定どおりかを調べるための確認です。今回の脆弱性について、別の権限回避が報告されたという意味ではありません。

更新と過去の調査は別に完了を記録する

疑わしい入力や編集があれば、設定を消す前に、取り込み元の変更履歴、取り込みの実行記録、広告の編集・公開時刻、確認可能なサーバーログを保全します。コマンド実行が疑われる場合は、CMSのサービスアカウントで作成・変更されたファイルや、普段と異なる外部通信が調べられるかを確認します。広告については、何がどの期間に公開されたかを整理し、配信経路ごとのキャッシュも確認します。これらは状況に応じた調査の出発点であり、特定の痕跡だけで今回の攻撃だと断定できるわけではありません。

対応記録には、更新した版と対象サイト、実際に稼働する処理系の確認結果、取り込みと広告の試験結果、過去の記録を確認できた範囲を分けて残します。更新に成功しても、以前に何が実行されたかまでは分かりません。一方、過去のログが十分に残っていないことを理由に、修正作業を後回しにする必要もありません。公開ページの運営者と基盤の保守担当者が別なら、どちらが公開出力を確認し、どちらが実行環境のログを保全するかを明確にしておくと、作業を重ねずに対応を進められます。