- Parameter LabsがChatGPTのHTMLプレビューに対する攻撃手法を公開
- サンドボックスiframe→親ページのinnerHTML→YouTube oEmbedの順で回避
- 共有URLを開くだけでデータ窃取が可能。OpenAIは修正し5,000ドル支払い
何が報告されたのか
Parameter Labsは、ChatGPTのHTMLプレビュー機能に対する攻撃手法を公表した。HTMLプレビューは、対話の中で生成されたインタラクティブなHTMLアプリをサンドボックス化されたiframe内に表示する仕組みで、記事によればOpenAIは以前これを「Canvas」と呼んでいたという。攻撃が成立すると、共有URLを開いた別のサインイン済みユーザーの個人データを窃取したり、そのユーザーに代わって操作を実行したりできた。
この報告を紹介したのは、2026年10月31日付でSimon Willison氏が自身のブログに投稿したリンク記事である。同氏は、OpenAIが穴を塞いで5,000ドルの報奨金を支払ったと伝えたうえで、この深刻さに対しては報奨金が安すぎるとの見方を示している。
攻撃チェーンの仕組み
起点は、OpenAIがグラフ機能の一部に使っているJavaScriptライブラリ「MathLive」だった。このライブラリは独自の仮想キーボードを備えており、サンドボックス化されたiframeからpostMessage()を送ることで親ページ側で呼び出せる。問題は受け手側のコードがinnerHTMLを使っており、他のサンドボックス化されたフレーム(HTMLプレビューのフレームを含む)からの呼び出しを防ぐ仕組みがなかったことだ。
結果として、iframe内の信頼できないコードが親ページに任意のHTMLを挿入できた。innerHTMLはscript要素を直接には実行しないが、サンドボックス制限のない新しいiframeを注入する用途には使えた。さらにCSPがインラインスクリプトを禁じ、スクリプトの読み込み元を数ドメインに限っていたものの、その一つにYouTubeが含まれていたため、YouTubeのoEmbedエンドポイントを使ってJavaScriptを反射させ、実行に持ち込めたという。
ChatGPT上でJavaScriptが動いてしまえば、APIから非公開のユーザーデータを取得し、画像参照を経由して外部へ送り出すのは容易だった、と記事は述べている。
入り口が共有URLだった点
この脆弱性で特に注意すべきは、攻撃の入り口が「共有URL」だった点である。攻撃者が用意したChatGPTの共有URLを、サインイン済みの別ユーザーが開くだけで、データ窃取や代理操作につながった。ユーザー側には特別な操作も、不審なファイルの実行も求められない。
防御は多層に見えるが、各層のわずかな設計判断が連鎖して回避された。postMessageの受け口、innerHTMLによるDOM挿入、CSPの許可ドメインという三つの前提が組み合わさって成立した攻撃チェーンであり、単一のバグとして片付けられるものではないと解釈できる。
修正と残る不明点
OpenAIはこの穴を塞ぎ、5,000ドルのバグバウンティを支払った。Willison氏は金額面に疑問を呈しているが、記事の範囲では修正自体は完了している。
一方、発見から修正までの期間や、実際に影響を受けたユーザーがいたかどうかは明らかにされていない。同様のpostMessage受け口が他の機能に残っていないか、Parameter Labsの技術解説がどこまで詳細に公開されているかも、この記事からは分からない。
| 防御層 | 回避に使われた要素 | 結果 |
|---|---|---|
| サンドボックス化されたiframe | MathLiveのpostMessage受け口がinnerHTMLを使用 | 親ページに任意のHTMLを注入できた |
| インラインスクリプトの禁止(CSP) | 許可ドメインのYouTube oEmbedでJavaScriptを反射 | スクリプト実行に持ち込めた |
| スクリプト読み込み元のドメイン制限 | 許可先の一つであるYouTubeを経由 | 制限を実質的に迂回した |
The end result: you could create a ChatGPT share URL which, when visited by another signed-in user, could exfiltrate their private data or take actions on their behalf.
最終的な結果として、ChatGPTの共有URLを作成し、他のサインイン済みユーザーがそれを訪問した際に、そのユーザーの非公開データを窃取したり、そのユーザーに代わって操作を実行したりすることが可能だった。
今後の見通し
OpenAIは該当の穴を塞いだが、記事が示すのは個別のバグではなく「サンドボックス+postMessage+緩いCSP」という組み合わせの危うさである。HTMLプレビューやArtifacts的な機能を提供する他のプロダクトでも、親ページ側のメッセージ受信実装が同種の弱点になり得るとみられるが、原文は他社への影響に触れていない。今後、Parameter Labsの詳細な技術解説やOpenAIのインシデント開示が出れば、影響範囲や再発防止策の実効性を判断できる。
日本の開発者・IT企業にとっての意味
日本のIT企業にとっても他人事ではない。ChatGPTのHTMLプレビューに限らず、生成AIアプリに対話型のHTML UIを埋め込むArtifacts的な機能は各社が追随している領域で、多くはサンドボックス化したiframeとpostMessageで親アプリと通信する。今回の攻撃は、その受け口がinnerHTMLを使い、送信元の検証を怠っていた点から始まった。自社実装では、メッセージ受信時の送信元検証、DOM挿入にtextContentやサニタイズを通すこと、CSPのscript-srcにoEmbedのような反射可能なドメインを安易に加えないことが具体的な確認項目になる。共有URLのようにワンクリックで広がる導線を持つ製品では、脆弱性の影響がユーザー間で連鎖し得る点も設計時に意識したい。
気になる点
- 共有URLを開くだけで被害に遭うのか
- 記事によれば、細工されたChatGPTの共有URLをサインイン済みのユーザーが訪問すると、そのユーザーの非公開データを窃取されたり、本人に代わる操作を実行されたりする可能性があった。OpenAIはすでに修正済みとされている。
- 自分のアカウントで追加の対策は必要か
- 記事の時点でOpenAIは脆弱性を修正済みで、利用者側の操作は求められていない。ただし影響を受けたユーザーがいたかどうかや、対象期間は公表されていないため、必要に応じて公式のアナウンスを確認したい。
- 他のAIサービスのHTML表示機能も危ないのか
- 原文は他社サービスについて言及しておらず、現時点では分からない。ただしサンドボックス化したiframeからpostMessageで親ページと通信する実装は広く使われており、受信側の検証が同種のリスクになり得る。
用語解説
- サンドボックスiframe
- 信頼できないHTMLやスクリプトを、親ページから隔離した状態で実行するための仕組み。
- postMessage()
- 親ページとiframeなど異なるオリジン間でメッセージをやり取りするブラウザAPI。送信元の検証は受信側の責務になる。
- innerHTML
- 要素の中身をHTML文字列として読み書きするDOMプロパティ。挿入の仕方によってはスクリプト実行につながる。
- CSP
- Content Security Policy。スクリプトの読み込み元やインライン実行の可否を制御するブラウザの仕組み。
- oEmbed
- URLを渡すと埋め込み用のHTMLを返す仕組み。YouTubeなどが提供している。
- バグバウンティ
- 脆弱性を報告した研究者に対して報奨金を支払うプログラム。
出典
How We Took Over ChatGPT Accounts
https://simonwillison.net/2026/Oct/31/how-we-took-over-chatgpt-accounts
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する