1. これは何の話？

OpenReviewのAPIバグにより、ICLR 2026を含む主要ML会議で匿名とされるレビュワー・著者・エリアチェアの身元が一時的に外部から参照可能になった事件の解説です。profiles/searchエンドポイントの認可抜けが原因で、ブラウザから誰でも役割付きプロフィールを列挙できる状態になり、学会のダブルブラインド運用が破られました。

2. 何がわかったか

  • ICLR 2026やACL ARR、NeurIPS、ICML、EMNLPなど広範な会議のレビュワー・著者・ACの紐づけが露出したと報告。
  • 問題はgroupパラメータ付きのprofiles/searchが十分な認可チェックを行わず、役割情報付きでプロファイルを返したことによる。
  • 最初の報告から約1時間で暫定パッチが投入され、OpenReviewはアクセスログの解析と影響ユーザーへのメール通知を進めると説明。
  • OpenReviewは悪用が確認されれば多国籍の法執行機関に連絡するとし、ICLRは漏洩情報の利用に対し即時desk rejectと複数年の参加禁止を明示。

3. 他とどう違うのか

パスワード流出ではなく、匿名性が前提の「役割と実名の対応表」が一括で露出した点が特殊です。正規UIに依存しないパラメータ操作での情報列挙という、読取り専用API由来の“静かな”アクセス制御崩れが本質です。

4. なぜこれが重要か

レビュワーの匿名性は報復や圧力からレビュー品質を守る要石であり、これが壊れるとレビュー参加意欲と学会運営の信頼が大きく損なわれます。同時に、単一プラットフォームが多数会議の審査基盤を担う集中リスクが顕在化しました。

5. 未来の展開・戦略性

列挙系APIの認可強化やフィールド最小化、異常検知の標準化が学会インフラでも必須になるでしょう。各学会はコード・オブ・コンダクトに沿った制裁を明文化し、プラットフォームと連携した事後開示・監査体制を整える流れが加速しそうです。

6. どう考え、どう動くか（具体例→指針）

例えば、過去1年でOpenReviewを使った提出・レビューがある場合、届く通知メールと公開声明を確認し、自身のレビューや提出が紐づいていないかを記録する。

  • 指針1：profiles/searchなど列挙系APIの権限設計を自社SaaSでも棚卸しし、不要フィールドを遮断する。
  • 指針2：学会・プラットフォーム双方のインシデント対応（通知窓口・制裁方針）をチーム内で共有する。
  • 指針3：レビューや採点の品質を保つため、匿名性が薄れた場合でも説明責任を果たせる記録を残す。 次の一歩： ・今日やること：OpenReviewからの通知メールが届いていないかスパムを含め確認する。 ・今週やること：自社・研究室の利用SaaSで、列挙APIの認可ルールとログ取得状況を1件点検する。

7. 限界と未確定

  • 何が不明か：実際にどのアカウントがどの程度データを取得したか、具体的な影響件数は未公表です。
  • なぜ不明か：ログ解析と当事者通知が進行中で、フォレンジック結果がまだまとめられていないためです。
  • 次にどう調べるか：OpenReviewとICLRの追加報告やメール通知を確認し、公開されるフォレンジック結果で範囲を特定します。

8. 用語ミニ解説

  • 列挙系API（enumeration API）：ユーザーやグループを一覧取得できるエンドポイント。権限漏れがあると大量のメタデータが取得されやすい。
  • ダブルブラインドレビュー（double-blind review）：著者とレビュワー双方の身元を相互非公開にして評価する方式。

9. 出典と日付

MGX Blog（公開日：2025-11-28）：https://mgx.dev/blog/openreview-leak-2025