
LINE官方帳號背後隱藏的漏洞並非存在於應用程式本身,而是存在於「網路基礎設施」中。
這起事件將商業聊天、CDN 和漏洞賞金聯繫在一起,引發了人們對未來服務營運的一些疑問。
這不只限於LINE。如果滿足類似條件,任何使用HTTP的應用程式都可能成為攻擊目標。
2025年12月9日,LY Corporation宣布,由於其面向企業和商店的LINE官方帳號服務上某些資訊的顯示不正確,用戶資訊和公司/商店資訊可能已被洩露。
造成這種情況的原因是存在一個漏洞(CVE-2025-66373),由於用作外部 CDN 服務的 Akamai 的規範與該公司的資料處理方法存在差異,在某些情況下,該漏洞允許錯誤地處理 HTTP 請求。
受影響區域為「LINE Chat」聊天功能和「LINE官方帳號」管理介面,在2025年9月19日、24日和25日這三天的特定時間內,使用相同通訊管道的使用者和公司資訊可能會被錯誤顯示。可能洩露的資訊包括內部識別碼、用戶名、頭像、管理的公司資訊、管理員個人資料資訊以及在「LINE Chat」上收發的訊息,據稱發生這種情況的機率低於0.001%。
這個問題是由參與「LINE安全漏洞賞金計畫」的漏洞測試員提交的報告發現的。 LINE和Akamai都已做出回應並修復了該問題,導致該漏洞和事件被公開披露。目前尚未確認有未經授權使用等二次損害,LINE公司正在採取措施防止再次發生,並對其測試系統進行審查。
從:
關於因「LINE官方帳號」錯誤顯示而導致資訊外洩的通知和道歉
【社論】
⚠️近期,LINE出現了一些問題,這些問題都與LINE官方帳號有關。
有關 LINE E2EE(信函密封 v2)漏洞的更多信息,請參閱此處 → LINE“信函密封 v2”漏洞 | innovaTopia 編輯團隊成功演示,我們應該怎麼做?
在這種情況下,影響「LINE 官方帳號」(連接企業和商店與用戶的入口)的問題並非出在應用程式本身,而是出在 CDN 層。 Akamai 邊緣伺服器的 HTTP 請求走私漏洞 CVE-2025-66373,加上 LINE 端資料處理方式的差異,導致在特定情況下回應出現“擁塞”,進而造成其他使用者或企業的資訊顯示錯誤。
HTTP 請求走私:“隱形攻擊面”
HTTP 請求走私是一種攻擊方法,它利用前端(CDN 或 WAF)和後端(應用程式伺服器)對相同請求使用略有不同的規則進行解析這一事實。本案例中的問題是“無效的分塊請求體大小”,這源自於分塊傳輸編碼中對請求體長度的處理方式。如果邊緣端和來源端對請求的解析方式不同,原本應該分開的請求和回應可能會混淆。
「限制性條件」背後的結構性風險
LY解釋說,只有在測試期間受影響的服務通過同一通訊路徑使用時才會產生影響,且發生的機率低於0.001%。雖然這個數字極低,但由於LINE聊天訊息的內容也包含在測試範圍內,因此不能忽視在諮詢或支援訊息中處理的敏感資訊可能被意外發送給非預期接收者的風險。
漏洞賞金計畫的成功案例及其面臨的困境
這次事件是由參與LINE安全漏洞賞金計畫的測試人員提交的報告發現的,並在被大規模利用為零日攻擊之前就被修復,展現了漏洞賞金計畫的積極作用。然而,在驗證過程中發現其他用戶的資料實際上也被洩露後,LINE暫時停止接受新的報告,目前正在審查其驗證系統和規則,這凸顯了「防禦性驗證」可能帶來新風險的困境。
重要的是要意識到,您自己的服務可能也是基於相同的架構構建的。諸如官方帳號、聊天、CDN 和漏洞賞金服務等元素不再只是少數大型平台的功能,而是正在成為所有數位產品的「必備基礎設施」。
企業現在應該重新考慮的幾點
與其簡單地將這次事件視為「LINE故障」而置之不理,不如將其視為一個契機,促使讀者所在機構思考以下問題:貴公司的服務在多大程度上依賴外部供應商?如何追蹤CDN和SaaS漏洞資訊?如何與漏洞賞金計畫和外部研究人員建立合作關係?我認為,這些視角對於未來建立「值得信賴的數位服務」至關重要。
技術細節
HTTP/1.1 有兩種主要方法來表示訊息體可以分隔的位置。
- Content-Length 標頭:郵件正文的位元組長度預先在標頭中指定。
- Transfer-Encoding 標頭:透過指定“分塊”,您可以無需先確定長度即可進行串流傳輸。
當這兩個頭部同時使用時,會出現一個常見問題。同時使用這兩個頭部違反了規範。然而,在實際的伺服器實作中,當同時指定這兩個頭部時,其行為卻有所不同。
最新的 HTTP/1.1 規範 RFC 9112 規定,如果同時偵測到這兩個頭部訊息,則應將其視為攻擊並立即傳回錯誤。然而,實際實現並非總是遵循該標準。
如果收到的訊息同時包含 Transfer-Encoding 和 Content-Length 標頭字段,則 Transfer-Encoding 會覆蓋 Content-Length。此類訊息可能表示有人試圖進行請求走私(請參閱 11.2 節)或回應拆分(請參閱 11.1 節),應視為錯誤處理。選擇轉送該訊息的中間方必須先移除收到的 Content-Length 字段,並處理 Transfer-Encoding(如下所述),然後才能將訊息轉送給下游。
RFC 9112 第 6.3 條
什麼是分塊編碼?
簡而言之,HTTP 訊息體被分割成多個資料塊(單元)並依序傳送。此時,一個資料區塊由十六進位的 `<length>` 、 <CR><LF> 、資料區塊內容( `<length> ` 位元組)和<CR><LF>組成,訊息體透過將這些資料區塊連接起來完成。訊息體末端會傳送一個`<length> = 0` 的資料區塊。
在這個漏洞中,Akamai CDN 伺服器錯誤地解釋了分塊編碼中指定的無效長度。結合 LINE 伺服器端的處理機制,這使得攻擊成為可能。
HTTP/2、HTTP/3 和 QUIC 是 HTTP/1.1 的替代方案,它們不存在此漏洞,並且在現實中被廣泛使用,但 HTTP/1.1 在負載平衡器和反向代理的後端被廣泛使用,許多支援 HTTP/2 和 HTTP/3 的伺服器也支援 HTTP/1.1,因此攻擊者可以利用這一點。
本節內容由編輯部安全工程師 Yuka 撰寫。
Yuka – innovaTopia 我從哲學和實踐的角度探索了科技與人類思維之間的關係。身為一名從事系統開發和人工智慧技術的IT工程師,我也在探索心靈和宇宙的哲學。[術語]
HTTP 請求走私<br>一種攻擊技術的通用術語,它利用多個設備使用不同規則解釋 HTTP 請求這一事實,允許以非預期的方式走私請求。
零時差攻擊<br>在修補程式或應對措施發布之前針對漏洞發起的攻擊,使開發人員沒有時間做出回應。
CVE
「Common Vulnerabilities and Exposures」的縮寫,是一個為已知漏洞分配唯一 ID 並對其進行組織和共享的系統。
CDN(內容傳遞網路)
一種基礎設施服務,它將內容快取到世界各地的邊緣伺服器上,並將其交付給用戶,從而加快 Web 和 API 的速度並提高其可用性。
漏洞賞金計劃
這是一個組織向安全研究人員和其他報告漏洞的人員支付獎勵或其他補償的系統,已被大型雲端服務和 SaaS 廣泛採用。
[參考連結]
LY Corporation(LINE Yahoo Japan Corporation) (外部)
經營 LINE 和 Yahoo! JAPAN 的 LY 公司的官方網站也包含新聞、隱私和安全資訊。
LINE 安全漏洞賞金計畫(外部)
針對 LINE 相關服務漏洞的漏洞賞金計畫的官方網站解釋了該計畫的範圍、規則和獎勵。
CVE-2025-66373 (外部)
Akamai HTTP 請求走私漏洞的官方 CVE 記錄概述了該漏洞的技術概況、嚴重性和影響範圍。
Akamai Technologies (外部)
這是某家在全球範圍內提供 CDN、安全服務和邊緣運算基礎設施的公司的官方網站。
[參考文章]
Akamai 修復邊緣伺服器中的 HTTP 請求走私漏洞(外部)
本文對 Akamai 邊緣伺服器中的 HTTP 請求走私漏洞 CVE-2025-66373 進行了技術概述,並提供了修復時間表和影響範圍。
CVE-2025-66373 – 漏洞利用及嚴重性(外部)
這是一個面向工程師的資源,它匯總了諸如 CVE-2025-66373 的嚴重性、利用場景和已知 PoC 等信息,並為使用 Akamai 的服務編制風險評估。
CVE-2025-66373 安全漏洞及利用詳情(外部)
這是一篇解釋性文章,詳細介紹了 CVE-2025-66373 的原因和攻擊模式,該問題是由 HTTP 請求中分塊正文大小的處理引起的。
Akamai 修正了 Edge 瀏覽器中的 HTTP 請求走私漏洞… (外部連結)
本文從事件回應的角度總結了 Akamai 如何處理從漏洞揭露到修補程式應用和客戶通知的整個過程。
Akamai 的 CDN 導致「LINE 官方帳號」資訊外洩(外部連結)
本文面向國內讀者,概述了LINE官方帳號資訊洩露事件、事件發生的時間以及可能洩露的資料類型。
LINE官方帳號資訊外洩—個人資訊屢遭洩露… (外部連結)
本文從國內企業安全營運和風險管理的角度,探討了這次資料外洩事件,並回顧了以往與官方LINE帳號相關的案例。
2025年近期資料外洩事件清單 – Bright Defense (外部連結)
該報告列舉了 2025 年發生的幾起資料外洩事件,其中就包括 LINE 官方帳號事件,並比較了損失規模和攻擊途徑。
[編者註]
我認為這次事件讓我們得以窺見支撐我們日常互動的「LINE官方帳號」背後運作的基礎設施和風險。如果您的公司或組織使用官方帳號或外部CDN,不妨與您的團隊討論一下:“在哪個層面上可能會發生什麼?”
即使你不了解所有的技術細節,我覺得只要把你信任這項服務的假設說出來,就能更容易看到你的下一步。
關於LINE,不只官方帳號,就連普通聊天記錄也存在安全漏洞。 LINE公司已表示將審查其安全模型,其後續舉措將受到密切關注。
LINE的「信件密封v2」漏洞 | innovaTopia編輯團隊成功演示了該漏洞,我們該怎麼做?