論文の査読者の身元情報が漏洩ーOpenReview大規模情報漏洩に見るAPIセキュリティの死角

セキュリティニュース

投稿日時: 更新日時:

論文の査読者の身元情報が漏洩ーOpenReview大規模情報漏洩に見るAPIセキュリティの死角

2025年11月27日、機械学習分野のトップカンファレンス(ICLR 2026、NeurIPS、ICMLなど)の査読・投稿管理プラットフォームである「OpenReview」において、極めて重大なセキュリティインシデントが発生しました。

概要

本来、厳格に匿名化されているはずの

・査読者(Reviewer)

・エリアチェア(Area Chair)

・ブラインド審査中の著者

の身元が、外部から容易に特定可能な状態となっていました。

攻撃手法は高度なハッキングによるものでなく

OpenReviewが提供するAPIの不備を突いたものでした。誰でもアクセス可能なブラウザ上で、特定のURLパラメータを操作するだけで、論文IDと査読者の個人プロファイルを紐づけて取得することが可能でした。

51分間で修正

公式のタイムラインを見ると、対応自体は迅速でした。

  • 2025年11月27日 10:09 AM (EST):ICLR関係者がバグを発見し報告

  • 2025年11月27日 10:12 AM (EST):OpenReviewチームが調査を開始

  • 2025年11月27日 11:00 AM (EST):修正パッチのデプロイ完了

報告から修正デプロイまで、わずか51分で対応しています。

漏洩した個人情報の内容

profiles/search APIに対し、適切なパラメータ(グループID)を投げるだけで、以下の情報をJSON形式で取得可能でした。

  • 氏名(Name): 漢字や母国語表記も含むフルネーム。

  • 所属機関(Institutional Affiliation): 大学、研究所、企業名。

  • メールアドレスの一部: 完全なメアドではないものの、ドメイン(@stanford.edu 等)が含まれており、氏名と合わせれば特定は容易。

  • 外部サービスID: DBLP、Google Scholar、個人ホームページへのリンク。

  • 履歴情報: 過去の学歴や職歴(Education & Employment history)。

  • コンフリクト情報(Conflicts): 共著者や利害関係者のリスト。

今回の本質的なリスクは、これらが「Submission ID(論文ID)」と紐付いた形で出力されたことにあります。

ダブルブラインド査読 紐付けのリスク

APIのレスポンスには、特定の論文IDに対する「Reviewer(査読者)」や「Area Chair(エリアチェア)」というロール(役割)情報が含まれていました。これにより、以下の「紐付け」が成立してしまいました。

  • 「誰が」(Reviewer Xの実名)

  • 「どの論文を」(Submission ID YYYY)

  • 「どう評価したか」(Reject/Accept、およびスコア)

匿名で守られているからこそ辛辣であるが正当な批判ができた査読者が、著者の目の前に引きずり出された状態です。特に、キャリアの浅い学生査読者が、学界の重鎮である著者の論文をリジェクトしていた場合、その心理的負荷は計り知れません。

この漏洩がもたらす主なリスク

最も直感的なリスクは、レビュワーやエリアチェアへの報復です。

  • 「自分の論文を落としたのはこの人だ」と特定される

  • SNS などでの晒し上げ(ネーム&シェイム)

  • メールや DM による嫌がらせ、嫌味、圧力

  • 将来の人事・共同研究・査読機会における見えないペナルティ

元記事でも、インシデント発生直後から SNS 上で「誰に落とされたのか調べてやる」といった投稿やミームが拡散されていたと指摘されています。

これを受けて ICLR や OpenReview は、

  • 漏洩情報の閲覧・共有・利用そのものを禁止行為とし

  • 発覚した場合は投稿の即時デスクリジェクト&複数年の出禁

  • 悪質な場合は法執行機関への通報も検討

と、かなり強いトーンで牽制しています。

なぜ参照系APIが穴になったのか

原因はWebアプリケーションセキュリティにおける最も古典的な欠陥の一つ、「アクセス制御の不備(Broken Access Control)」に集約されます。

問題となったのは、内部検索用に設計された profiles/search というAPIエンドポイントです。 レポートおよび公開された検証コードによると、このAPIは group というパラメータを受け付けていました。

  • リクエスト例: .../profiles/search?group=ICLR.cc/2026/Conference/Submission{ID}/Reviewer

システムはこのリクエストに対し、認証済みのユーザーが「その情報を閲覧する権限(Authorization)を持っているか」を適切に検証していませんでした。

結果として、正規のログインユーザーであれば誰でも、任意の論文IDを指定して査読者グループのメンバーを「列挙(Enumeration)」し、その個人プロファイル(氏名、所属、リンク等)を引き出すことができてしまいました。

出典

The OpenReview / ICLR 2026 Identity Leak: What Really Happened, Why It Matters, and What Comes Next