LIFF SDKにXSSの脆弱性、対象は2.20.0から2.31.0。LINEミニアプリを作る側が確認すべき版数が決まった

まず初めに

LIFFという名前は一般の利用者には馴染みが薄いが、LINEの中で動く小さなWebアプリ、つまり予約や会員証や注文画面の裏側は、かなりの割合でこの仕組みに乗っている。その土台の部品に「細工したURLを開かせればスクリプトが動く」という穴が開いていた。派手な侵害ニュースではない。けれども、直すべき版数がここまではっきり指定されている告知は、開発者にとって一番ありがたい種類の警告だと思う。

※個人の感想です

何が起きたのか

JVNは2026年10月22日、「JVNVU#91023667：LIFF SDKにクロスサイトスクリプティングの脆弱性」を公表しました。LIFF（LINE Front-end Framework）は、LINEのプラットフォーム上で動作するWebアプリを作るための仕組みで、その開発キットがLIFF SDKです。提供元はLINEヤフー株式会社です。

脆弱性の内容は、DOMベースのクロスサイトスクリプティング（XSS、CWE-79）です。DOMベースXSSとは、サーバー側ではなく、利用者のブラウザの中で動作するJavaScriptの処理の不備によって、攻撃者の用意したスクリプトが実行されてしまうタイプの脆弱性を指します。

深刻度の指標であるCVSSは、バージョン4.0の基本値が5.1、バージョン3.1の基本値が6.1と評価されています。開発元であるLINEのGitHubリポジトリでも、2026年10月20日にセキュリティアドバイザリ（GHSA-wppr-qmp4-w627）が公開されています。本件は、LINEヤフーがJPCERT/CCへ報告し、情報セキュリティ早期警戒パートナーシップの枠組みで調整のうえ公表されたものです。

影響の範囲——何が起きうるのか

JVNによれば、想定される影響は「当該製品を使用しているサイトにアクセスしたユーザのウェブブラウザ上で、任意のスクリプトを実行される可能性がある」というものです。

開発元のアドバイザリは、もう少し具体的に説明しています。利用者が細工されたURLを外部ブラウザで開くと、影響を受けるLIFFアプリのエンドポイントのオリジン上で任意のJavaScriptが実行される可能性があります。その結果、アプリの状態や実装によっては、次のようなことが起こりうるとされています。

• JavaScriptからアクセスできる認証トークンや、その他の機微な情報が読み取られる
• localStorageのデータや、JavaScriptから読めるCookieが読み取られる（HttpOnly属性の付いたCookieは直接読めません）
• 利用者のセッションを使った不正な操作が行われる（アプリ側の認可制御の範囲内）
• アプリの表示内容が改ざんされたり、フィッシングページへ誘導されたりする

裏を返せば、影響の大きさはアプリごとの実装に左右されます。トークンをJavaScriptから読める場所に置いていないか、セッションで実行できる操作の範囲が適切か、といった点検も、今回の更新と合わせて行う価値があります。なお、開発元は、開発者が更新する時間を確保するため、技術的な詳細は伏せているとしています。

対策——提供形態ごとに更新の仕方が違う

修正版はLIFF SDK 2.31.1です。ただし、LIFF SDKの組み込み方によって「自動で直るか」が変わります。開発元のアドバイザリに沿って整理します。

第一に、CDNのedge URL（https://static.line-scdn.net/liff/edge/2/sdk.js）を使っている場合です。このURLは更新されたSDKが自動で配信されるため、基本的には自動で修正版になります。ただし、実際に配信されているのが修正済みの版数かどうかは、デプロイ済みのアプリで確認するよう求められています。

第二に、CDNの版数を固定したURLを使っている場合です。URLを修正済みの版数に書き換える必要があります。固定したままでは、修正は届きません。

第三に、npmパッケージ（@line/liff）を使っている場合です。依存関係とロックファイルを更新し、アプリを再ビルドしてデプロイし直します。

