--- title: "LIFF SDK 脆弱性：CVE-2026-112148の影響確認と2.31.1への更新手順" url: "https://www.issoh.co.jp/tech/details/18999/" published: 2026-10-27 updated: 2026-10-27 categories: ["セキュリティ"] publisher: "株式会社一創" --- # LIFF SDK 脆弱性：CVE-2026-112148の影響確認と2.31.1への更新手順 LINEのWebアプリ基盤LIFFのSDK（npmの@line/liff）に、DOMベースのクロスサイトスクリプティング（CVE-2026-112148）が見つかりました。影響は2.20.0〜2.31.0で、2.20.0の公開は2022年5月です。この4年あまりに作ったLIFFアプリの多くが対象に入ります。この記事では、脆弱性の中身、SDKの組み込み方ごとの確認方法、npm auditで検出されない理由と代わりのチェック、2026年11月24日頃の利用制限までに済ませる更新手順を整理しました。内容は2026年10月27日時点の公開情報にもとづきます。 ## まとめ：11月24日頃の利用制限までにLIFF SDKを2.31.1以上へ上げる 修正版は2.31.1で、最新は2.31.2です。CDNエッジパスで読み込んでいるアプリは自動で修正版に切り替わっていますが、固定パスやnpmで組み込んだアプリは、URLの書き換えか依存の更新と再デプロイをしない限り古い版のままです。LINEヤフーは2026年11月24日頃に2.20.0〜2.31.0の利用を制限する予定と告知しているので、放置すればセキュリティ上の問題に加えてアプリ自体が動かなくなるおそれもあります。 注意したいのは、npm auditやDependabotが現時点でこの勧告を拾わない点です。依存の自動点検に頼っている開発体制では、リポジトリを横断して版を数える作業が別に要ります。委託先が作ったLIFFアプリで組み込み方が分からない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で配信中のSDKの版とトークンの扱いをまとめて確かめると漏れが減ります。 ## CVE-2026-112148：外部ブラウザのURL起点のDOMベースXSS発生条件 まず、どんな条件で何が起きるのか、公表元の記載を整理します。 ### 細工したクエリパラメータ付きURLで任意のJavaScriptが動く条件 [GitHubのセキュリティ勧告GHSA-wppr-qmp4-w627](https://github.com/line/liff/security/advisories/GHSA-wppr-qmp4-w627)によると、利用者が細工したURLを外部ブラウザで開くと、LIFFアプリのエンドポイントのオリジンで任意のJavaScriptが実行されます。[LIFFのリリースノート](https://developers.line.biz/ja/docs/liff/release-notes/)は、v2.31.1の修正内容を「外部ブラウザで細工されたクエリパラメータを含むURLからLIFFアプリを開いた場合」の不具合と説明しています。 サーバーを経由せず、ブラウザの中でURLの値がページに流れ込んで起きる型を[OWASPはDOM Based XSS](https://owasp.org/www-community/attacks/DOM%5FBased%5FXSS)と呼びます。サーバー側のWAFやログに痕跡が残りにくい型です。どのAPIのどの処理で起きるかは、利用者が更新を終えるまで非公開とされています。XSS自体の仕組みは[XSSとCSRFの違いと実装レベルの対策](https://www.issoh.co.jp/tech/details/4109/)で解説しています。 ### CVSS v4.0で5.1、v3.1で6.1：数値が中程度でも急ぐ理由 [JVNVU#91023667](https://jvn.jp/vu/JVNVU91023667/index.html)が示す評価値は、CVSS v4.0が5.1、v3.1が6.1です。利用者がURLを開く操作が要る点（UI:A）と、影響が後続のシステム側で機密性・完全性とも「低」と置かれている点が、点数を押し下げています。v3.1の各項目の読み方は[CVSSv3のスコアの目安と計算式](https://www.issoh.co.jp/tech/details/5094/)で確認できます。 対応を判断する基準は、点数よりもLIFFアプリが扱う情報の中身です。勧告は想定される影響として、JavaScriptから読める認証トークンやlocalStorageの値の読み取り、利用者のセッションを使った操作、表示の改ざんやフィッシングへの誘導を挙げています。LIFFアプリは予約・会員証・ポイントなど本人に結びつく処理を持つことが多く、URLはトーク画面で簡単に回せます。 ### 修正版2.31.1の公開日と勧告公開日の3週間のずれと監視への影響 時系列には注意が要ります。npmの登録日時では2.31.1の公開は2026年9月30日で、リリースノートも同日に「速やかにアップデートしてください」と告知しました。CVEの採番と勧告の公開は10月20日、JVNの公表は10月22日です。[CVE.orgのレコード](https://www.cve.org/CVERecord?id=CVE-2026-112148)では、番号を割り当てたのはLY Corporation自身です。 9月末の告知は「セキュリティ上の影響が生じる可能性のある不具合」という書き方で、CVE番号が付いていませんでした。CVEやJVNの配信だけを監視している運用では、10月20日まで気づけなかった計算です。 ## 影響の確認手順：CDNパス・npm・自前配信ごとにLIFF SDKの版を調べる 判定の方法は、SDKの組み込み方で変わります。[LIFFアプリを開発する](https://developers.line.biz/ja/docs/liff/developing-liff-apps/)のページが示す方法は、CDNのパスを指定する方法とnpmパッケージを使う方法の2つです。 ### CDNエッジパスは自動更新、固定パスは版番号の書き換えが必要 CDNには、メジャーバージョンだけを含むエッジパス（edge/2/sdk.js）と、パッチバージョンまで指定する固定パス（edge/versions/2.31.0/sdk.js など）があります。エッジパスは常に最新に切り替わるため、今回も自動で配信されるのは修正版です。固定パスは、URLを書き換えない限り指定した版を使い続けます。 ``` # ソースとビルド成果物から、LIFF SDK を読み込む CDN パスを洗い出す grep -rnoE "static\.line-scdn\.net/liff/edge/[^\"' ]+" --include=*.html --include=*.js --include=*.ts --include=*.vue --include=*.tsx . # 配信中のページで実際に読み込んでいるパスを確かめる（URL は自社の LIFF エンドポイントに置き換える） curl -s "https://example.com/liff/" | grep -oE "liff/edge/[^\"']+" ``` 結果が「edge/2/sdk.js」ならエッジパスなので、残る作業はキャッシュの確認だけです。「versions/2.20.0」〜「versions/2.31.0」が出たら対象です。 ### npmアプリのnpm lsとliff.getVersion()による配信版の二重確認 npmで入れた場合は、ロックファイル上の版と、実際に配信されているバンドルの版を分けて見ます。ロックファイルを直してもビルドとデプロイをやり直さなければ、利用者の手元に届くのは古いバンドルだからです。 ``` # ロックファイル上の版（2.31.1 以上なら修正済み） npm ls @line/liff # 配信中のアプリで実行される版：ブラウザの開発者ツールのコンソールで実行 liff.getVersion() ``` [LIFF APIリファレンス](https://developers.line.biz/ja/reference/liff/)によると、liff.getVersion()はliff.init()の前でも呼べて、SDKの版を文字列で返します。本番のエンドポイントを開いてこの値が2.31.1以上なら、配信まで終わった状態です。SDKのファイルを自社サーバーへコピーして配っている場合は、そのファイルを修正版に置き換えたうえで同じ確認をします。 ### npm auditとDependabotで検出されない理由と非推奨の警告 2026年10月27日に確かめた範囲では、この勧告はLIFFのリポジトリに付いた勧告にとどまっています。GitHub Advisory Database全体のAPIでGHSA-wppr-qmp4-w627を引くと404で、npm auditが問い合わせる監査APIとOSVのAPIに@line/liff 2.31.0を渡しても結果は0件でした。同じ監査APIにaxios 0.21.0を渡すと勧告が返るので、問い合わせの方法の問題ではありません。[Dependabot](https://www.issoh.co.jp/tech/details/6796/)や[OSV-Scanner](https://www.issoh.co.jp/tech/details/12926/)で点検していても、今は警告が出ません。 手がかりになるのはnpmの非推奨表示です。2.20.0〜2.31.0の各版には「Update to LIFF v2.31.1 immediately」という非推奨の文言が付いていて、npm installのときに警告が出ます。ただし、この表示が付くのは@line/liffだけで、内部で使われる@liff/coreなどのパッケージの2.31.0には付いていません。判定は必ず@line/liffの版で行います。 ## 更新手順と再発防止：CIで旧版のLIFF SDKを止める設定 修正そのものは版を上げるだけで、リリースノートは「LIFFアプリの機能変更はありません」としています。手間がかかるのは、すべての配信経路に行き渡らせる部分です。 ### 固定パスとpackage.jsonを2.31.2へ上げてキャッシュまで入れ替える 固定パスはURLの版番号を書き換え、npmは依存とロックファイルを更新して作り直します。[LINEヤフーのセキュリティアドバイザリ](https://line.github.io/security-advisory-blog/CVE-2026-112148/)は、アプリ側のキャッシュに古いSDKやバンドルが残っている場合、デプロイの一部として入れ替えるよう求めています。 1. 固定パスの場合：edge/versions/2.31.0/sdk.js を edge/versions/2.31.2/sdk.js に書き換える 2. npmの場合：npm install @line/liff@2.31.2 を実行し、package-lock.jsonもコミットする 3. ビルドし直し、本番のLIFFエンドポイントへデプロイする 4. CDNやService Workerのキャッシュを消し、liff.getVersion()の値を本番で確かめる 2.31.2は10月7日の版で、LIFFブラウザでクエリパラメータ値の「?」を「&」に置き換えなくなる変更を含みます。URLのクエリをそのまま解釈している処理がある場合は、2.31.1で止めて動作を確かめてから2.31.2へ進めるのが無難です。 ### package-lock.jsonの版を検査してビルドを止めるNode.jsスクリプト 監査ツールが拾わない間は、CIで版を直接見て止めます。次のスクリプトはpackage-lock.json（lockfileVersion 2以降）を読み、@line/liffが2.31.1未満ならビルドを失敗させます。 ``` // scripts/check-liff-version.js（CI で npm ci の後に実行する） const lock = require("../package-lock.json"); const MIN = [2, 31, 1]; const found = Object.entries(lock.packages || {}) .filter(([path]) => path.endsWith("node_modules/@line/liff")) .map(([path, pkg]) => [path, pkg.version]); const isOld = (v) => { const p = v.split(".").map(Number); for (let i = 0; i < 3; i++) { if (p[i] !== MIN[i]) return p[i] < MIN[i]; } return false; }; const bad = found.filter(([, v]) => isOld(v)); bad.forEach(([path, v]) => console.error(`${path}: ${v} は CVE-2026-112148 の対象`)); process.exit(bad.length ? 1 : 0); ``` package.jsonのscriptsに “check:liff”: “node scripts/check-liff-version.js” を足し、CIの依存インストールの直後に呼べば、古い版へ戻すプルリクエストも止まります。GitHub Advisory Databaseに勧告が載り、npm auditが検出するようになったら、このスクリプトは外して構いません。 ## LIFFアプリ側の守り：トークンの置き場所とサーバーでの検証 SDKを直しても、別のXSSが入り込めば同じ被害が起きます。今回の勧告が挙げた影響に沿って、アプリ側の作りも見直しておきます。 ### localStorageに自前のセッションを置かずサーバーでIDトークンを検証 勧告は、注入されたスクリプトがlocalStorageやHttpOnlyでないCookieを読めると書いています。LIFFアプリが独自に発行したセッショントークンをlocalStorageに置いているなら、HttpOnly属性のCookieへ移すと、XSSが起きても読み取られる範囲が狭まります。 サーバーへ本人の情報を渡す方法も、併せて確認する対象です。[LIFFアプリおよびサーバーでユーザー情報を使用する](https://developers.line.biz/ja/docs/liff/using-user-profile/)は、liff.getProfile()で取ったプロフィールをそのままサーバーへ送らず、IDトークンかアクセストークンを送ってサーバーで検証するよう求めています。この検証の実装例は[LIFFで予約フォームを作るコード](https://www.issoh.co.jp/tech/details/18647/)に、クライアントが返すユーザーIDを信じる危険は[LINEミニアプリの危険性](https://www.issoh.co.jp/tech/details/16710/)にまとめています。 ### CSPで読み込めるスクリプトの出どころを絞る多層防御と設定の限界 [Content-Security-Policyヘッダー](https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Content-Security-Policy)でscript-srcを自社のドメインとLIFF SDKのCDNに限ると、外部のスクリプトを読み込ませる攻撃を防げます。ただしDOMベースXSSは、ページ内の既存コードが値を実行してしまう型なので、CSPだけで止まるとは限りません。’unsafe-inline’や’unsafe-eval’を許可している設定では効果が大きく下がります。SDKの更新を済ませたうえで重ねる対策と位置づけます。 ## 対応の優先順位：個人情報を扱うLIFFアプリから更新する判断基準 複数のLIFFアプリを抱えている場合の順番を、条件ごとに決めます。 ### 即日更新が要る構成と利用制限日までに回せる構成の個人情報による線引き 当日中に更新するのは、固定パスかnpmで2.20.0〜2.31.0を組み込み、会員情報・予約・決済・ポイントのような本人に結びつく処理をLIFFアプリの中で扱っているものです。外部ブラウザで開かれる導線（Webサイトのボタン、メール、QRコード）を持つアプリも同じ扱いにします。受信側の認可やトークン失効の考え方は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)と共通です。 キャンペーンの告知だけでログインもトークン取得もしないアプリは、11月24日頃の利用制限より前の定例更新に回して構いません。CDNエッジパスのアプリは、キャッシュの入れ替えとliff.getVersion()の確認だけで済みます。どのアプリがどの組み込み方かを即答できないなら、すべてを当日扱いにするのが安全です。 ### 委託先が作ったLIFFアプリで求める配信中の版と更新予定日の書面報告 LIFFアプリは制作会社や広告代理店に作ってもらい、納品後の保守契約がないまま動いている例が少なくありません。発注側で確かめられるのは、本番のエンドポイントを開いて取れるliff.getVersion()の値と、ページが読み込むCDNパスまでです。どちらも、ブラウザの開発者ツールがあれば数分で見られます。 委託先には、配信中の版、組み込み方、更新予定日の3点を書面で報告してもらいます。11月24日頃の利用制限までに改修の手当てが付かない場合や、複数の委託先にまたがって棚卸しが必要な場合は、[脆弱性診断の進め方と外注時の判断基準](https://www.issoh.co.jp/column/details/13101/)を参考に、第三者による点検を検討してください。 ## LIFF SDKの脆弱性CVE-2026-112148でよくある質問と回答 CVE-2026-112148への対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。 ### LINEアプリの中（LIFFブラウザ）だけで使っていれば影響はありませんか？ 勧告とリリースノートが示す発生条件は、細工したURLを外部ブラウザで開いた場合です。ただし、同じLIFFアプリのURLは外部ブラウザでも開けるので、攻撃者がURLを外部ブラウザで開かせる誘導を防ぐ手段はアプリ側にありません。LIFFブラウザでの利用を想定したアプリでも、更新は必要です。 ### 11月24日頃の利用制限で、古い版のアプリはどうなりますか？ リリースノートの10月20日の追記は「旧バージョン（v2.20.0〜v2.31.0）の利用制限を実施する予定」とするだけで、制限の具体的な中身は2026年10月27日時点で公表されていません。LIFFの機能が使えなくなる可能性を前提に、制限日より前に更新を終えておくのが確実です。 ### 2.19以前の古いLIFF SDKを使い続けても問題ありませんか？ 今回の影響範囲は2.20.0以降なので、2.19以前はCVE-2026-112148の対象外です。ただし2.19.0の公開は2022年3月で、その後の修正や仕様変更を4年以上取り込んでいない状態です。今回の更新に合わせて2.31.2まで上げることを勧めます。 ### LIFFアプリのアクセストークンが盗まれた場合、何をすればよいですか？ LIFF APIリファレンスによると、liff.getAccessToken()で取れるアクセストークンの有効期間は発行から12時間です。サーバー側では、[LINEログインAPIリファレンス](https://developers.line.biz/ja/reference/line-login/)のアクセストークン取り消しで失効させられます。自社のセッションも併せて失効させ、アクセスログで同じ利用者の不審な操作を確かめてください。 ### この脆弱性で個人情報が漏れた場合、報告は必要ですか？ 勧告は、JavaScriptから読めるトークンやアプリのデータが漏れるおそれがあるとしています。LIFFアプリが扱う会員情報などの個人データについて漏えいのおそれがあると判断した場合は、個人情報保護委員会への報告の対象になりうるということです。判断の基準と期限は[個人情報保護委員会への報告義務と速報3〜5日の実務](https://www.issoh.co.jp/column/details/17840/)で確認できます。LIFFの仕組みそのものは[LIFFとは：LINEアプリ内で動くWebアプリの仕組み](https://www.issoh.co.jp/tech/details/3396/)で解説しています。 ## 関連記事 - [LINEミニアプリとは？未認証と認証済みの違い・LIFFとの使い分け・審査と開発費用【2026年版】](https://www.issoh.co.jp/column/details/15161/)：LIFFアプリとLINEミニアプリの選び分けを発注側の視点で整理しています。 - [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：勧告の公表から修正までの流れの基礎です。 - [CVE（共通脆弱性識別子）とは？番号の読み方・CVSS/CWE/NVDとの違いと調べ方](https://www.issoh.co.jp/tech/details/5092/)：GHSA番号・JVN番号とCVE番号の関係を整理しています。 --- 出典: [LIFF SDK 脆弱性：CVE-2026-112148の影響確認と2.31.1への更新手順]()（株式会社一創）