要点
- 攻撃者が細工した ChatGPT の共有リンクを開くと、攻撃者のコードが自分のログイン中の ChatGPT で動き、共有していない会話まで読まれるおそれがあった。
- 見つけたのはセキュリティ企業 Parameter で、OpenAI は報告から8日後の2026年10月26日に直した。利用者側でやることはない。
- 研究者の検証で示された段階の話で、実際に悪用されたという報告はない。
何が起きたか
ChatGPT には、会話を URL にして他の人に見せる「共有リンク」の機能がある。セキュリティ企業 Parameter の Mukul Goyal 氏は2026年10月28日、この共有リンクを使って、開いた人の ChatGPT アカウントで勝手に動くコードを仕込めたと報告した。
Parameter によると、当たる条件は次のとおりだ。
- ブラウザで ChatGPT にログインしている。
- 攻撃者が作った共有リンクを開く。リンクはふつうの公開リンクで、メールやチャット、SNS などで送られうる。
- 最も安定した版では、会話の中の「Preview」（HTML の表示を試すボタン）を1回押す必要があった。のちの版では Preview が自動で開くようにでき、リンクを開くだけで足りたという。
アプリを入れる、コードを貼る、といった操作は要らなかったと Parameter は書いている。
仕込まれたコードは、被害者本人として ChatGPT を操作できたと Parameter は報告している。攻撃者が共有を受けたことのない会話も、その対象に入る。中身を取り出して外のサーバーへ送るところまで確かめたという。Parameter は、報告の題で「アカウントの乗っ取り」と呼んでいる。ただし検証は研究者が用意した別のアカウントどうしで行い、送ったデータもわずかにとどめたという。
日本の利用者への影響
仕事の資料や個人的な相談を ChatGPT に入れている人は多く、それが読まれうる点で身近な話だ。
Parameter の報告には、実際の悪用についての記述はない。日本の利用者が当たったかどうかも分からない。スマートフォンのアプリが当たるかどうかも、報告には書かれていない。
今すぐやること
- やり直しは要らない。 OpenAI の修正はサーバー側で済んでおり、何かを入れ直したりパスワードを変えたりする必要はないと The Hacker News は伝えている。
- 知らない人からの共有リンクは、ほかのリンクと同じく疑う。 心当たりのない ChatGPT の共有リンクは開かない。開いても、出どころの分からない会話で Preview を押さない。
- 自分の共有リンクを見直す。 設定の「データコントロール」にある「共有リンク」の「管理」から、作ったリンクの一覧を見て、要らないものを消せる（OpenAI のヘルプによる）。OpenAI のヘルプによると、個人アカウントで作ったリンクは、リンクを持つ人なら誰でも見られる。見せる相手を一人ずつ選ぶ仕組みはない。
- 会話の履歴を見て、覚えのないものがないか確かめる。 見覚えのない会話や、自分が作っていない共有リンクがあれば、OpenAI のサポートに相談する。
- 大事な情報は入れすぎない。 今回のような欠陥は今後も見つかりうる。パスワードや顧客の個人情報など、漏れて困るものは ChatGPT に入れないのが無難だ。
背景
Web の画面では、危ないかもしれない中身を「サンドボックス」（外に手を出せない囲い）の中で動かすことが多い。ChatGPT の Preview も、別のドメインの囲いの中で HTML を動かしていた。Parameter によると、この囲い自体は破られていない。
問題は、囲いの外にある別の部品だった。共有された会話に対話式のグラフがあると、数式入力のための部品（MathLive）が ChatGPT の本体の画面に読み込まれる。この部品は、ほかの枠から届くメッセージを、誰が送ったか確かめずに受け付けていた。Preview の囲いの中から送ったメッセージが本体の画面に届き、囲いのない枠が作られて、そこで攻撃者のコードが動いたという。
囲いそのものがどれだけ固くても、囲いの内と外をつなぐ通り道が一つでも甘ければ守りにならない。一つひとつの機能は安全でも、組み合わせると穴になる例だ。
OpenAI はこの問題を再現したうえで深刻度を P2 から最も重い P1 に上げ、5,000 ドルの報奨金を払ったと Parameter は報告している。
技術者向けの詳細
- 経緯（Parameter の報告による）
- 2026-10-18: OpenAI のバグ報奨金プログラムに報告
- 2026-10-21: OpenAI が再現し、P2 → P1 に引き上げ
- 2026-10-26: 2つある Web フロントエンドの両方で、問題のメッセージを拒むよう修正。解決扱い
- 2026-10-28: Parameter が公開
- 原因（Parameter の分析による）: 弱いところが1か所ではなく、本体の画面に読み込まれた MathLive の中でいくつも重なっていた。キーボード関連の
postMessageの受け手はevent.originもevent.sourceも照合していなかった。しかも、渡される配列データには生の HTML を入れられた。createHTMLヘルパーも値を無害化せず、そのまま返していたとされる。その HTML は sandbox 属性のないsrcdociframe として描かれ、chatgpt.comのオリジンで動いた。 - CSP について: インラインスクリプトは CSP で止まっていた。それでも、許可されていた YouTube の oEmbed（JSONP）を使って迂回できたという。Parameter の見方では、穴の本体は上の MathLive 側にある。CSP は最後の守りとして置くもので、ほかの対策の代わりにはならないとしている。
- 開発者への勧め（Parameter の勧めを要約）: 動的に作る文書から sandbox を外さない。枠をまたいで渡す設定値に HTML を入れない。メッセージの受け手では、送り元のオリジンと、許可した window そのものを両方照合する。共有で人に見せる画面は、機能を一つずつではなく組み合わせて試す。
- 詳しい流れは Parameter の報告を参照