2026年11月5日、自治体や企業のサイトで使われる国産のオープンソースCMS「SHIRASAGI」に、OSコマンドインジェクションとクロスサイトスクリプティングの2件の脆弱性がJVN#55454512で公表されました。重いほうのCVE-2026-118869は、ログインできる利用者がサーバー上で任意のOSコマンドを実行できるおそれがあり、CVSS v3.0の基本値は8.8です。影響はv1.12.0からv1.21.0まで、修正版はv1.21.1です。本記事では、対象になる版と機能の見分け方、修正を取り込めたかを確かめるコマンド、公式マニュアルに沿った更新手順、修正コミットから読めるRubyの落とし穴を、2026年11月5日時点の一次情報で整理します。
まとめ：v1.19.0以降でオープンデータを使う環境は当日中にv1.21.1へ
最優先は、v1.19.0からv1.21.0でオープンデータのハーベスト機能を使っている環境です。管理画面にログインできるアカウントを1つ奪われるだけで、サーバーを乗っ取られる経路が開いています。v1.21.1へ上げ、更新後にマイグレーションまで流してください。
v1.12.0以降で広告の機能を使う環境は、XSSの対象です。こちらも同じv1.21.1で塞がります。v1.14.2以前は大きな非互換をまたぐため、開発元が公開した修正コミットを個別に当てる方法も選べます。
なお、v1.21.1が同梱するRailsは8.1.3.1です。2026年11月4日に出たRails 8.1.4.1の修正は含まれないため、SHIRASAGIを上げたあともRails側の判定は別に要ります。
JVN#55454512で公表された2件の中身と影響を受けるSHIRASAGIの版
2件とも東京理科大学の佐藤勇斗氏がIPAへ届け出て、JPCERT/CCが開発元のSHIRASAGI Projectと調整しました。修正版v1.21.1は2026年10月30日にリリースされ、JVNでの公表はその6日後です。
OSコマンドインジェクションCVE-2026-118869の発生箇所と前提条件
開発元の告知によると、発生箇所は管理画面の「オープンデータ・データセットのハーベスト」です。「インポート」の編集画面にある「URL」欄へ不正な値を保存し、そのあと「データセットをインポートする」を実行すると、サーバー上でOSコマンドが動きます。
影響はv1.19.0からv1.21.0までです。v1.18.2以前はハーベスト機能が無いか、あっても安全な実装のため影響を受けないと告知に明記されています。CWEの分類はCWE-78で、仕組みの一般論はOSコマンドインジェクションの仕組みと引数配列で防ぐ実装で解説しています。
クロスサイトスクリプティングCVE-2026-117679の2つの入力経路
XSSは広告の機能に2つの経路があります。1つ目は、広告ページの編集画面の「追加属性」に不正な属性値を保存する経路で、公開画面で広告をクリックした閲覧者のブラウザでスクリプトが動きます。影響はv1.12.0からv1.21.0までです。
2つ目は、広告ページや広告バナーパーツの「リンク表示」の入力形式を、ブラウザの開発者ツールで書き換えて不正な値を保存する経路です。こちらはv1.19.0以降が対象です。画面側の選択肢だけで入力を縛り、サーバー側で値を検証していなかった型だと読めます。XSSそのものの防ぎ方はXSSとCSRFの違いと実装レベルの対策にまとめています。
CVSS v3.0 8.8とv4.0 8.7の読み方とログイン権限が前提になる理由
CVE-2026-118869のベクトルは、CVSS v3.0でAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hです。PR:Lは、攻撃者に管理画面へのログイン権限が要ることを示します。誰でも外から突ける種類ではありません。
ただし、条件が軽いとは言えません。自治体サイトでは、各課の担当者や制作会社など、管理画面のアカウントを持つ人が多くなりがちです。そのうち1つのパスワードが漏れれば、コンテンツの編集権限からサーバー全体の操作まで一気に広がります。XSS側はPR:LとUI:R（閲覧者の操作が要る）で、基本値はv3.0で5.4です。
修正コミット98eca87の差分で読むURI.openとOSコマンド実行の関係
OSコマンドインジェクションの修正は、GitHubのコミット98eca871件です。題は「remote code execution vulnerability」で、17ファイルに手が入っています。開発元は攻撃手順を公表していないため、ここでは差分とRubyの仕様から読める範囲だけを書きます。
URI.openが「|」始まりの文字列でコマンドを起動するRubyの仕様
Rubyの公式ドキュメントCommand Injectionは、引数の先頭が「|」のときにコマンドを実行するメソッドとして、Kernel#openやIO.readと並べてURI.openを挙げています。
URI.openの説明によれば、文字列が「http://」のようなスキーム付きで始まればURLとして開き、そうでなければKernel#openに処理を回します。つまり、URLのつもりで受け取った値が「|」で始まると、Kernel#open経由でシェルコマンドとして動きます。
OpenURI.open_uriへの置き換えとurl検証の追加で塞いだ経路
コミットでは、ハーベスト関連のckan_package.rb、shirasagi_package.rb、shirasagi_scraper.rbなどにあったURI.openが、すべてOpenURI.open_uriに置き換わりました。open-uriのソースを見ると、open_uriは受け取った文字列を必ずURI.parseに通し、Kernel#openへは回しません。
あわせてimporter.rbでは、source_urlに「url: true」の形式検証が加わりました。入口で不正なURLを保存させず、出口で開き方を変える二重の手当てです。告知が経路として名指しした「URL」欄と、この2か所の変更はよく噛み合います。
自社のRailsコードで同型のURI.openを洗い出すgrepの手順
同じ型は、外部URLを取りに行くRailsアプリならどこにでも潜みます。RSSの取り込み、画像URLからのアップロード、Webhookの検証などが典型です。次の2つのコマンドで、手元のコードを点検できます。
cd /path/to/your-app
grep -rnE "URI\.open|Kernel\.open|IO\.(read|readlines|foreach)\(" app lib
bundle exec rubocop --only Security/Open app libRuboCopのSecurity/Openは、今回の差分でもテストコードの抑止コメントとして登場する検査です。利用者の入力が届く箇所で見つかったら、OpenURI.open_uriかNet::HTTPに置き換え、スキームをhttpsとhttpに限る検証を足します。入力からコード実行に至る経路の全体像はRCEが成立する5経路と直し方で整理しています。
稼働中のSHIRASAGIが対象かをgitとgrepで判定する確認コマンド
判定は「稼働中の版」と「修正が入ったか」の2段で行います。git cloneで入れた環境はgitで、アーカイブ展開で入れた環境はファイルの中身で確かめます。
git describeとタグc089432で稼働中の版を突き合わせる手順
公式マニュアルの標準構成では、SHIRASAGIは/var/www/shirasagiに置かれます。v1.21.1のタグが指すコミットはGitHubのリリースでc089432と確認できます。
cd /var/www/shirasagi
git fetch --tags origin
git describe --tags
git log -1 --format="%h %cd" --date=shortgit describeが「v1.21.0」や「v1.20.2-15-g…」を返すなら未修正です。「v1.21.1」か、それ以降のタグが出れば修正済みと判断できます。
importer.rbのurl: true有無で修正の取り込みを確かめる方法
アーカイブで入れた環境や、独自に手を入れた環境では、タグが当てになりません。修正で変わった行を直接見ます。
cd /var/www/shirasagi
grep -n "validates :source_url" app/models/opendata/harvest/importer.rb
grep -rn "URI.open\|OpenURI.open_uri" app/models/opendata/harvest/1行目が「validates :source_url, presence: true, url: true」を返せば、OSコマンドインジェクションの修正は入っています。2行目で、ckan_package.rbなどの該当行がOpenURI.open_uriになっているかも見てください。XSS側は8件のコミットに分かれているため、版で判断するほうが確実です。
ハーベスト設定のURL欄と広告の追加属性に不審な値が残っていないかの点検
更新は今後の悪用を止めますが、すでに保存された値は消しません。ハーベストのインポート設定のうち、URLがhttpかhttpsで始まらないものを一覧にします。
cd /var/www/shirasagi
bundle exec rails runner -e production 'Opendata::Harvest::Importer.all.each { |i| puts [i.id, i.name, i.source_url].join("\t") unless i.source_url.to_s.match?(%r{\Ahttps?://}) }'読み取りだけのコマンドですが、本番で流す前に検証環境で試すと安全です。1件でも出たら、その設定の作成者と更新日時を確かめ、サーバーのプロセスと接続のログを保全します。広告の「追加属性」も、管理画面でonclickやjavascript:を含む値が無いか目で確かめてください。
公式マニュアルに沿ってv1.21.1へ上げるgitとマイグレーションの手順
更新の手順はSHIRASAGI開発マニュアルの「SHIRASAGIの更新」に書かれています。ここでは、git cloneで入れた環境の流れを順に追います。
現行版をgitブランチへ退避してorigin/stableを取得するコマンド
マニュアルは、作業前の状態をgitのブランチに残してから最新版を取る手順を示しています。DBのバックアップ手順は書かれていないため、MongoDBのダンプは別に取っておきます。
cd /var/www/shirasagi
git add .
git commit -a -m "backup at $(date +%Y-%m-%d)"
git branch -m backup-$(date +%Y-%m-%d)
git fetch origin
git checkout -b stable origin/stablegit branch -mは、作業中のブランチの名前を変えるコマンドです。元の状態はbackup-日付のブランチに残り、そこへいつでも戻せます。
bundle installとss:migrateを忘れると修正が効かない理由
ソースを入れ替えたら、Gemを更新してDBの差分を当てます。v1.21.1のリリースノートは「重要な修正プログラム」がマイグレーションで適用されると明記し、実行を忘れないよう求めています。
bundle install --without development test
bundle exec rake ss:migrate独自の設定ファイルがある場合は、config/defaults配下の既定値とdiffで比べて差分を反映します。最後にアプリケーションサーバーを再起動し、git describeの確認をもう一度流してください。
v1.21.1が求めるRuby 3.4.12とRails 8.1.3.1の環境差の確認
リリースノートが示すv1.21.1の動作環境は、Ruby 3.4.12、Rails 8.1.3.1、MongoDB 8.0、Node.js 24です。v1.17.0でRubyの管理ツールがasdfに変わっているため、古い環境から上げるときはRubyの入れ替えから始まります。マニュアル内のコマンド例はRuby 3.1.4のままなので、版の指定はリリースノートに合わせます。
即日更新・コミット個別適用・機能停止の3択を決める版ごとの判断基準
選ぶ道は、稼働中の版と使っている機能で決まります。「様子を見る」は選択肢に入れません。
v1.19.0〜v1.21.0でハーベストを使う環境は即日更新を選ぶ
告知が非互換を注意しているのはv1.14.2以前からの更新だけで、この帯は対象外です。サーバーを乗っ取られる経路が開いている以上、検証環境での確認を半日で済ませ、当日中に本番を上げます。ハーベストを使っていなくても、機能自体はコードに残るので更新は省きません。
v1.14.2以前は非互換のためコミット個別適用で先に塞ぐ判断
告知は、v1.14.2以前からの更新には重大な非互換があると注意しています。この帯でv1.21.1まで一気に上げるのは、1日では終わらない作業です。告知はv1.18.2以前をOSコマンドインジェクションの対象外としているため、この帯で塞ぐべきはXSSです。残るXSSは、告知に並ぶ8件のコミットを当てて先に塞ぎ、版上げは計画を立ててから進めます。
v1.21.1へ上げてもRails 8.1.4.1の修正は入らない点の扱い
v1.21.1のGemfile.lockでは、railsもactionpackも8.1.3.1です。Railsは2026年11月4日に8.1.4.1を公開し、21件のセキュリティ問題を直しました。SHIRASAGIのv1.21.1はその5日前に出ているため、この修正を含みません。
SHIRASAGIはDBにMongoDBを使うため、Railsの21件がすべて当てはまるわけではありません。どの項目が該当するかはRailsの脆弱性21件と影響判定の手順で確かめ、開発元がRailsを上げた版を出すまで告知を追います。
9月のJVN#37476837と合わせてv1.20.2以前が抱える計4件
2026年9月にもJVN#37476837で2件が公表されています。XSSのCVE-2026-81635と、グループウェアの共有ファイルを権限の無い利用者が取得できるCVE-2026-82582で、修正版はv1.21.0でした。v1.20.2以前のまま止まっている環境は、今回の2件と合わせて4件を抱えています。v1.21.1への更新で4件とも解消します。
SHIRASAGIを自治体・企業サイトで運用する側が更新後に続ける点検
SHIRASAGIの脆弱性は、2022年6月から今回までに確認できただけで7回、JVNで公表されています。今回の更新を一度きりの作業で終わらせない仕組みが要ります。
JVNとss-proj.orgの告知を追う更新監視の仕組みづくり
今回は、修正版の公開からJVNでの公表まで6日の差がありました。JVNだけを見ていると、その間の更新機会を逃します。SHIRASAGI Projectのリリース一覧とGitHubのリリースを週1回は確かめ、担当者と確認日を記録に残す運用がお勧めです。管理画面のアカウントの棚卸しも同じ周期で行うと、PR:Lの脆弱性に対する備えになります。
侵害が疑われるときのログ保全と個人情報保護委員会への報告の速報期限
点検で不審なハーベスト設定が見つかった場合、サーバー上のファイルとDBが読まれた前提で動きます。住民の申請情報やメールアドレスを持つサイトなら、個人データの漏えい等として報告の対象になり得ます。速報は把握から3〜5日以内が目安です。期限と対象の4類型は個人情報保護委員会への報告義務の実務で確認できます。
独自改修やプラグイン追加をしたSHIRASAGIを外部の脆弱性診断に出す場面
SHIRASAGIを独自に改修している環境では、開発元の修正が自社コードまで届きません。今回のURI.openのように、同じ型の書き方が独自部分に残っていても、公開の告知には出てこないからです。改修箇所が多い、外部URLを取り込む機能を足している、という環境は、脆弱性診断・セキュリティ診断で改修部分まで点検する価値があります。進め方と費用の目安は脆弱性診断の種類と外注時の判断基準にまとめています。
SHIRASAGIの脆弱性とv1.21.1更新についてのよくある質問
SHIRASAGIの脆弱性対応で迷いやすい点を、2026年11月5日時点の告知とJVNにもとづいて答えます。
LGWAN-ASPやクラウド版のSHIRASAGIでも自分で更新する必要はありますか？
開発元の告知は、提供形態ごとの対応には触れていません。LGWAN-ASPやクラウドの形で使っている場合、サーバーの更新は提供事業者の作業になるのが通常です。v1.21.1への更新日を契約先に問い合わせ、回答を記録に残してください。自前のサーバーで動かす環境が別に無いかも、この機会に確かめておきます。
オープンデータ機能を使っていなければCVE-2026-118869の影響はありませんか？
悪用の入口はハーベストのインポート設定なので、その画面を操作できる権限がなければ突けません。ただし、機能のコード自体は対象の版に含まれています。権限設定の誤りや今後の改修で入口が開く可能性もあるため、使っていない環境でも更新は省かないでください。
v1.18.2以前のSHIRASAGIはOSコマンドインジェクションの対象外ですか？
告知によれば、v1.18.2以前はハーベスト機能が無いか、あっても安全な実装のため対象外です。ただし、v1.12.0以降ならXSSの対象になります。さらにv1.20.2以前は9月公表の2件も残っているため、古い版ほど抱える問題は増えます。
更新までの間、回避策としてハーベストのインポートを止めておけますか？
告知に回避策の記載はありません。一時しのぎとして、ハーベストの設定を編集できる権限を管理者だけに絞り、インポートを実行しない運用は考えられます。これは開発元が示した対策ではないため、更新までの数日に限ってください。
SHIRASAGIから別のCMSへ乗り換えるべきかはどう判断すればよいですか？
今回の脆弱性だけを理由に乗り換える必要はありません。開発元はJVN公表の前に修正版を出し、告知で影響範囲とコミットまで示しています。判断の軸は、更新を誰がどの周期で回せるかです。他のCMSでの対応例はMovable Typeの脆弱性と版の確認手順やWordPress更新中のRCEと安全な更新手順で比べられます。
関連記事
- OSコマンドインジェクションとは？仕組みと引数配列で防ぐ実装をPython・Node.js・Goのコード例で解説：CVE-2026-118869の型を言語ごとのコードで確認できます。
- コンテンツセキュリティポリシー（CSP）とは？nonce方式の設定とXSS防御の実装判断を解説：XSSが残っても被害を抑えるブラウザ側の設定です。
- Railsの脆弱性21件：8.1.4.1・8.0.5.2の修正内容とActive Storageの回避策：SHIRASAGIが土台にするRails側の修正です。
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：ログイン権限を奪われた後の被害を抑える実装です。
- 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：独自改修したCMSをまとめて点検する際の進め方です。
