LIFF SDKのXSSを公表｜11月の旧版利用制限前にミニアプリを更新する

LINEヤフーは2026年10月20日、LIFF SDKのDOMベースのクロスサイトスクリプティング（XSS）に関する情報を公開しました。対象は2.20.0から2.31.0で、修正は2.31.1に含まれます。JVNも10月22日に注意喚起を公開しています。LINEミニアプリやLIFFアプリの運営者は、自分のページが実際に読み込んでいるSDKを確認してください。

今回の対応は、脆弱性を修正するだけでなく、サービスの継続にも関わります。LINE Developersの公式ニュース一覧には、11月24日頃に対象の旧版の利用制限を実施する予定が示されています。予定時期を修正作業の先送り期限と捉えず、先に更新と動作確認を進める必要があります。

本記事は10月22日に確認した一次資料に基づくニュースです。修正版のリリースは9月30日、脆弱性に関する情報の公開は10月20日、JVNの公開は10月22日と、日付を分けて整理します。以下の配備や試験の進め方は本サイトの提案です。

何が公表され何がまだ予定なのか

LINEヤフーのアドバイザリは、CVE-2026-112148として脆弱性を説明しています。利用者が細工されたURLを外部ブラウザーで開くと、影響するLIFFアプリのエンドポイントのオリジンで、任意のJavaScriptが実行される可能性があります。

ここで重要なのは、LINEアプリの中だけを動作確認して完了としないことです。公式の説明が示す条件には外部ブラウザーが含まれます。LIFFアプリへの入口や、外部ブラウザーで使う導線を持つサービスは、その利用方法も試験対象にします。

一方、11月24日頃の利用制限は、10月22日時点では将来の予定です。本記事は制限が既に実施されたと報じるものではありません。具体的な制限の内容や変更については、10月20日付の公式告知で継続して確認してください。確認できていない画面表示や停止の方式を推測することは避けます。

トークンや操作への影響はアプリの実装にも左右される

公式GitHubアドバイザリは、JavaScriptからアクセスできる認証トークンやアプリケーションのデータ、利用者のセッションによる操作などへの影響を挙げています。画面の改変やフィッシングページへの誘導につながる可能性も説明されています。

ただし、トークンの漏えいは、対象のトークンが存在し、実行されたスクリプトからアクセスできるかに依存します。HttpOnlyが付いたCookieをJavaScriptから直接読み取れるという説明ではありません。認可の制御など、アプリ側の設計によっても実際に可能な操作は変わります。

このため、「利用者全員の情報が漏れた」「LINE全体が侵害された」といった断定はできません。確認した一次資料から、今回の脆弱性による実環境での悪用や自社の被害を認定することもできません。本サイトでは、脆弱性の存在、起こり得る影響、実際の被害の有無を分けて扱います。

JVNはCVSS v4.0を5.1、v3.1を6.1と記載しています。版の違うスコアを混ぜて比較せず、利用者の操作が条件に含まれることも含めて確認してください。中程度の評価であっても、更新せずに放置する理由にはなりません。

修正版は9月30日に公開済み

LIFFの公式リリースノートでは、2.31.1の公開日は9月30日です。この時点で2.20.0から2.31.0は、セキュリティ上の影響が生じる可能性がある不具合を理由に非推奨となりました。その後、10月20日に脆弱性の概要と旧版の利用制限予定が告知されています。

10月22日の確認時点で、リリースノートの最新は10月7日公開の2.31.2です。したがって、脆弱性の修正境界である2.31.1と、現在選べるより新しい版を区別して更新計画を立てます。古い告知を見て、修正版がまだ公開されていないと誤解しないことが大切です。

本サイトの提案は、採用する版と、その版に含まれる変更点を一つのリリースとして確認することです。セキュリティ修正が含まれている事実と、自分のアプリの動作に問題がない事実は別です。更新の必要性を認めたうえで、変更点に対応する試験を行います。

CDNかnpmかで残る作業が違う

公式アドバイザリは、SDKの取り込み方ごとに対応を分けています。ソースコードの一か所を更新しても、別のページが固定版を読んでいたり、過去のビルド成果物が残っていたりする可能性があるため、配布経路を先に把握してください。

