CVE-2026-12473: OHIF Token Theft via SSRF in DICOMWebProxy and DICOMJSON

Technical summary

CVE-2026-12473 is a Server-Side Request Forgery (SSRF) variant classified under CWE-918 (Server-Side Request Forgery) that exploits insufficient input validation in OHIF's DICOMWebProxy and DICOMJSON data sources. These components accept arbitrary URL parameters without sanitization and pass them to backend request logic. The critical detail is the interaction with OHIF's global authentication service: when these data sources make outbound requests to the attacker-supplied URL, the authentication middleware automatically injects the current user's OIDC (OpenID Connect) Bearer token into the HTTP headers. This token, issued by the organization's identity provider, is then transmitted to the attacker's server, resulting in token exfiltration. The vulnerability requires user interaction (the victim must click a crafted link or visit a page with a malicious parameter), but no additional authentication or special privileges are needed to create the attack vector. The CVSS 3.1 score of 8.2 reflects high confidentiality impact (token exposure), low integrity impact (no data modification), and no availability impact.

Business impact

For healthcare organizations relying on OHIF for diagnostic imaging workflows, this vulnerability poses a direct threat to user account security and potential lateral movement risk. Compromised OIDC tokens can be replayed to access other systems integrated with the same identity provider, potentially affecting EHR systems, PACS (Picture Archiving and Communication System) access, or administrative portals. The attack is silent—users will not notice token exfiltration—making detection and containment difficult. Regulatory implications are significant: HIPAA-covered entities must report unauthorized access to PHI; token theft could trigger breach notification obligations. Additionally, supply chain trust is affected if OHIF instances are hosted by imaging service providers serving multiple healthcare organizations, as a single exploitation could compromise credentials across multiple clients.

Affected systems

OHIF deployments configured to use either DICOMWebProxy or DICOMJSON as their data source are vulnerable in their default state. The vulnerability does not affect OHIF instances using the standard DICOMweb data source. Vulnerable versions are those released prior to the patch; no specific version range is confirmed in the advisory, so organizations must verify against the vendor's security guidance. The attack surface includes any OHIF interface accessible to users (web browser, embedded in EHR systems, or standalone diagnostic workstations). Multi-tenant OHIF deployments or those exposed on public networks face heightened risk due to broader attacker reach.

Exploitability

This vulnerability requires user interaction—an attacker must trick a user into clicking a link containing a malicious URL parameter or visiting a compromised page that embeds such a request. However, no special authentication, admin access, or complex technical steps are required to craft the exploit. A simple URL manipulation is sufficient. The attack succeeds silently; the victim's browser will fetch the malicious resource and transmit the token without visual indication of compromise. The network accessibility (AV:N) is unrestricted, and no special configuration or conditions (AC:L) are needed, making exploitation straightforward for a non-sophisticated attacker. The severity is bounded only by the user interaction requirement and the fact that only authentication credentials (not patient data directly) are exposed, though those credentials can lead to further compromise.

Remediation

Organizations using OHIF must immediately identify instances configured with DICOMWebProxy or DICOMJSON data sources and prioritize patching. The vendor has released security updates; apply them to all affected deployments without delay. As an interim mitigation, if patching cannot be immediately applied, restrict network egress from OHIF servers to only explicitly whitelisted destinations, blocking unexpected outbound connections. Additionally, implement Content Security Policy (CSP) headers to restrict the domains from which OHIF can load resources and to which it can send data. Review OIDC token configuration to implement token binding or short-lived token rotation policies, reducing the window of compromise for stolen tokens. Organizations should audit logs for suspicious outbound requests from OHIF instances and check for token replay activities on their identity provider.

Patch guidance

Apply vendor-supplied security patches to all OHIF instances using DICOMWebProxy or DICOMJSON data sources. Verify patch versions against the vendor's official security advisory to ensure you are deploying the correct release. Test patches in a non-production environment before rolling out to clinical workflows to ensure compatibility with existing imaging workflows and integrations. If OHIF is deployed via containerization or cloud platforms, rebuild images with the patched version and redeploy containers. For on-premises installations, follow the vendor's documented upgrade process. After patching, rotate any OIDC tokens that may have been exposed during the vulnerability window; consult your identity provider's token revocation and re-issuance procedures. Document patch deployment dates and versions for compliance auditing.

Detection guidance

Monitor OHIF server logs and network traffic for anomalous outbound connections initiated from the OHIF application, particularly to unexpected external domains. Check authentication provider logs for token usage anomalies (tokens used from unusual geographic locations, IP addresses, or at unusual times). Implement network intrusion detection signatures that flag outbound requests from OHIF servers to non-whitelisted destinations. Review HTTP request logs for URL parameters that might indicate exploitation attempts (unusual URL schemes, suspicious domain parameters, or obfuscated payloads). Correlate OHIF request logs with identity provider token issuance and usage logs to identify potential token exfiltration patterns. If deploying before patch availability, establish baseline network behavior for your OHIF instances and alert on deviations.

Why prioritize this

This vulnerability scores 8.2 (HIGH) and should be addressed immediately. The combination of unauthenticated access, broad user interaction (any user of OHIF can be targeted), and direct credential exposure creates significant risk. Unlike many SSRF vulnerabilities that target internal services, this one exfiltrates authentication credentials to external attackers, directly enabling account takeover and lateral movement. The healthcare context adds regulatory and operational urgency: imaging workflows are often time-critical, and compromise can disrupt diagnostics. The fact that standard DICOMweb data sources are unaffected provides a clear technical path forward for remediation. For organizations using vulnerable data sources, this is a critical patch priority.

Risk score, explained

The CVSS 3.1 score of 8.2 reflects: (1) High confidentiality impact—authenticated user credentials are directly exposed to an attacker; (2) Low integrity impact—the vulnerability itself does not modify data, but stolen tokens could be used to do so elsewhere; (3) No availability impact—OHIF and its imaging services remain operational; (4) Network accessibility with no authentication required for exploitation—an attacker need not be inside the network or authenticated to the OHIF platform itself; (5) Low complexity—straightforward URL parameter injection; (6) Required user interaction—a user must visit a malicious link, limiting the attack scope; (7) Changed scope—the impact extends beyond the vulnerable component (tokens can be used on other systems). The score appropriately captures the severity of credential theft while acknowledging the practical constraint of user interaction.

Frequently asked questions