Parameter Labs 於 2026 年 10 月 28 日公開一項已修復的研究：ChatGPT 的公開分享連結可讓攻擊者程式碼在受害者登入狀態下執行，讀取私人對話並外傳，只需打開一條連結。OpenAI 已於 10 月 26 日修復，列為 P1。
這次 ChatGPT 分享連結漏洞是什麼？
攻擊者用正常分享功能發布惡意對話，受害者打開後，注入程式碼以 chatgpt.com 身分在其登入狀態下執行，可讀取私人對話並外傳資料。
問題的起點並非分享功能本身，而是分享頁面同時承載了兩種會被瀏覽器當成程式碼執行的內容：一是對話中的互動圖表，二是 HTML Preview。兩者在設計上各自有隔離，但當它們出現在同一個公開分享頁面時，隔離層之間的縫隙被打開。
研究團隊把這條路徑形容為「組合出來的漏洞」。單獨檢視任何一個功能，行為都符合預期；把公開分享、Preview、數學鍵盤元件、動態 iframe 與內容安全政策放在一起，才出現可被利用的鏈條。這類漏洞難以靠單一功能測試發現，也解釋了為何它存在一段時間而未被自動掃描捕捉。
攻擊鏈如何跨越沙箱邊界？
Preview 被關在獨立網域，但主頁面的 MathLive 鍵盤監聽器不檢查訊息來源，接受任意網域的鍵盤設定，內容再被當成 HTML 寫入主頁面。
第一步是製造一個可信的發送者與一個鬆散的接收者。對話中的圖表會在主要頁面載入 MathLive 這個數學輸入函式庫，載入過程同時在主頁面註冊一個監聽器，用來接收虛擬鍵盤的訊息。瀏覽器的 postMessage 機制允許不同頁框交換訊息，本身屬於正常設計，前提是接收方要驗證訊息來自哪個網域、哪個視窗。
MathLive 的頂層控制器在該設定下採用寬鬆的來源政策，等於接受任何網域送來的訊息，也沒有要求更新設定必須來自先前核准的視窗。Preview 頁框雖然被隔離在另一個網址，仍然可以往主頁面的訊息通道投遞內容。兩個互不相關的功能於是被接成一條通道。
第二步是把訊息變成 HTML。鍵盤版面設定允許以原始 HTML 描述按鍵外觀，元件在顯示鍵盤時把該字串指派給主頁面的 innerHTML。研究團隊指出，負責處理的可信型別輔助函式只把字串標記為可信，並未實際過濾內容。透過 innerHTML 插入的 script 標籤不會執行，因此需要第三步。
第三步是用 srcdoc 建立新文件。寫入的內容包含一個不帶 sandbox 屬性的 iframe，其 srcdoc 直接承載 HTML。瀏覽器會為這個頁框建立全新文件並解析內容，由於頁框由 chatgpt.com 主頁面建立，新文件繼承了同源身分，內部的程式碼因此可以存取父頁面。
為什麼 YouTube 的 JSONP 端點能繞過 CSP？
ChatGPT 的政策封鎖行內程式碼，卻允許載入 YouTube 腳本。oEmbed 端點支援 JSONP 回呼，回傳內容以 JavaScript 執行，可載入任意程式。
內容安全政策在此扮演第二道牆。ChatGPT 的政策正確封鎖行內 JavaScript，但仍允許來自 YouTube 的腳本，因為頁面需要嵌入影片。研究團隊轉向 YouTube 的 oEmbed 端點，該端點支援 JSONP 風格的 callback 參數，回應本身是 JavaScript 而非純 JSON。
端點對非法的回呼名稱有驗證，但驗證失敗的錯誤訊息在回傳前就把使用者提供的字串放進回應內容。研究團隊在回呼結尾加上 void 運算子，令附加的錯誤物件不產生作用，回應因此成為一段可執行且無副作用的程式。由於 YouTube 本來就在允許清單內，瀏覽器把回應當作腳本載入並執行。
需要強調，這一步只是繞過政策的手段，並非根因。研究團隊明確指出，即使封鎖該端點，未受信任的 Preview 仍然可以把 HTML 注入主頁面，風險只是被推遲而非消除。
漏洞實際可以讀取哪些資料？
程式碼取得頁面中的存取權杖與帳號識別碼，呼叫對話介面列出最近二十個對話，再讀取指定對話的訊息內容，最後以圖片請求把資料送往外部伺服器。
研究團隊展示的路徑分成三段。第一段從主文件的啟動資料區塊取出存取權杖與帳號識別碼，並核對兩者是否一致。第二段以權杖呼叫對話介面，先列出最近的對話清單，再針對特定對話取得訊息資料，被讀取的對話與惡意分享完全無關，也從未分享給攻擊者。
第三段是外傳。注入的程式碼建立一個指向攻擊者伺服器的圖片請求，把選取的資料附在網址參數中送出。研究團隊刻意只送出少量資料，並在請求前清除權杖、帳號與請求標頭的參照，避免在展示環境留下完整憑證。
由於程式碼以網頁應用本身的已驗證身分執行，影響範圍不限於對話介面。同一套前端介面能存取的其他資料與操作，理論上都落在同一邊界內。這一點是整個研究最需要留意的部分：漏洞的嚴重度不在於頁面被改動，而在於攻擊者取得了與使用者相同的操作能力。
OpenAI 如何修復與評級？
OpenAI 於 10 月 21 日重現問題並把嚴重度由 P2 提升至 P1，10 月 26 日確認兩個前端版本都拒絕跨頁框的鍵盤訊息，完成修復並發放 5,000 美元獎金。
時間線顯示修復節奏緊湊。10 月 13 日確認從鍵盤訊息到 HTML 的路徑存在於正式環境，10 月 14 日透過正常介面重現完整鏈條，10 月 16 日確認可在不同帳號與工作區之間以一次點擊交付，10 月 17 日確認開啟分享後 Preview 自動展開，10 月 18 日正式提交報告。
10 月 21 日 OpenAI 重現問題，嚴重度由初步分級提升為 P1。10 月 22 日回報其中一個前端已修，另一個仍在更新；10 月 23 日政策調整攔下部分鏈條，但仍有一個前端待更新。10 月 26 日確認兩個版本都已拒絕報告中的跨頁框訊息，問題結案，獎金合計 5,000 美元。
修復方式集中在訊息接收端。如果只封鎖 YouTube 端點，注入路徑仍然存在，因此團隊把重點放在讓主頁面拒絕未經授權來源的鍵盤設定訊息。這個選擇反映一個原則：修補要落在信任判斷的位置，而非症狀出現的位置。
使用者需要做什麼？
官方已修復，日常使用不需額外動作。對來源不明的分享連結仍應保持警覺，避免在登入狀態下開啟陌生對話分享，並定期檢查帳號的登入裝置與工作階段。
漏洞已在伺服器端修復，使用者不需要更新任何軟體或清理瀏覽器資料。前端修復的特性是下次載入頁面即生效，因此舊分頁若長期未關閉，重新載入一次即可取得新版頁面。
習慣層面的調整仍然值得做。公開分享連結本質上屬於可被任何人製作的內容，與陌生郵件中的附件地位相近。對於來源不明的對話分享，先確認發送者身分再開啟，是最低成本的防護。同時建議定期檢視帳號的登入裝置清單，移除不認識的工作階段。
企業環境可以再加一層。若組織允許員工在瀏覽器登入個人 AI 帳號並同時處理內部資料，這類跨站執行的風險會直接連到內部資訊。以瀏覽器設定檔隔離工作與個人帳號，能把單一漏洞的影響限制在較小範圍。
開發者可以從中學到什麼？
接收跨頁框訊息時必須同時驗證來源網域與發送視窗，跨視窗設定不應容許原始 HTML，由外部內容建立的動態文件必須保持 sandbox 屬性，政策封鎖只能作為後備。
研究團隊列出的防護原則相當具體。訊息接收端要驗證兩件事：訊息來自哪個網域，以及是否來自先前核准的視窗。只檢查其中一項，仍然可能被另一個頁框借用通道。跨視窗傳遞的設定值不應包含可被解析為 HTML 的內容，因為渲染層一旦把字串當成標記處理，過濾就必須在更早的位置完成。
動態建立的文件需要保持 sandbox 屬性，尤其是內容可能受外部影響的情況。若一個頁框由受信任的主頁面建立且不帶 sandbox，它會繼承主頁面的來源身分，這正是本次鏈條從「無法讀取父頁面」變成「可完全操作父頁面」的關鍵一步。
內容安全政策適合當作縱深防禦，不適合當成唯一屏障。當攻擊者已能把 HTML 送進主頁面，政策能做的只是限制載入來源；只要允許清單中存在任何可被操控的第三方端點，繞過就有機會成立。把信任判斷放在接收端，比不斷收窄允許清單更為根本。
出處連結有哪些？
原始研究由 Parameter Labs 於 2026 年 10 月 28 日發表，內含完整技術細節、程式碼片段與時間線，官方修復說明以 OpenAI 的回報結案紀錄為準。
總結：分享功能還安全嗎？
現行版本已封堵本次路徑，公開分享仍可正常使用。真正的啟示是功能組合帶來的風險，單一環節看似安全，串連之後仍可能形成完整攻擊面。
這次事件的價值在於展示現代網頁應用的風險結構。沙箱、來源政策、內容安全政策與第三方端點都是成熟機制，各自運作正常，卻在交界處留下可被組合的路徑。修復只花數日，發現卻需要把五個看似無關的功能放在同一個畫面裡思考。
對一般使用者，這次的實際影響有限，因為修復已在伺服器端完成，且利用條件需要受害者主動開啟特定連結。對開發者與產品團隊，這次留下的檢查清單相當清楚：每一個跨頁框通道都要問接收方是否驗證了來源，每一段會被當成標記渲染的字串都要問是否可能來自外部。
公開分享是協作產品的核心功能，關閉它並不現實。可行的做法是把分享內容視為完全外部輸入，在渲染、訊息傳遞與文件建立三個層面各自設下邊界，令單一環節失效時不會直接連到已驗證的工作階段。
