AWS Amplifyの地図表示に保存型XSS 4.0.3以降への更新と派生コードの点検

AWSは2026年11月3日、地図連携ライブラリmaplibre-gl-js-amplifyの保存型クロスサイトスクリプティング（XSS）、CVE-2026-121652を公表した。4.0.2以前を組み込んだWebアプリでは、保存された位置情報やジオフェンス識別子を表示すると、別の利用者のブラウザーで意図しないスクリプトが動くおそれがある。対象ライブラリを使う開発・運用担当者は、4.0.3以降への更新とフロントエンドの再配備を優先したい。

これはAmazon Location Service全体の侵害を伝える告知ではなく、利用アプリが取り込むオープンソースライブラリの描画処理に関する修正情報だ。AWS Security Bulletin 2026-167-AWSは、問題を完全に解消する回避策はなく、更新が必要としている。入力の検証やContent Security Policy（CSP）は多層防御として示されているが、修正版への置き換えの代わりにはならない。

保存した地図データが別の利用者の画面で解釈される

問題になるのは、文字列として扱うべき値をHTMLとしてDOMへ挿入していた経路である。AWS Amplifyのセキュリティ勧告 GHSA-34v3-xxqp-g5g9は、GeoJSONのtitle、address、place_nameと、ジオフェンスのgeofenceIdを挙げる。地図マーカーのポップアップだけでなく、ジオフェンス一覧や削除確認の表示も点検対象になる。

攻撃は、細工された値が保存され、それを被害者が対象の画面で表示する流れを取る。例えばマーカーをクリックした利用者のアプリ内コンテキストでスクリプトが動く可能性がある。公式CVEレコードと勧告のCVSS 3.1は5.4で、攻撃者の低い権限と利用者の操作を条件に含む。認証不要のサーバー側コード実行と同じ条件ではないが、管理者が共有データを閲覧する画面も含めて影響を判断する必要がある。

公式資料は、認証済みセッションでの影響例としてセッションの乗っ取りやデータ流出を挙げている。これは起こり得る影響の説明であり、特定企業の侵害や実被害を確認した報告ではない。今回読んだ開発元資料には実環境での悪用確認の記載はなく、悪用がないことを保証するものでもない。自社アプリで実行可能な操作や表示データの範囲に応じて優先度を決めたい。

公表日と修正版の公開日は分けて読む

AWS告知の公開時刻は11月3日10時30分PSTで、日本時間では11月4日3時30分に当たる。一方、maplibre-gl-js-amplify v4.0.3リリースは4.0.3のリリース日を2026年6月24日としており、XSS修正を変更点に含む。11月に修正版が初めて出たと読み替えてはいけない。以前に更新したアプリでも、実際の配布物が修正版を含むかを確認すればよい。

影響範囲は4.0.2以前、修正を含む最初の版は4.0.3である。ここで4.0.3を「最新版」とは呼ばない。採用する版は公式リリースと依存関係の互換性を確認して選ぶ。今回の対処のために、検証せず別のメジャー版へ移行する必要があると決めつけることも避けたい。更新先が修正を含むことと、アプリがその版で動くことを別々に確認する。

依存宣言だけでなく配布されるJavaScriptを確認する

以下は本サイトが提案する影響調査と更新の進め方であり、実際のアプリで動作検証した結果ではない。まずリポジトリ全体からパッケージ名を検索し、直接依存、社内共通コンポーネント、コピーしたソース、静的HTMLから読み込む配布ファイルを洗い出す。aws-amplifyやMapLibre GL JSだけの版を見て完了にせず、問題のmaplibre-gl-js-amplifyそのものを追う。

npm ls maplibre-gl-js-amplify --all
rg -n 'maplibre-gl-js-amplify|popupRender|AmplifyGeofenceControl' .

npm lsはnpmプロジェクトで解決された依存ツリーを見る例で、ファイル検索は独自実装の候補を拾う補助だ。別のパッケージ管理方式を使う場合は、そのロックファイルと依存ツリーを確認する。コマンドがパッケージを表示しなくても、手動コピーや別リポジトリで作られたバンドルまで存在しないとは判断できない。検索結果にはビルド済みファイルやテストも含まれるため、実際の呼び出し元まで辿る。

更新後は、依存宣言、ロックファイル、CIで解決した版、配布したビルドを対応付ける。ローカルで更新しても、古いロックファイルからCIが再構築したり、別の静的配布ファイルを参照したままだったりすれば、利用者に届くコードは変わらない。ブラウザーの開発者ツールで読み込まれたJavaScriptのURLとビルド識別子を確認し、必要に応じてCDNやService Workerの更新手順も実施する。

