Azure Health Data Services FHIR
$import Exfiltrates MI-Readable FHIR Data and Leaks Azure Storage Error Metadata
The same missing destination check behind the token-theft advisory also let import callers reach other storage accounts using the service's permissions. The import pipeline can expose FHIR records through the normal read API without giving the caller a Storage role. Tests demonstrated the content import and access to another account separately; a complete cross-account content retrieval was not performed. Failed imports also revealed Storage response details. Microsoft has restricted imports to the configured account.
Description
This is a second impact of the same SSRF and fix as the token-theft advisory. The affected import validator accepted source URLs outside the configured storage account, and the Storage client used the service's Managed Identity to access them.
The import pipeline reads a source blob, parses its FHIR NDJSON, and makes the imported resources available through the FHIR API. Recoverable content is limited to valid FHIR NDJSON on accounts the service identity can read and reach; arbitrary blob content is not returned.
A synthetic Patient canary was imported from the configured account and read back by a caller with only FHIR Data Importer and no Storage role. A separate probe confirmed authenticated access to another account. Cross-account content recovery is supported by this shared code path, but was not separately demonstrated end to end.
Canary read-back (sanitized excerpt from the recorded output)
GET /Patient/probe-canary-<id> -> 200identifier.value = 'PROBE-CANARY-<id>-NOT-REAL-PHI'GetImportRequestHandler includes source URLs and Storage SDK error text in OperationOutcome.issue.diagnostics. The three-target test below produced a detailed Storage 404 for the account accessible to the identity, and generic 500 errors for both other destinations.
Operation-status diagnostics across three targets (abridged and sanitized)
# A - Storage account the Managed Identity can read (public callers firewall-denied):GET /_operations/import/<job-A> status=404 diagnostics: "Service request failed. Status: 404 (BlobNotFound) Server: Windows-Azure-Blob/1.0 x-ms-request-id: <redacted>"
# B - unresolvable host (no DNS record anywhere):GET /_operations/import/<job-B> status=500 diagnostics: "InternalServerError"
# C - reachable public non-Storage host:GET /_operations/import/<job-C> status=500 diagnostics: "InternalServerError"The reachable non-Storage host and the unresolvable host returned indistinguishable errors. These results show a limited Storage response oracle; they do not establish general network reachability or an exhaustive classification of other failures.
The separate probe account granted the identity Storage Blob Data Reader and enabled the trusted Microsoft services exception with an otherwise deny-by-default firewall. A direct external request returned 403, while the FHIR service reached Storage and received 404. This exception is one supported network option; IP allowlisting is another.
PR #5536 restricts imports to the configured storage account. Ordinary imports and detailed errors within that account remain possible: GetImportRequestHandler is unchanged in release/4.0.759. No CVE was assigned.
Impact
- The code supports disclosure of valid FHIR NDJSON from additional accounts readable and reachable by the service identity, including exported patient records where present. The evidence establishes the import mechanism and access to a separate account independently.
- Error responses disclosed Storage metadata in the tested cases. The service could reach the probe account because its role and the account's firewall exception permitted access.
Mitigation
Microsoft has deployed the destination check to Azure Health Data Services. Self-hosted Microsoft FHIR Server deployments should update to release/4.0.759 or later. The fix prevents imports from other accounts; it does not change access within the configured account.
Defender's Checklist
Restrict import and Storage permissions.
Grant
import/actiononly to trusted import workflows and remove unnecessary Storage grants from the service identity. Review network exceptions alongside those permissions.Review activity before the fix.
Where logs were enabled and retained, correlate FHIR imports with Storage operations by the service identity using available timestamps, resource URIs, and request metadata. Storage logs alone do not identify the originating FHIR caller or job.
Reduce detail in public errors.
For self-hosted forks, replace Storage SDK exception text in operation-status responses with a generic read-failure message. Keep diagnostic detail in appropriately protected operator logs.
Severity Reasoning
FHIR Data Importer, a role scoped to the FHIR service.UI:NThe service retrieves the source automatically.S:CThe caller's FHIR permission enables access under the service identity's separate Storage authorization.C:HCross-account FHIR data disclosure is supported by the shared code path and separate tests of content import and authenticated account access; it was not demonstrated in one end-to-end test.I:NImporting resources is already authorized for this role; no additional integrity impact was demonstrated.A:NNo availability impact was demonstrated.References
- Microsoft FHIR Server Repository
- ImportController.cs (input.url validator)
- GetImportRequestHandler.cs (diagnostic reflection)
- Azure Health Data Services: configure $import (network options)
- PR #5536 (fix: Restrict Import to Configured Storage Account)
- Azure Health Data Services: FHIR service overview
- Related: Managed Identity token exfiltration via the same validator gap
How We Can Help
Who We Are
The security researchers behind this advisory.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec Researcher
I evaluate your SaMD with the same industry-defining security insight I contributed to the BAK MV for the revision of the B3S standard.
- PhD on Hospital Cybersecurity
- Critical vulnerabilities found in hospital systems
- Alumni of THB MedSec Research Group
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
As a former CTO and developer turned pentester, I work alongside your team to uncover vulnerabilities and find solutions that fit your architecture.
- 20+ years as CTO, 50M+ app downloads
- Architected and secured large-scale IoT fleets
- Certified Web Exploitation Specialist
- gematik Security Hero
Looking for a Penetration Test?
Machine Spirits specializes in security assessments for medical devices and healthcare IT. From MDR penetration testing to C5 cloud compliance, we help MedTech companies meet regulatory requirements.