取り込み方	公式に示された対応	配備後に確認したいこと
CDNのedge URL	自動更新されるが修正版の読み込みを確認	実際の取得内容とキャッシュ
CDNの固定版URL	修正版を指すURLへ変更	本番HTMLやテンプレートの参照先
npmの@line/liff	依存関係やロックファイルを更新し再ビルド・配備	配布されたバンドルと稼働環境
SDKのコピーを自己配信	コピーを修正版へ置き換える	配信ディレクトリーと古いコピー

表の最後の列は本サイトが提案する確認項目です。公式は、アプリが管理するキャッシュに古いSDKやバンドルが残る場合、配備に合わせてそれらも更新するよう求めています。リポジトリー上の依存関係だけで、利用者へ届く内容まで更新されたと判断しないでください。

特に制作会社への委託や複数のミニアプリを持つ運用では、一つのアプリの修正を全体へ一般化しないようにします。同じブランドでも、アプリごとに配布方式や保守担当が異なる場合があります。対象一覧を作り、個々の更新状況を記録する方法が役立ちます。

edge URLの自動更新でも実機で確かめる

公式が挙げるedge URLは https://static.line-scdn.net/liff/edge/2/sdk.js です。この取り込み方ではSDKの更新が自動で届きますが、公式の説明も、配備されたアプリが修正版を読み込むことを確認するよう求めています。

本サイトの提案は、HTMLの参照先、ブラウザーのネットワーク記録、アプリのキャッシュ制御を対応付けて確認することです。別の固定版が混在していないか、複数のページで別々に読み込んでいないかも点検します。自動更新のURLを一つ見つけただけで、すべての配布経路が対象だとは限りません。

通常のブラウザーと、以前から使っているブラウザーの両方を確認すると、新規利用と更新済み利用の違いを調べやすくなります。サービスワーカーなどで独自のキャッシュを使う構成では、その更新条件も検証します。これは本サイトの一般的な配備確認の提案で、すべてのLIFFアプリが同じキャッシュを使うという意味ではありません。

npmの更新はビルドと配備までを一つにする

npmを使う場合、公式は依存関係と必要なロックファイルの更新に加え、アプリの再ビルドと更新済みバンドルの配備を求めています。パッケージ管理ファイルだけを変更して、本番に古い成果物を残したままにしないでください。

本サイトの提案として、今回採用するSDKの版、コミット、ビルド成果物、配備先、確認日時を結び付けて記録します。開発環境で修正版が選ばれていても、本番のビルドが別のロックファイルを使うなどの不一致がないかを確かめます。

また、修正のために依存関係全体を無関係に大きく更新すると、問題の切り分けが難しくなる場合があります。必要な修正を取り込む変更と、それ以外の改修を整理し、レビューできる範囲に保つことを提案します。ただし、古い版を維持するためにセキュリティ修正を先送りする判断とは分けてください。

利用者の導線と重要操作を試験する

更新後は、SDKの読み込み成功だけでなく、サービスが提供する主要な導線を確認します。以下は本サイトの試験案であり、公式がすべてのアプリへ同じ機能を実装するよう求めているわけではありません。

• LINE内と外部ブラウザーからの起動を分けて確認する
• 実装しているログインや初期化の成功・失敗を確認する
• 問い合わせ、予約、購入など自社の重要操作をテスト用データで確かめる
• 以前のHTMLやキャッシュが残る利用環境で更新が届くかを調べる
• 読み込みに失敗した場合に操作の完了を誤表示しないかを確認する

細工した攻撃用URLを一般の利用者へ送る必要はありません。まずは管理下の検証環境で正常系と失敗時の挙動を確かめ、公式が公開する情報に基づいて対応します。アドバイザリは開発者へ更新時間を確保するため技術的な詳細を控えているとしており、本記事も未公開の攻撃手順を推測しません。

戻す先も修正版にしておく

配備後に別の不具合が見つかることに備えて、ロールバックの準備は必要です。ただし、今回の影響を受ける古いSDKへ戻すことを標準の復旧手順にすると、脆弱性も再導入してしまいます。

本サイトの提案は、修正版SDKを含む既知の正常な成果物を確保し、機能の一部を停止する方法も含めて復旧を設計することです。古い成果物の保管が必要な場合でも、それを誤って公開しない運用と区別します。SDKのコピーが複数ある場合は、退避したものが配信対象に残らないかも点検してください。

外部スクリプトの固定や更新の扱いは、SRIと外部スクリプトの更新運用の解説でも整理しています。リンク先は一般的な恒久対策です。SRIは承認した内容との一致を確かめる仕組みであり、脆弱性があるSDKを固定しても今回の修正の代わりにはなりません。