HAPI FHIR の XSLT 変換に XXE（外部実体参照）（CVSS 9.1）

Critical（CVSS 9.1）に分類されるHAPI FHIR (org.hl7.fhir.core) org.hl7.fhir.core 6.9.10 未満の脆弱性です。HAPI FHIR は、医療情報の相互運用規格である HL7 FHIR の Java 実装である。電子カルテやレセプト系のシステムが FHIR で外部とやり取りするときに、実質の標準ライブラリとして使われている。 この脆弱性は、6.9.10 より前の `org.hl7.fhir.utilities.XsltUtilities` の `saxonTransform(...)` にある。XSLT 変換を行うために `net.sf.saxon.TransformerFactoryImpl()` を素のまま生成しており、`ACCESS_EXTERNAL_DTD` と `ACCESS_EXTERNAL_STYLESHEET` の制限を設定していなかった。この2つはどちらも「変換の途中で外部を読みに行ってよいか」を決める設定で、既定では制限されない。 結果として、変換にかける XML を攻撃者が用意できる、あるいは途中で改ざんできる場合に、XML 外部実体参照（XXE）が成立する。できることは2つある。1つはローカルファイルの読み出しで、サーバ上のファイルの中身を変換結果に混ぜて持ち出せる。もう1つはブラインド XXE / SSRF で、実体参照の解決先を任意の URL にすることで、そのホストから到達できる先へリクエストを飛ばせる。クラウド上で動いていれば、メタデータサービスのような内部エンドポイントが射程に入る。 NVD の CVSS 3.1 基本値は 9.1（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N）で Critical。**認証も利用者の操作も不要（PR:N/UI:N）**である一方、可用性への影響は無し（A:N）とされている。つまり落とすための欠陥ではなく、読み出しと踏み台化のための欠陥である。GitHub Security Advisory（GHSA-2f55-g35j-5jmf）側は CVSS 4.0 で 8.7 HIGH としており、こちらは機密性のみ高（VC:H/VI:N/VA:N）と評価している。 修正は 6.9.10 で入っており、コミット `01ca2ecd` で TransformerFactory に外部アクセスの制限を設定するようになった。NVD の版レンジは versionEndExcluding=6.9.10 で、それより前の全バージョンが対象である。NVD 公開日は2026年7月8日、最終更新は7月16日、vulnStatus は Analyzed。2026年8月3日時点で CISA KEV カタログには収載されていない。

まず、自分のシステムが対象かどうかを依存関係から確認する。直接 `org.hl7.fhir.core` を書いていなくても、HAPI FHIR の各種モジュール経由で推移的に入っていることが多い。Maven なら `mvn dependency:tree -Dincludes=org.hl7.fhir*`、Gradle なら `./gradlew dependencies --configuration runtimeClasspath | grep hl7.fhir` で実際に解決されている版が出る。**pom に書いた版ではなく、解決された版を見る**こと。 恒久対応は **6.9.10 以降へ更新する**ことである。推移的依存で古い版が引っ張られている場合は、直接の依存を上げるか、`dependencyManagement`（Maven）／`resolutionStrategy.force`（Gradle）で版を固定する。 更新できるまでの緩和策は、XSLT 変換を通す経路を絞ることである。この欠陥は「攻撃者が中身を左右できる XML を変換にかける」ことで成立するので、外部から受け取った FHIR リソースやプロファイル定義をそのまま変換に渡している箇所があれば、そこを止めるか、信頼できる入力だけに限定する。自前で `TransformerFactory` を生成している箇所があるなら、`setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)` と `setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "")` / `ACCESS_EXTERNAL_STYLESHEET, ""` を明示する。これはこのライブラリに限らず Java の XML 処理全般で有効な設定である。 検知は、XXE の性質上アプリのログには残りにくい。現実的にはネットワーク側から見る。アプリケーションサーバから外向きに出る想定外の HTTP/HTTPS リクエスト、特にクラウドのメタデータエンドポイント（169.254.169.254 等）宛の通信を監視すると、ブラインド XXE の試行が見える。**アプリから外へ出る通信を既定で拒否し、必要な宛先だけ許可する**構成にしてあると、この種の欠陥の被害はそこで止まる。 優先順としては、インターネットから FHIR エンドポイントを受けているシステムが最優先である。院内ネットワーク内に閉じている場合でも、患者データを読み出せる欠陥である以上、放置してよいものではない。

HAPI FHIR (org.hl7.fhir.core) org.hl7.fhir.core 6.9.10 未満 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-55471）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。