作業記録には、アプリ名、利用経路、更新前後の版、コミット、ビルドID、配備先、確認した日時を残す。同じ地図部品を複数サイトで共有しているなら、共通パッケージを直しただけで全利用先へ反映されたとせず、各サイトの配備を別に確認する。旧版へ戻すロールバックが脆弱性を再導入する点も、障害対応の担当者へ引き継いでおきたい。

派生コードとカスタムポップアップは別にレビューする

AWSはforkや派生コードにも修正を取り込むよう求めている。開発元のXSS修正コミット 5804fbcでは、HTML特殊文字をエスケープする処理を加え、ポップアップやジオフェンス側の挿入箇所へ適用している。コピー済みの旧実装は依存パッケージの更新だけでは置き換わらないため、該当する描画処理を差分と照合する必要がある。

さらにmaplibre-gl-js-amplify APIリファレンスでは、drawPointsのunclusteredOptions.popupRenderで既定の描画関数を上書きできる。独自関数はGeoJSON featureを受け取り、HTML文字列を返す構成である。したがって、標準ライブラリを更新したことだけを根拠に、独自ポップアップも安全になったとは判断できない。テンプレートのどの位置へ外部データを挿入するか、HTMLとして解釈する必要があるかを確認する。

単に名称や住所を表示する部分なら、文字列をテキストとして扱う設計を優先する。装飾を含むHTMLを意図的に許す部分は、許容する要素や属性を決めた処理を別に設計する。開発元のescapeHtmlという関数名だけを真似して、URL、スクリプト、CSSなど異なる文脈へ万能に流用しない。今回の修正対象と、自社が追加したHTML出力のレビューを区別することが重要だ。

更新後は表示経路ごとに安全な回帰確認を行う

検証は本番の共有データへ攻撃用スクリプトを書き込む方法ではなく、分離したテスト環境と専用アカウントで行う。例えば名称に山括弧、引用符、アンパサンドを含む無害な文字列を使い、文字として表示されること、想定外の要素や属性がDOMに増えないことを確認する。画面上で目立つ異常がないだけでなく、DOMとコンソールも合わせて見る。

確認する経路は、通常のマーカーポップアップ、独自popupRender、ジオフェンス一覧、削除確認など、自社が有効にしている機能に分ける。値の保存者と閲覧者を別アカウントにし、保存されたデータを後から表示するケースも含める。同じ文字列が検索結果や管理画面へ流れるなら、その表示経路も調べる。これらは自社アプリの検証提案であり、全画面がこのCVEの影響を受けると断定するものではない。

開発元の修正コミットにはXSSを防ぐテストも含まれるが、ライブラリのテストが自社のカスタム実装まで保証するわけではない。正常な住所や日本語名称、空値、長い名称も回帰確認へ入れ、修正で表示が二重エスケープされたり、必要な項目が消えたりしないかを見る。期待するテキストと実際のDOMを組み合わせて検証すると、単なる見た目の比較より変更の意味を確認しやすい。

更新を待つ間の防御と過去データの扱い

直ちに更新できない場合、AWSが挙げる入力検証・サニタイズと制限的なCSPを多層防御として検討する。ただし、既に保存されたレコードは、新規入力だけの検証では変わらない。利用者が変更できる名称、住所、識別子の保存先と表示先を整理し、不審な値があれば証跡を保全したうえで調査する。文字に山括弧があるだけで悪意と決めつけたり、履歴を一括削除したりしない。

本サイトとしては、保存機能の利用権限や公開範囲の一時的な縮小、対象の表示機能の停止も、業務影響を見ながら検討することを提案する。ただし、特定のスイッチを切れば全経路を塞げると公式が保証したわけではない。CSPも既存スクリプトとの互換性を確認して導入し、設定しただけで修正済みと記録しない。復旧の完了条件は、修正版の配布と必要な表示経路の確認まで含めて定義したい。

過去の被害が疑われる場合は、位置情報やジオフェンスの作成・更新履歴、閲覧時のアプリログなど、実際に取得している記録を基に調べる。CVE公表日から初めて攻撃可能になったとは限らず、一方で旧版利用だけを侵害の証拠にもできない。確認済みの事実と調査中の範囲を分けて扱い、必要なら通常のインシデント対応手順へ引き継ぐ。

対応を終えるための確認事項

まずmaplibre-gl-js-amplifyの有無と実際に配布された版を特定し、4.0.2以前なら互換性を確認した修正版へ更新する。次にfork、コピーした描画処理、独自popupRenderを点検し、再ビルドしたJavaScriptが利用者へ届いたことを確かめる。最後に保存済みデータを表示する経路をテストし、暫定防御と未解決の範囲を記録する。AWS側の更新を待つだけでは終わらない、利用アプリの出力処理の問題として対応したい。