CISA published an Industrial Control Systems medical advisory on June 25, 2026, warning that OHIF Viewers DICOM framework versions up to and including 3.12.0 can leak an authenticated clinician’s OIDC bearer token through crafted links in certain custom integrations. The flaw, tracked as CVE-2026-12473, is not the kind of bug that melts down a hospital by itself. It is more uncomfortable than that: a configuration-shaped vulnerability in the connective tissue between web identity, medical imaging, and clinical workflow. In healthcare IT, that is often where the real blast radius begins.
The vulnerable component is the Open Health Imaging Foundation’s OHIF DICOM Web Viewer Framework, a widely used open-source base for browser-based medical imaging applications. OHIF is not merely a viewer in the old desktop sense; it is a configurable web application that many organizations adapt, embed, and wire into their own archives, identity providers, research platforms, and clinical portals.
That flexibility is the point of the project. It is also why this advisory matters. CVE-2026-12473 is not described as a vulnerability in the core DICOMweb data sources that many operators may think of first. Instead, the problem sits in two data sources shipped in the default configuration, DICOMWebProxy and DICOMJSON, which could fetch an arbitrary URL parameter without sufficient validation.
The dangerous interaction comes from authentication. In authenticated OHIF deployments, the global authentication service can automatically inject the clinician’s OpenID Connect bearer token into outgoing requests. If a crafted link causes the affected data source to fetch an attacker-controlled URL, that token can be sent to the attacker’s server.
That turns what might sound like a familiar server-side request forgery issue into something more clinically consequential. The attacker is not merely bouncing a request through a trusted component. The attacker may be collecting a live credential belonging to a signed-in medical user.
Hospitals, imaging centers, research networks, and vendors routinely customize viewers. They add single sign-on, route studies from multiple archives, embed viewers in portals, connect to PACS and VNA infrastructure, and adjust configuration files to suit a local workflow that predates the web application by years. Those integrations are exactly where assumptions about origins, tokens, and URL parameters tend to get complicated.
The affected versions are OHIF DICOM Web Viewer Framework 3.12.0 and earlier. The maintainer fixed the issue and released version 3.12.2 on May 18, 2026, more than a month before CISA’s June 25 advisory. That chronology is important. This is not a “no patch available” disclosure; it is a “patch exists, now find your customized deployments” disclosure.
For large healthcare environments, that second sentence is usually the hard part. An OHIF-based viewer might be deployed as a container, bundled by a vendor, embedded in a research platform, copied into a staging portal, or forked into a private clinical tool. The vulnerability is specific, but the asset-management problem is broad.
In traditional SSRF scenarios, defenders worry about internal metadata services, cloud credentials, private APIs, or network pivoting. In this OHIF case, the most striking element is token forwarding. A clinician’s authenticated context is accidentally attached to a request shaped by the attacker.
That distinction explains the severity. CISA lists a CVSS v3.1 score of 8.2, high severity, with network attack vector, low complexity, no privileges required, and user interaction required. The CVSS v4.0 score is 8.3, also high. The required click matters, but it does not make the bug low risk in a clinical environment where users move quickly, open links from scheduling systems, messaging platforms, patient portals, shared worklists, and email.
The confidentiality impact is the center of gravity. A stolen bearer token may allow access until it expires or is revoked, depending on the identity provider and application design. In the worst case, it could expose patient imaging data or clinical metadata through whatever APIs the token authorizes.
The integrity impact is lower, but not irrelevant. Imaging systems are part of diagnostic workflow, and even limited unauthorized access can create audit, privacy, and operational consequences. In healthcare, a “read-only” compromise is still a breach if it exposes protected health information.
The failure occurs at the seam. If a URL parameter can point to an arbitrary origin, and the application automatically adds an Authorization header, the browser becomes a courier for a secret. The clinician sees a link; the attacker sees a token.
This is why web security guidance often sounds repetitive about allowlists, origin checks, and rejecting user-controlled destinations. The same-origin policy is a powerful browser boundary, but applications can punch holes through it by design. When those holes are configurable, the security model moves from browser enforcement to deployment discipline.
The OHIF fix reflects that reality. Operators who need DICOMWebProxy or DICOMJSON in authenticated deployments must configure a new allowlist setting,
But shared foundations create shared responsibilities. The organizations most likely to benefit from OHIF’s flexibility are also the ones most likely to have nonstandard deployments. They may have custom data sources, legacy archives, reverse proxies, federated authentication, or research systems that use imaging data outside a conventional radiology workflow.
That is where the maintenance cost shows up. “Upgrade to 3.12.2 or later” is the clean recommendation, but many operators cannot simply pull a new image and declare victory. They need to verify whether their custom app configuration still works, whether the data sources are used, whether authentication flows behave correctly, and whether any cross-origin dependencies now fail closed.
That inconvenience should not be treated as optional. The vulnerable behavior involves bearer-token exposure, not a cosmetic defect. If the viewer is authenticated and those affected data sources are enabled unnecessarily, removing them is not merely hardening. It is reducing the number of ways a clinical identity can be exfiltrated.
That webification has benefits. It makes imaging more accessible, especially across departments and locations. It supports research platforms, AI pipelines, and remote consultation. It reduces the dependency on local installs and specialized endpoints.
It also means a crafted link can become part of the threat model. The same phishing and social engineering risks that haunt enterprise SaaS now apply to imaging workflows. A radiologist, oncologist, surgeon, or technologist may not think of a viewer launch URL as a credential boundary, but in a modern authenticated web app, it can be exactly that.
CISA’s general advice follows the familiar ICS pattern: minimize network exposure, segment systems behind firewalls, isolate control networks from business networks, use secure remote access, keep VPNs patched, and perform impact analysis before defensive changes. Some of that language is broader than this particular bug. Still, the principle fits: clinical systems should not be casually reachable, and imaging applications should not be treated as ordinary web front ends just because they run in a browser.
The more practical guidance for this issue is narrower. Find OHIF deployments. Determine whether they are authenticated. Identify use of DICOMWebProxyDataSource and DICOMJSONDataSource. Upgrade. Remove unused configurations. Add explicit allowlists only where authenticated cross-origin fetches are truly required.
But defenders should pay attention to the mitigation language. Operators who need the affected data sources in authenticated environments must configure the new allowlist. Users running OHIF with authentication should remove all unused DicomWebProxyDataSource and DicomJSONDataSource configurations from the deployed configuration file.
That second sentence is doing a lot of work. Many production incidents begin with features that were left enabled because they were part of a sample configuration, a development setup, a migration path, or a “we might need this later” integration. Default-shipped capabilities become risks when they are not matched to actual use.
The advisory also says DICOMweb data sources are not impacted. That matters because it prevents overcorrection. Administrators do not need to treat every OHIF data path as equally vulnerable, and panic-driven disablement can disrupt clinical access. The goal is targeted remediation: upgrade the framework, constrain authenticated cross-origin behavior, and remove the affected unused data-source configurations.
A good patch window for this bug should therefore include both software and configuration review. If an organization merely updates a container but leaves a permissive integration pattern intact elsewhere, it may not have reduced risk as much as it thinks. Conversely, if an operator removes unused vulnerable data sources while planning a tested upgrade, it can lower exposure quickly.
Clinicians and imaging staff routinely interact with links that launch studies, open worklists, or deep-link into patient contexts. Links are part of the workflow, not a suspicious exception. Attackers know this. A phishing message that looks like a study review request, a shared case, or a portal notification may be more plausible in a healthcare environment than a generic password-reset lure.
CISA says it has no reports of known public exploitation specifically targeting this vulnerability at the time of publication. That is welcome, but it is not a reason to defer remediation. Once an advisory explains the affected components and the token-leak mechanism, defenders should assume capable attackers can understand the path.
The more subtle danger is that exploitation may not produce obvious symptoms. A clinician clicks a link, the viewer behavior may fail or look unremarkable, and the attacker receives a token. Unless organizations are logging unusual outbound requests, suspicious origins, token use from unexpected locations, or abnormal API access patterns, detection may be difficult after the fact.
This is where identity controls matter. Short-lived access tokens, refresh-token safeguards, audience restrictions, conditional access, anomalous sign-in detection, and rapid revocation all reduce the impact of token theft. The application bug is in OHIF, but the blast radius is governed by the identity architecture around it.
The affected product line is specific: OHIF DICOM Web Viewer Framework version 3.12.0 and earlier. But version checks alone are insufficient if the application has been forked, backported, or bundled by a downstream product. Administrators should ask vendors directly whether their viewer uses OHIF, which version it includes, and whether DICOMWebProxy or DICOMJSON configurations are enabled in authenticated contexts.
The most important distinction is authenticated versus unauthenticated deployment. The token theft mechanism depends on the global authentication service injecting an OIDC bearer token. Unauthenticated viewers may still deserve patching, but they do not carry the same credential-exfiltration risk described in the advisory.
Where authenticated cross-origin fetches are needed, the new allowlist should be treated as a narrow exception list, not a broad compatibility bucket. Bare origins should be enumerated deliberately, reviewed, and tied to an operational owner. If an origin is not required for patient care, research workflow, or a supported integration, it should not be present.
This is also an opportunity to review logs. Organizations can look for historical requests from OHIF deployments to unusual external origins, especially around viewer launch URLs containing suspicious
A radiologist opening an OHIF viewer in Edge on a managed Windows workstation is part of this threat model. So is a sysadmin reviewing IIS or reverse-proxy rules, a security engineer tuning Microsoft Entra ID conditional access, or a desktop team investigating whether a suspicious link was clicked from Outlook or Teams. The viewer is web software, but the environment around it is the Windows enterprise.
The response should therefore not be siloed as an “imaging team” issue. Identity administrators need to understand whether stolen bearer tokens would be useful outside the original browser session. Endpoint teams should ensure browser and email protections are not bypassed for clinical convenience. Network teams should know which origins the viewer is legitimately allowed to contact.
Healthcare IT often fragments responsibility because the systems are specialized. PACS teams know imaging. Identity teams know tokens. Desktop teams know endpoints. Security teams know phishing. CVE-2026-12473 sits directly across those boundaries, which is why it deserves more attention than its narrow component name might suggest.
CISA and the maintainer recommend removing all unused DicomWebProxyDataSource and DicomJSONDataSource configurations from authenticated deployments. That is a strong hint about how these risks persist. Features that are not needed in production should not remain available in production merely because they shipped, tested, or helped during integration.
This principle is especially important for healthcare environments, where change control can accidentally preserve insecure defaults. Teams are understandably reluctant to touch a working imaging system. But untouched configurations age into unknown configurations, and unknown configurations become the attack surface nobody owns.
The “dangerously” prefix in the new allowlist setting is not theater. It is a reminder that cross-origin authenticated fetches deserve explicit justification. If the viewer must fetch configuration or data across origins while carrying authentication, that relationship should be documented, monitored, and periodically revalidated.
The patch gives administrators a safer mechanism. It does not absolve them from deciding which origins deserve trust.
The concrete lessons are refreshingly direct:
A Medical Viewer Bug Becomes an Identity Problem
The vulnerable component is the Open Health Imaging Foundation’s OHIF DICOM Web Viewer Framework, a widely used open-source base for browser-based medical imaging applications. OHIF is not merely a viewer in the old desktop sense; it is a configurable web application that many organizations adapt, embed, and wire into their own archives, identity providers, research platforms, and clinical portals.That flexibility is the point of the project. It is also why this advisory matters. CVE-2026-12473 is not described as a vulnerability in the core DICOMweb data sources that many operators may think of first. Instead, the problem sits in two data sources shipped in the default configuration, DICOMWebProxy and DICOMJSON, which could fetch an arbitrary URL parameter without sufficient validation.
The dangerous interaction comes from authentication. In authenticated OHIF deployments, the global authentication service can automatically inject the clinician’s OpenID Connect bearer token into outgoing requests. If a crafted link causes the affected data source to fetch an attacker-controlled URL, that token can be sent to the attacker’s server.
That turns what might sound like a familiar server-side request forgery issue into something more clinically consequential. The attacker is not merely bouncing a request through a trusted component. The attacker may be collecting a live credential belonging to a signed-in medical user.
The Highest-Risk Systems Are the Customized Ones
CISA’s wording is careful: successful exploitation in a “custom integration version” could let an attacker steal an authenticated clinician’s token through a crafted link. That phrasing should not lull anyone into assuming the issue is academic. Healthcare software rarely runs in a pristine upstream configuration for long.Hospitals, imaging centers, research networks, and vendors routinely customize viewers. They add single sign-on, route studies from multiple archives, embed viewers in portals, connect to PACS and VNA infrastructure, and adjust configuration files to suit a local workflow that predates the web application by years. Those integrations are exactly where assumptions about origins, tokens, and URL parameters tend to get complicated.
The affected versions are OHIF DICOM Web Viewer Framework 3.12.0 and earlier. The maintainer fixed the issue and released version 3.12.2 on May 18, 2026, more than a month before CISA’s June 25 advisory. That chronology is important. This is not a “no patch available” disclosure; it is a “patch exists, now find your customized deployments” disclosure.
For large healthcare environments, that second sentence is usually the hard part. An OHIF-based viewer might be deployed as a container, bundled by a vendor, embedded in a research platform, copied into a staging portal, or forked into a private clinical tool. The vulnerability is specific, but the asset-management problem is broad.
SSRF Is the Wrong Acronym to Underestimate
CISA maps the issue to CWE-918, server-side request forgery. The acronym SSRF has become so common in security advisories that it risks sounding generic, but this case shows why it remains dangerous in modern web stacks. The vulnerability is not simply that software can be tricked into fetching a URL. It is that the request may carry trust the attacker should never receive.In traditional SSRF scenarios, defenders worry about internal metadata services, cloud credentials, private APIs, or network pivoting. In this OHIF case, the most striking element is token forwarding. A clinician’s authenticated context is accidentally attached to a request shaped by the attacker.
That distinction explains the severity. CISA lists a CVSS v3.1 score of 8.2, high severity, with network attack vector, low complexity, no privileges required, and user interaction required. The CVSS v4.0 score is 8.3, also high. The required click matters, but it does not make the bug low risk in a clinical environment where users move quickly, open links from scheduling systems, messaging platforms, patient portals, shared worklists, and email.
The confidentiality impact is the center of gravity. A stolen bearer token may allow access until it expires or is revoked, depending on the identity provider and application design. In the worst case, it could expose patient imaging data or clinical metadata through whatever APIs the token authorizes.
The integrity impact is lower, but not irrelevant. Imaging systems are part of diagnostic workflow, and even limited unauthorized access can create audit, privacy, and operational consequences. In healthcare, a “read-only” compromise is still a breach if it exposes protected health information.
The Browser Did What It Was Told
One reason this class of bug keeps returning is that every individual piece can look reasonable in isolation. OHIF supports configurable data sources because medical imaging deployments vary. OIDC bearer tokens are injected because authenticated data access should be seamless. URL-driven configuration can simplify launch workflows. Cross-origin connections are sometimes necessary because PACS, archives, identity providers, and viewers do not always live under one neat hostname.The failure occurs at the seam. If a URL parameter can point to an arbitrary origin, and the application automatically adds an Authorization header, the browser becomes a courier for a secret. The clinician sees a link; the attacker sees a token.
This is why web security guidance often sounds repetitive about allowlists, origin checks, and rejecting user-controlled destinations. The same-origin policy is a powerful browser boundary, but applications can punch holes through it by design. When those holes are configurable, the security model moves from browser enforcement to deployment discipline.
The OHIF fix reflects that reality. Operators who need DICOMWebProxy or DICOMJSON in authenticated deployments must configure a new allowlist setting,
dangerouslyAllowedOriginsForAuthenticatedEnvironments, in app-config.js. The name is unusually blunt, and that is good engineering communication. It tells administrators that allowing authenticated cross-origin fetches is not a casual compatibility switch.Healthcare’s Open-Source Advantage Has a Maintenance Cost
OHIF’s prominence is not an accident. Web-based DICOM viewing solves real problems: zero-footprint access, easier integration into portals, browser-native workflows, and a path away from thick-client imaging tools that are harder to deploy and patch. Its open-source model also gives researchers, vendors, and institutions a shared foundation instead of requiring every group to reinvent a medical viewer.But shared foundations create shared responsibilities. The organizations most likely to benefit from OHIF’s flexibility are also the ones most likely to have nonstandard deployments. They may have custom data sources, legacy archives, reverse proxies, federated authentication, or research systems that use imaging data outside a conventional radiology workflow.
That is where the maintenance cost shows up. “Upgrade to 3.12.2 or later” is the clean recommendation, but many operators cannot simply pull a new image and declare victory. They need to verify whether their custom app configuration still works, whether the data sources are used, whether authentication flows behave correctly, and whether any cross-origin dependencies now fail closed.
That inconvenience should not be treated as optional. The vulnerable behavior involves bearer-token exposure, not a cosmetic defect. If the viewer is authenticated and those affected data sources are enabled unnecessarily, removing them is not merely hardening. It is reducing the number of ways a clinical identity can be exfiltrated.
CISA’s ICS Framing Is a Warning About Where Imaging Now Lives
CISA placed the advisory in the healthcare and public health critical infrastructure context, with worldwide deployment and a U.S.-based vendor headquarters. That may seem bureaucratic, but it reflects an important shift. Medical imaging viewers are no longer isolated workstation utilities. They are web applications connected to identity systems, archives, cloud services, and clinical operations.That webification has benefits. It makes imaging more accessible, especially across departments and locations. It supports research platforms, AI pipelines, and remote consultation. It reduces the dependency on local installs and specialized endpoints.
It also means a crafted link can become part of the threat model. The same phishing and social engineering risks that haunt enterprise SaaS now apply to imaging workflows. A radiologist, oncologist, surgeon, or technologist may not think of a viewer launch URL as a credential boundary, but in a modern authenticated web app, it can be exactly that.
CISA’s general advice follows the familiar ICS pattern: minimize network exposure, segment systems behind firewalls, isolate control networks from business networks, use secure remote access, keep VPNs patched, and perform impact analysis before defensive changes. Some of that language is broader than this particular bug. Still, the principle fits: clinical systems should not be casually reachable, and imaging applications should not be treated as ordinary web front ends just because they run in a browser.
The more practical guidance for this issue is narrower. Find OHIF deployments. Determine whether they are authenticated. Identify use of DICOMWebProxyDataSource and DICOMJSONDataSource. Upgrade. Remove unused configurations. Add explicit allowlists only where authenticated cross-origin fetches are truly required.
The Patch Fixes Code, Not Local Assumptions
The maintainer’s fix landed in the OHIF project and was released as version 3.12.2. According to the advisory, the relevant fixes are associated with OHIF/Viewers pull requests on master and the 3.12 release branch. That is the software supply chain working as designed: report, patch, release, disclose.But defenders should pay attention to the mitigation language. Operators who need the affected data sources in authenticated environments must configure the new allowlist. Users running OHIF with authentication should remove all unused DicomWebProxyDataSource and DicomJSONDataSource configurations from the deployed configuration file.
That second sentence is doing a lot of work. Many production incidents begin with features that were left enabled because they were part of a sample configuration, a development setup, a migration path, or a “we might need this later” integration. Default-shipped capabilities become risks when they are not matched to actual use.
The advisory also says DICOMweb data sources are not impacted. That matters because it prevents overcorrection. Administrators do not need to treat every OHIF data path as equally vulnerable, and panic-driven disablement can disrupt clinical access. The goal is targeted remediation: upgrade the framework, constrain authenticated cross-origin behavior, and remove the affected unused data-source configurations.
A good patch window for this bug should therefore include both software and configuration review. If an organization merely updates a container but leaves a permissive integration pattern intact elsewhere, it may not have reduced risk as much as it thinks. Conversely, if an operator removes unused vulnerable data sources while planning a tested upgrade, it can lower exposure quickly.
The Crafted Link Is the Social Engineering Layer
The exploit path requires user interaction. In the language of CVSS, that reduces automation. In the language of hospital operations, it is still a credible scenario.Clinicians and imaging staff routinely interact with links that launch studies, open worklists, or deep-link into patient contexts. Links are part of the workflow, not a suspicious exception. Attackers know this. A phishing message that looks like a study review request, a shared case, or a portal notification may be more plausible in a healthcare environment than a generic password-reset lure.
CISA says it has no reports of known public exploitation specifically targeting this vulnerability at the time of publication. That is welcome, but it is not a reason to defer remediation. Once an advisory explains the affected components and the token-leak mechanism, defenders should assume capable attackers can understand the path.
The more subtle danger is that exploitation may not produce obvious symptoms. A clinician clicks a link, the viewer behavior may fail or look unremarkable, and the attacker receives a token. Unless organizations are logging unusual outbound requests, suspicious origins, token use from unexpected locations, or abnormal API access patterns, detection may be difficult after the fact.
This is where identity controls matter. Short-lived access tokens, refresh-token safeguards, audience restrictions, conditional access, anomalous sign-in detection, and rapid revocation all reduce the impact of token theft. The application bug is in OHIF, but the blast radius is governed by the identity architecture around it.
The Real Inventory Is the Configuration File
The immediate work for IT teams is not glamorous. It is finding every deployedapp-config.js and every derivative configuration that may enable the vulnerable data sources. In a small environment, that may be straightforward. In a large health system, it may involve container registries, vendor-managed appliances, research servers, departmental tools, and old proof-of-concept deployments that quietly became operational.The affected product line is specific: OHIF DICOM Web Viewer Framework version 3.12.0 and earlier. But version checks alone are insufficient if the application has been forked, backported, or bundled by a downstream product. Administrators should ask vendors directly whether their viewer uses OHIF, which version it includes, and whether DICOMWebProxy or DICOMJSON configurations are enabled in authenticated contexts.
The most important distinction is authenticated versus unauthenticated deployment. The token theft mechanism depends on the global authentication service injecting an OIDC bearer token. Unauthenticated viewers may still deserve patching, but they do not carry the same credential-exfiltration risk described in the advisory.
Where authenticated cross-origin fetches are needed, the new allowlist should be treated as a narrow exception list, not a broad compatibility bucket. Bare origins should be enumerated deliberately, reviewed, and tied to an operational owner. If an origin is not required for patient care, research workflow, or a supported integration, it should not be present.
This is also an opportunity to review logs. Organizations can look for historical requests from OHIF deployments to unusual external origins, especially around viewer launch URLs containing suspicious
url parameters. Perfect retrospective detection may not be possible, but targeted log review can at least surface obvious signs of probing.Windows Shops Should Not Tune This Out
WindowsForum readers may wonder why a web-based DICOM viewer belongs in a Windows-focused publication. The answer is simple: Windows remains deeply embedded in clinical endpoint fleets, identity environments, administrative tooling, and the operational reality of healthcare IT. Even when the vulnerable application is containerized or hosted on Linux, the users, browsers, SSO policies, endpoint controls, and incident response workflows often run through Windows-heavy infrastructure.A radiologist opening an OHIF viewer in Edge on a managed Windows workstation is part of this threat model. So is a sysadmin reviewing IIS or reverse-proxy rules, a security engineer tuning Microsoft Entra ID conditional access, or a desktop team investigating whether a suspicious link was clicked from Outlook or Teams. The viewer is web software, but the environment around it is the Windows enterprise.
The response should therefore not be siloed as an “imaging team” issue. Identity administrators need to understand whether stolen bearer tokens would be useful outside the original browser session. Endpoint teams should ensure browser and email protections are not bypassed for clinical convenience. Network teams should know which origins the viewer is legitimately allowed to contact.
Healthcare IT often fragments responsibility because the systems are specialized. PACS teams know imaging. Identity teams know tokens. Desktop teams know endpoints. Security teams know phishing. CVE-2026-12473 sits directly across those boundaries, which is why it deserves more attention than its narrow component name might suggest.
The Advisory’s Most Important Word Is “Unused”
The easiest mistake after reading this advisory is to focus only on version numbers. Versioning matters, and upgrading to 3.12.2 or later is the baseline. But the more enduring security lesson is about unused capability.CISA and the maintainer recommend removing all unused DicomWebProxyDataSource and DicomJSONDataSource configurations from authenticated deployments. That is a strong hint about how these risks persist. Features that are not needed in production should not remain available in production merely because they shipped, tested, or helped during integration.
This principle is especially important for healthcare environments, where change control can accidentally preserve insecure defaults. Teams are understandably reluctant to touch a working imaging system. But untouched configurations age into unknown configurations, and unknown configurations become the attack surface nobody owns.
The “dangerously” prefix in the new allowlist setting is not theater. It is a reminder that cross-origin authenticated fetches deserve explicit justification. If the viewer must fetch configuration or data across origins while carrying authentication, that relationship should be documented, monitored, and periodically revalidated.
The patch gives administrators a safer mechanism. It does not absolve them from deciding which origins deserve trust.
The Practical Reading for OHIF Operators Is Narrow but Urgent
This is not a reason to abandon OHIF, nor is it evidence that browser-based medical imaging is inherently unsafe. It is a reminder that open, extensible clinical software inherits the same web security constraints as every other modern application, with higher consequences when the data is medical and the users are clinicians.The concrete lessons are refreshingly direct:
- Organizations running OHIF DICOM Web Viewer Framework 3.12.0 or earlier should upgrade to version 3.12.2 or later.
- Authenticated deployments should be reviewed specifically for DICOMWebProxyDataSource and DICOMJSONDataSource usage.
- Unused affected data-source configurations should be removed from the deployed configuration, not merely ignored.
- Sites that require those data sources with authentication should configure a narrow
dangerouslyAllowedOriginsForAuthenticatedEnvironmentsallowlist inapp-config.js. - Security teams should treat suspicious viewer launch links as potential credential-theft attempts, not just nuisance phishing.
- Identity logs, proxy logs, and application logs should be checked for unexpected OHIF-originated requests to unfamiliar external hosts.
References
- Primary source: CISA
Published: 2026-06-25T12:00:00+00:00
OHIF Viewers DICOM | CISA
www.cisa.gov
- Related coverage: docs.ohif.org
Authorization and Authentication | OHIF
The OHIF Viewer can be configured to work with authorization servers that support one or more of the OpenID-Connect authorization flows. The Viewer finds it's OpenID-Connect settings on the oidc configuration key. You can set these values in your configuration files. For instance you can take a...docs.ohif.org
- Related coverage: newreleases.io
- Official source: github.com
GitHub - OHIF/Viewers: OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages · GitHub
OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages - OHIF/Viewers
github.com
- Related coverage: ohif.org
- Related coverage: v2.docs.ohif.org
- Related coverage: v3p8.docs.ohif.org
- Related coverage: hub.docker.com
ohif/viewer - Docker Image
hub.docker.com
- Related coverage: docs.oracle.com
- Related coverage: dicom.nema.org