第四に、SDKのコピーを自前で配置している場合です。そのコピーを修正済みのものに置き換えます。あわせて、アプリ側で管理しているキャッシュに影響を受ける版数のSDKやバンドルが残っている場合は、デプロイ時にキャッシュの更新も必要だとされています。

一般の利用者側に求められる操作はありません。ただし、LINE経由で届いたリンクを外部ブラウザで開く場面では、送信元が確かなものかを確認する、という通常の注意は引き続き有効です。不審なページで認証情報の入力を求められても、応じないでください。

私たちへの影響

この脆弱性は、利用者ではなく開発者・事業者が対応する種類のものです。LIFFアプリ（LINEミニアプリ）を提供している事業者は、自社のアプリがどの版数のSDKを、どの方法で読み込んでいるかを確認し、対象版数（2.20.0〜2.31.0）であれば2.31.1以降へ更新することが求められます。

確認のポイントは「自社が対象かどうかが、組み込み方法で決まる」ことです。edge URLの利用者は自動更新の対象ですが、「自動のはず」で終わらせず、実際に読み込まれている版数を本番環境で確認するところまでが作業です。逆に、版数固定やnpm、自前コピーを使っている場合は、誰かが手を動かさない限り永遠に対象版数のまま残ります。脆弱性対応で一番怖いのは、修正方法の難しさではなく、「うちは対象外だと思っていた」という思い込みの方です。

初心者が知っておくべきこと

Q. XSS（クロスサイトスクリプティング）とは何ですか。

A. Webサイトやアプリの不備を突いて、利用者のブラウザ上で攻撃者のスクリプト（小さなプログラム）を実行させる攻撃手法です。実行される場所が利用者自身のブラウザの中であるため、正規のサイトを開いているつもりでも、情報の窃取や表示の改ざんが起こりえます。

Q. 自分が使っているLINEミニアプリが危ないかどうか、利用者側で見分けられますか。

A. 利用者側でSDKの版数を確認する手段は基本的にありません。対応はアプリの提供側が行うものです。利用者側でできるのは、LINEで届いた不審なリンクを安易に開かない、リンク先で認証情報を求められても入力しない、といった通常の注意です。

Q. CVSS 5.1や6.1という数字は、どのくらい深刻なのですか。

A. CVSSは脆弱性の深刻度を0から10で表す共通指標で、一般的には7以上が「重要」寄りの扱いを受けます。今回の値は中程度の範囲ですが、LIFFが多くのサービスで使われる土台の部品であること、対策（版数の更新）が明確であることを考えると、数字の大きさだけで後回しにする理由にはなりません。

IT Postの見方——「自動で直るはず」を本番で確かめるまでが対応だった

IT Postでは、この件の要点は脆弱性そのものの珍しさではなく、「修正の届き方が組み込み方法で4通りに分かれる」点だと考えます。edge URLの自動更新は便利だが、それゆえに「確認しなくても直っている」という空気を作りやすい。アドバイザリがわざわざ「デプロイ済みのアプリが修正版を読み込んでいるか確認せよ」と書き添えたのは、その空気への釘です。自動化は確認を不要にするのではなく、確認の対象を「更新したか」から「本当に行き渡ったか」へ移すだけだ、という当たり前を思い出させます。

もう一つ、公表の進め方も記録しておく価値があります。開発元がJPCERT/CCへ報告し、調整のうえで修正版の公開と同時に告知し、技術詳細は更新の時間を確保するために伏せる。これは脆弱性公表の教科書どおりの手順で、騒ぎにならなかったのは手順が機能した証拠でもあります。地味な告知ほど、実は一番うまくいっている。

※個人の感想です

今後どうなりそうか

開発元は技術的な詳細を伏せていますが、時間が経てば公開される可能性があります。詳細が出てから対応するのでは遅く、対象版数を使っている事業者は、詳細の公開を待たずに2.31.1以降への更新と本番確認を進めることが推奨されます。

IT Postでは、本件に関する続報（詳細の公開や、悪用の確認など）が出た場合は取り上げます。LIFFアプリを提供している事業者は、まず自社の読み込み方法と版数の確認から始めてください。