OpenAI侵入、画像アップロード起点の4手順

この報告の価値は、単一の欠陥ではなく4つのステップの組み合わせ方にある。第一は画像処理だ。Discourseのアップロード経路はFastImageで画像を検査していたが、FastImageがHEIC/HEIFを認識しなかったため、それらのファイルはそのままImageMagick、次いでlibheifに渡された。第二はほぼ不公平に見えるバージョンギャップだ。Debian 12の1.19.7に含まれるlibheifの脆弱性は前年に上流で修正されていたが、修正はセキュリティラベルもCVEもないリファクタリングコミットとして届いたため、Debianのセキュリティアップデートには反映されず、脆弱なバージョンがDebian 12とDebian 13の両方に残った。

研究者はその後、この脆弱性を足がかりにし、Claude Opus 4.8と後のOpus 5を頼りに、Discourseの環境（x86-64、メモリ管理はjemalloc）に合わせたエクスプロイトを構築した。まず自分たちのDiscourse Cloudインスタンスで試し、次にOpenAIのフォーラムでリモートコード実行と管理者アクセスに成功した。そこからはフォーラムの「Sign in with OpenAI」SSOを経由して、従業員のChatGPT/Codexアカウントへと至る経路が続いていた。報告はSSOの具体的な弱点を明かしていないが、著者らは問題がDiscourse固有のものではなくOpenAIのSSOにあったと明言している。

最後に、リンクされたCodexエージェントを使ってopenai/openaiモノレポにプルリクエストを開いた。研究者は自らの判断でそこで停止したため、被害は彼らが選んだ範囲にとどまった。彼らのより広い主張は速度についてだ。攻撃コードの構築という、かつては熟練者が長期間かけて行う作業だった段階が、AIの支援によって、脆弱性の発見からPR作成まで72時間未満に圧縮されたのである。