OpenEMRの認可回避で患者情報を読み書き、8.4.0で修正
OpenEMR 8.4.0未満のOAuth認可に不備があり、認証なしで患者レコードを読み書きされるおそれがあります。FHIR APIとシステムスコープを有効にしている施設は、8.4.0へ更新し、承認設定を見直してください。
急ぎ度: 早めに
CVSS v3は9.1、v4は9.3で、認証なしに患者レコードを書き換えられ、修正版の8.4.0も出ていますが、成立にはFHIR APIなどの設定が前提なので、該当する施設は早めの更新が必要です。
関係があるか
FHIR APIとシステムスコープを有効にし、OAuthの登録・トークン・FHIRの経路をネットワークから到達できる状態で動かしているOpenEMRが対象です。どちらの機能も既定ではオフなので、使っていない環境は、通常の更新計画に組み込めば足りるとみられます。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| OpenEMR | 8.4.0未満（開発元の検証は8.3.0で実施） | 8.4.0 |
確かめ方
- 1OpenEMRの版が8.4.0未満かを確認します。公式のDockerイメージを使っている場合は、イメージのタグも見てください。
- 2設定項目rest_fhir_apiとrest_system_scopes_apiが、どちらも有効（1）になっていないかを確認します。
- 3設定項目oauth_app_manual_approvalが0（自動承認）のままになっていないかを確認します。
- 4OAuthの登録・トークン・FHIRの各経路に、インターネットや院外のネットワークから到達できるかを、ネットワーク担当者と確認します。
何が起きたか
OpenEMRのOAuth認可に2つの不備があり、管理者の承認を受けないまま、システム権限のFHIR APIで患者レコードの検索・閲覧・更新・新規作成ができてしまいます。CWEはCWE-863（不適切な認可）です。
1つ目は、承認が必要なクライアントを見分ける判定の抜けです。スコープの区切りにはスラッシュとコロンのどちらも使えますが、システム権限かどうかの判定はスラッシュ表記しか見ていません。コロン表記で登録されたシステム用クライアントは、管理者の承認を待たずに有効になります。
2つ目は、権限の包含を調べる処理の誤りです。この処理が、サーバーやクライアントが持つ権限ではなく、要求された権限をそのまま返すため、読み取り用に登録されたクライアントにも、登録していない書き込み権限のトークンが発行されます。
開発元の勧告は2026年10月28日付で、公式の本番イメージを使った検証で、患者の検索・閲覧・更新・作成を確認したと書いています。修正版は8.4.0です。
攻撃の流れ
-
1
クライアント登録
外部の者が、アカウントなしでOAuthクライアントの動的登録を送る。
-
2
承認をすり抜け
スコープ表記の扱いの食い違いで管理者承認が働かず、クライアントが有効になる。
-
3
読み取りトークン
システム権限の読み取りトークンを取得する。
-
4
書き込みを上乗せ
登録していない書き込み権限が、判定の誤りで追加で発行される。
-
5
患者レコード操作
FHIR APIで患者レコードを検索・閲覧・更新・作成する。
どう悪用されるか
攻撃者はネットワーク越しに到達できればよく、OpenEMRのアカウント、既存のOAuthクライアント、管理者の承認、利用者の操作は要りません。ただし、FHIR APIとシステムスコープのAPIが有効で、パッチアプリの承認が自動承認のままという構成が前提です。OAuthの登録・トークン・FHIRの経路に、攻撃者の側から到達できる必要もあります。
悪用されると、患者レコードの内容を読まれ、書き換えられ、偽のレコードを作られます。CVSSの評価でも、機密性と完全性への影響が高く、可用性への影響はありません。
今すぐやること
-
1
8.4.0へ更新する
本番に当てる前に、テスト環境で更新後のFHIR連携を確認します。更新の前にバックアップを取っておくと、あとで内容を突き合わせるときに役立ちます。Dockerを使っている場合は、いま動いているイメージのタグを確認してから、修正版のイメージに差し替えてください。
docker image ls openemr/openemr -
2
登録済みのOAuthクライアントを点検する
システム権限のスコープを持つクライアントのうち、身に覚えのないものがないかを調べます。見つけたら、無効にしたうえで登録の経緯を調べてください。
-
3
患者レコードの更新・作成の履歴を見る
APIのアクセスログや監査ログで、心当たりのない更新や新規作成がないかを確認します。外部から経路に到達できる状態で動かしていた場合は、とくに丁寧に見てください。
-
4
更新後に設定を見直す
FHIR APIやシステムスコープを使っていないなら、無効のままにします。使う場合も、OAuthの経路を到達できる範囲に絞り、システム権限のクライアントは管理者が承認する運用にしてください。
すぐ更新できないとき
すぐに更新できないときは、次の措置でつなぎます。
- 手動承認を有効にします（oauth_app_manual_approvalが0の状態が自動承認です）。開発元によると、これで示された攻撃の流れは止まります。
- FHIR APIやシステムスコープを使っていなければ、rest_fhir_apiとrest_system_scopes_apiを無効にします。
- OAuthの登録・トークン・FHIRの経路へ、信頼できるネットワークからしか到達できないように制限します。
これらは更新までのつなぎです。手動承認だけでは2つ目の不備が残るため、8.4.0への更新は省けません。
背景
OpenEMRは、オープンソースの電子カルテと診療管理のソフトウェアです。FHIR APIを有効にすると、外部のアプリや院内の別システムが患者データを取りにいけます。システムスコープは、利用者がログインしない裏側のサービスにAPIを使わせるための権限で、管理者の承認が唯一の関門です。今回の1つ目の不備は、まさにこの関門を表記の違いで素通りできるというものです。
開発元の勧告によると、今回の流れはCVE-2026-67610の近縁にあたります。そちらは、管理者が承認したあとに患者の読み取りができる問題でした。今回は承認そのものを回避でき、さらに未登録の書き込み権限まで上乗せされる点が違います。
よくある質問
Q.手動承認にしてあれば、更新しなくてもよいですか。
Q.FHIR APIを使っていない場合は、急いで更新が必要ですか。
まだ分かっていないこと
- 開発元の検証は8.3.0で行われており、8.3.0より前の各版で同じ流れが成り立つかは個別に示されていません。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| openemropenemr |
8.4.0 未満→ 8.4.0 |
8.4.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
OpenEMR before 8.4.0 contains OAuth scope canonicalization and containment flaws that allow unauthenticated attackers to obtain unapproved system-level FHIR access. Attackers can register a colon-form system:Patient.read client that bypasses approval, then request unregistered system/Patient.write scope to read, modify, and create Patient records.
出典: CVE.org (CVE Program・cvelistV5) NVD