CVE-2026-49120: Medplum SSRF via FHIR Subscription – Healthcare Data & Credentials at Risk
Medplum versions before 5.1.14 contain a vulnerability that allows authenticated users to make the server reach out to internal network addresses and systems that should be isolated. An attacker with valid credentials can create subscription configurations that trick the system into fetching or sending data to sensitive internal targets like cloud credential stores or databases. This enables attackers to steal credentials and patient health information that would normally only be accessible to administrators.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
- Weaknesses (CWE)
- CWE-918
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-02 / 2026-06-17
NVD description (verbatim)
Medplum before 5.1.14 contains a server-side request forgery vulnerability in the subscription worker that allows authenticated users to perform unauthorized internal network requests by creating FHIR Subscription resources with arbitrary endpoint URLs. Attackers can point subscription endpoints at internal addresses such as cloud instance metadata services, internal databases, or container orchestration endpoints to exfiltrate IAM credentials and patient health records via the POST body containing full FHIR resource payloads.
4 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-49120 is a server-side request forgery (SSRF) vulnerability in Medplum's subscription worker component. The flaw exists because the system does not properly validate endpoint URLs when processing FHIR Subscription resources created by authenticated users. An attacker can exploit this by crafting a Subscription with a malicious endpoint URL pointing to internal resources (e.g., 169.254.169.254 for AWS metadata, internal database IPs, or Kubernetes API endpoints). When the subscription worker processes events, it issues POST requests containing full FHIR resource payloads to the attacker-controlled endpoint, leaking sensitive data including IAM credentials and Protected Health Information (PHI). The vulnerability requires valid authentication to the Medplum instance but does not require administrative privileges, significantly lowering the barrier to exploitation.
Business impact
For healthcare organizations deploying Medplum, this vulnerability creates a direct path to credential and PHI theft. An insider with standard user credentials—or an external attacker with compromised credentials—can access cloud provider metadata services to obtain temporary credentials for lateral movement, or directly query internal databases and orchestration systems. The exfiltration of patient records violates HIPAA and exposes the organization to regulatory fines, reputational damage, and patient notification obligations. In cloud-native deployments (Kubernetes, container registries), this can serve as a pivot point for container escape or supply-chain compromise.
Affected systems
Medplum instances running versions prior to 5.1.14 are affected. The vulnerability requires an authenticated user account, so air-gapped or strictly access-controlled Medplum instances face lower immediate risk. However, any deployment permitting standard user account creation or federated authentication is at risk. Healthcare SaaS providers hosting Medplum on behalf of multiple clients face compounded risk due to cross-tenant implications if subscription resources are not properly isolated.
Exploitability
The barrier to exploitation is moderate. An attacker needs valid authentication credentials (username/password, API key, or federated identity) to create a malicious Subscription resource. However, this does not require administrative access, and many healthcare deployments distribute user accounts freely to clinicians, billing staff, and administrative personnel. Once authenticated, the attacker can create a Subscription in seconds through the standard FHIR API. The subscription worker processes events asynchronously; exploitation does not require real-time interaction, making detection challenging. No patch installation or complex infrastructure is needed on the attacker side—only a listening endpoint to receive exfiltrated data.
Remediation
Upgrade Medplum to version 5.1.14 or later immediately. The fix likely includes URL validation to reject internal IP ranges (RFC 1918 addresses, 127.0.0.1, 169.254.x.x) and enforcement of allow-listing for Subscription endpoints. Pending patching, organizations should review subscription resource configurations and delete any with suspicious or internal endpoints. Implement strict network segmentation to prevent the Medplum server from accessing internal resources; use egress firewall rules and proxy-based controls to block outbound connections to internal IP ranges, cloud metadata services, and orchestration APIs.
Patch guidance
Verify the version of your Medplum deployment (check startup logs or the admin API). If running below 5.1.14, schedule an upgrade in your maintenance window. Consult the Medplum release notes for 5.1.14 to confirm the fix is included and identify any breaking changes. Test the upgrade in a development environment against your FHIR client integrations before production rollout. After upgrading, audit existing Subscription resources in your database for any with unexpected or internal endpoint URLs; remove or disable them.
Detection guidance
Monitor outbound network traffic from Medplum processes for POST requests to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata services (169.254.169.254, 169.254.169.253). Audit FHIR Subscription creation and modification events in your application logs, filtering for endpoints that do not match your organization's approved list. Alert on any Subscription with an endpoint containing an internal IP, localhost, or known metadata service address. If your Medplum logs include the POST body or response, search for exfiltrated credential patterns (AWS session tokens, database connection strings, IAM role metadata). Correlation with egress firewall denies may indicate failed exploitation attempts.
Why prioritize this
This vulnerability merits immediate prioritization due to the convergence of high-severity impact (confidentiality breach of PHI and credentials), low attack complexity (standard authenticated user), and the sensitive nature of Medplum deployments. Healthcare organizations face regulatory and reputational consequences that dwarf most software vulnerabilities. The lack of CISA KEV designation does not diminish the actual risk—active exploitation in healthcare supply chains is plausible and likely underreported.
Risk score, explained
The CVSS 3.1 score of 8.5 (HIGH) reflects a network-accessible vulnerability that requires low-privileged authentication but has high confidentiality impact and cross-boundary scope implications (changing trust boundaries via access to internal resources). The score appropriately captures the severity; however, for healthcare organizations, the true business risk is higher due to regulatory obligations and the sensitive nature of the data at stake.
Frequently asked questions
Can an attacker exploit this without a valid Medplum user account?
No. The vulnerability requires authentication. An attacker must have a valid set of credentials (API key, username/password, or federated identity configured in your Medplum instance). However, if your organization permits widespread user creation or uses federated authentication with loose controls, the effective attack surface is broader.
What internal systems are most at risk from this attack?
Cloud metadata services (AWS, Azure, GCP) are the primary target for credential theft. Internal databases, container registries, Kubernetes API servers, and configuration management systems are also high-value targets. Any system reachable from the Medplum network that is not properly segmented is vulnerable.
Does upgrading to 5.1.14 require downtime?
Upgrade procedures depend on your deployment model. Verify against the Medplum release notes and your operational runbook. Many modern deployments support rolling updates with zero downtime, but you should test in a non-production environment first.
If we block outbound network access from Medplum to internal IPs, can we avoid patching?
Network segmentation is a strong complementary control and should be implemented regardless, but it is not a substitute for patching. An attacker with access to a Medplum instance may find alternative exfiltration paths or exploit the presence of overly permissive rules you may have overlooked. Patching addresses the root cause and is mandatory.
This analysis is based on the published CVE description and CVSS assessment. No exploit code or weaponized proof-of-concept is provided. Patch version numbers and affected versions should be verified against the official Medplum security advisory and release notes. CVSS scores reflect standardized severity metrics but do not account for organization-specific risk factors, threat models, or regulatory context. Healthcare organizations must assess this vulnerability against their specific compliance obligations (HIPAA, state breach notification laws, etc.). Test all patches in a non-production environment before production deployment. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2026-10068HIGHSSRF in Shibby Tomato 1.28 miniupnpd (Unmaintained)
- CVE-2026-10107HIGHMoviePilot v2 SSRF in Image Proxy Allows Internal Network Access
- CVE-2026-10280HIGHServer-Side Request Forgery in Horizon921 mcpilot 0.1.0
- CVE-2026-10287HIGHSSRF in SourceCodester SEO Meta Tag Extractor 1.0
- CVE-2026-10771HIGHCRMEB Java SSRF Vulnerability in QR Code Endpoint
- CVE-2026-42398HIGHKibana Webhook SSRF Vulnerability—Egress Allowlist Bypass
- CVE-2026-42965HIGHOpenShift Router SSRF via FQDN EndpointSlice
- CVE-2026-44285HIGHFastGPT SSRF Vulnerability in Dataset Preview Endpoint