LINE公式アカウントの裏側で起きていたのは、アプリではなく「インターネットの基盤」に潜む脆弱性でした。
ビジネスチャットとCDN、バグバウンティが一本の線でつながった今回の事案は、これからのサービス運用にどんな問いを突きつけているのでしょうか。
これは、LINEに限った話ではありません。同じような条件がそろえば、あらゆるHTTPを使うアプリケーションが標的となりえます。
2025年12月9日、LY Corporationは企業・店舗向けサービス「LINE公式アカウント」において、一部情報の誤表示によりユーザー情報および企業・店舗情報が漏えいした可能性を公表しました。
原因は、外部CDNサービスとして利用しているAkamaiの仕様と同社のデータ処理方式の違いにより、特定の条件下でHTTPリクエストが誤って処理される脆弱性（CVE-2025-66373）が存在していたためです。
対象となったのは「LINE公式アカウント」のチャット機能「LINEチャット」と管理画面で、2025年9月19日、9月24日、9月25日の限定された時間帯に同一の通信経路を利用していたユーザーや企業の情報が誤表示された可能性があります。漏えいし得た情報には内部識別子やユーザーネーム、プロフィール画像、管理企業情報、管理者プロフィール情報、「LINEチャット」で送受信されたメッセージなどが含まれ、発生確率は0.001％以下とされています。
本件は「LINE Security Bug Bounty Program」に参加する検証者の報告をきっかけに発見され、LINE側とAkamai側での止血対応と修正を経て、脆弱性と事案の公表に至りました。現時点で不正利用などの二次被害は確認されておらず、LY Corporationは再発防止策と検証体制の見直しを進めています。
From: 
「LINE公式アカウント」誤表示による情報漏えいのお知らせとお詫び
【編集部解説】
⚠️最近、LINEには複数の問題が報告されています。これは、LINE公式アカウントに関するものです。
LINEのE2EE（Letter Sealing v2）の脆弱性についてはこちら
→ LINE「Letter Sealing v2」脆弱性｜innovaTopia編集部が実証に成功、私たちはどうするべきか
今回の事案は、「LINE公式アカウント」という企業・店舗とユーザーをつなぐ接点に、アプリ本体ではなくCDNレイヤーの不具合が波及したケースです。AkamaiのエッジサーバにおけるHTTPリクエストスマグリング脆弱性CVE-2025-66373と、LY側のデータ処理方式の違いが組み合わさることで、特定条件下でレスポンスが“混線”し、他ユーザーや他企業の情報が誤って表示される状態が生まれていました。
HTTPリクエストスマグリングという「見えない攻撃面」
HTTPリクエストスマグリングは、フロント（CDNやWAF）とバックエンド（アプリケーションサーバ）が同じリクエストを微妙に異なるルールで解釈してしまうことを突く攻撃手法です。今回問題となったのは「Invalid Chunked Body Size」、つまりチャンクド転送エンコードのボディ長の扱いに起因するもので、エッジ側とオリジン側で解釈がズレると本来別々であるべきリクエスト・レスポンスが入り交じる可能性があります。
「限定的な条件」の裏にある構造的リスク
LYの公表では、影響が出るのは検証が行われた時間帯に、同じ通信経路で対象サービスを利用していた場合に限られ、発生確率は0.001％以下と説明されています。数値としては極めて低い水準ですが、「LINEチャット」のメッセージ内容が範囲に含まれる以上、問い合わせやサポートの文脈で扱われるセンシティブな情報が、想定外の相手に届くリスクがあったという点は軽視できません。
Bug Bountyが機能した事例と、そのジレンマ
本件は、LINE Security Bug Bounty Programに参加する検証者からの報告によって発見され、ゼロデイ攻撃として大規模悪用される前に修正が進んだという意味では、バグバウンティの「良い面」が表れた事例でもあります。一方で、検証行為の過程で他ユーザーのデータが実際に表示される状態が発生したことから、LINEは新規報告の受付を一時停止し、検証体制とルールの見直しに踏み込んでおり、「守りのための検証」が新たなリスクを生み得るジレンマも浮かび上がりました。
重要なのは、「自分たちのサービスも同じ構造の上に乗っているかもしれない」という認識です。公式アカウントやチャット、CDN、Bug Bountyといった要素は、もはや一部の巨大プラットフォームだけの話ではなく、あらゆるデジタルプロダクトが関わる“前提インフラ”になりつつあります。
企業が今、問い直すべきポイント
今回の事案は、単に「LINEの不具合」として消費するのではなく、読者の組織側でも次のような問いを投げかける材料になり得ます。自社サービスはどのレイヤーまで外部事業者に依存しているのか、CDNやSaaSの脆弱性情報をどのようなフローでキャッチアップしているのか、Bug Bountyや外部研究者との関係性をどう設計するのか、といった視点が、これからの「信頼できるデジタルサービス」を育てるうえで欠かせないと感じます。
技術的詳細
HTTP/1.1には、メッセージ本文（Body）がどこで区切れるかを表す方式が主に2通りあります。
- Content-Length ヘッダー: 予めBodyのバイト長をヘッダで直接指定します。
- Transfer-Encoding ヘッダー: “chunked” を指定することで、長さを最初に決めずにストリーミングすることができます。
よくある問題は、この2つのヘッダーが同時に使われたときです。この両方のヘッダーを同時に使用することは仕様違反です。ところが、実際のサーバーの実装においては、この両方のヘッダーが指定されたときに、ものによって異なる挙動をします。
最新のHTTP/1.1の仕様であるRFC 9112（以下英文引用）においては、この2つのヘッダーを同時に検出したら攻撃とみなして直ちにエラーを返すべきだとされています。しかし、実際の実装が規格通りになっていないことがあるのです。
If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 11.2) or response splitting (Section 11.1) and ought to be handled as an error. An intermediary that chooses to forward the message MUST first remove the received Content-Length field and process the Transfer-Encoding (as described below) prior to forwarding the message downstream.
RFC 9112 §6.3
Chunkedエンコーディングとは
要するに、HTTPメッセージ本文をたくさんのチャンク（まとまり）に分割し、順番に送信する仕組みです。このとき、16進数の<長さ>、<CR><LF>、チャンクの中身（<長さ>バイト）、<CR><LF>というのがひとつのまとまりになっていて、これをつなぎ合わせることで、本文 (Body) が完成します。本文の終わりでは、<長さ>=0のチャンクを送信します。
今回の脆弱性では、Akamai CDNサーバーにおいて、chunked エンコーディングにおける無効な長さが指定された場合の解釈が不正な処理になっていました。LINEサーバー側での処理の仕組みと合わさり、これは攻撃可能となったのです。
HTTP/1.1に代わるHTTP/2やHTTP/3・QUICはこの脆弱性がなく、現実に広く使われていますが、HTTP/1.1はLB（ロードバランサ）やリバースプロキシの裏のバックエンドで広く使われているほか、HTTP/2やHTTP/3をサポートしているサーバーでもHTTP/1.1はサポートされていることが多いので、攻撃者はこれを利用することができます。
この節は、編集部セキュリティエンジニアである「ゆか」が担当しました。
【用語解説】
HTTPリクエストスマグリング
複数の機器がHTTPリクエストを異なるルールで解釈することを悪用し、本来想定されていない形でリクエストを紛れ込ませる攻撃手法の総称。
ゼロデイ攻撃
修正プログラムや対策が公開される前の脆弱性を狙う攻撃のことで、開発元にとって対処の猶予がない状態を指す。
CVE
「Common Vulnerabilities and Exposures」の略称で、既知の脆弱性に一意のIDを付与して整理・共有するための仕組み。
CDN（コンテンツ配信ネットワーク）
世界各地のエッジサーバにコンテンツをキャッシュし、ユーザーの近くから配信することでWebやAPIの高速化と可用性向上を実現するインフラサービス。
Bug Bounty Program（バグ報奨金制度）
セキュリティ研究者などが脆弱性を報告した際、組織側がその貢献に対して報奨金などを支払う制度であり、大規模クラウドやSaaSで広く採用されている。
【参考リンク】
LY Corporation（LINEヤフー株式会社）（外部）
LINEやYahoo! JAPANなどを運営するLY Corporationの公式サイトで、ニュースやプライバシー・セキュリティ情報も掲載されている。
LINE Security Bug Bounty Program（外部）
LINE関連サービスの脆弱性を対象としたバグ報奨金プログラムの公式サイトで、対象範囲やルール、報奨内容が説明されている。
CVE-2025-66373（外部）
AkamaiのHTTP Request Smuggling脆弱性に関する公式CVEレコードで、技術的概要や深刻度、影響範囲が整理されている。
Akamai Technologies（外部）
グローバルにCDNやセキュリティサービス、エッジコンピューティング基盤を提供する企業の公式サイトである。
【参考記事】
Akamai Patches HTTP Request Smuggling Vulnerability in Edge Servers（外部）
AkamaiのエッジサーバにおけるHTTPリクエストスマグリング脆弱性CVE-2025-66373の技術概要と修正タイムライン、影響範囲を解説する記事である。
CVE-2025-66373 – Exploits & Severity（外部）
CVE-2025-66373の深刻度や悪用シナリオ、既知のPoCなどを整理し、Akamai利用サービスにおけるリスク評価をまとめた技術者向けリソースである。
CVE-2025-66373 Security Vulnerability & Exploit Details（外部）
HTTPリクエストのチャンクドボディサイズ処理に起因する問題として、CVE-2025-66373の原因と攻撃パターンを詳説する解説記事である。
Akamai Patches HTTP Request Smuggling Vulnerability in Edge …（外部）
Akamaiが脆弱性公表からパッチ適用、顧客通知までをどのように行ったかを、インシデントレスポンスの観点から整理した記事である。
「LINE公式アカウント」で情報漏えい 米Akamai社のCDNの …（外部）
LINE公式アカウントでの情報漏えい事案について、国内向けに概要や対象期間、漏えい可能なデータ種別を整理した記事である。
LINEの公式アカウントで情報漏洩-繰り返される個人 …（外部）
LINE公式アカウント関連の過去事例も含め、今回の誤表示型漏えいを国内事業者のセキュリティ運用やリスクマネジメントの観点から論じた記事である。
List of Recent Data Breaches in 2025 – Bright Defense（外部）
2025年に発生した複数のデータ侵害事例を一覧化し、その一つとしてLINE公式アカウントの事案に触れつつ、被害規模や攻撃ベクトルを比較している。
【編集部後記】
日々のやりとりを支える「LINE公式アカウント」の裏側で、どんなインフラとリスクが動いているのか、今回の事案を通して少し輪郭が見えてきたように感じています。もし自社や所属先で公式アカウントや外部CDNを利用しているなら、「どのレイヤーで何が起きうるのか？」を一度チームで話題にしてみるのも良いかもしれません。
技術のディテールをすべて理解していなくても、「どんな前提でサービスを信頼しているのか」を言語化するだけで、次の一手が少し見えやすくなると感じています。
LINEに関しては、公式アカウントだけではなく、以下の通常のメッセージのやりとりにおける脆弱性も発表されています。LINE社はセキュリティモデルの見直しを行うとしていて、今後の動きが注目されます。
