Philips’ July advisory run is a lesson in where device risk actually lives

MedDevice Cyber Staff · Aug 11 · 3 min read · Via Philips Product Security

Philips published or updated four advisories between early June and July 30. A Trellix breach response (no Philips products known impacted). The OFFIS DCMTK vulnerabilities. Windows kernel CVE-2026-45657 across Holter, IntelliSpace ECG, ST80i and PIC iX. And the Defender findings, BlueHammer, RedSun and UnDefend, touching IntelliVue and UroNav.

Modern medical systems are assembled as much as they are written. A finished product bundles an operating system, third-party security agents, imaging toolkits and other software the maker integrates but does not maintain. Each layer carries its own defects, and when one surfaces, every product resting on it is exposed.

None of it is Philips code. A monitoring platform inherits the Windows kernel. An ECG cart inherits Defender. Every imaging product inherits DICOM toolkits. Now device makers inherit their security vendors’ breaches too.

That structure creates an obligation buyers often overlook. When an upstream component is found vulnerable, the maker that shipped it has to work out which products contain the code, judge whether the flaw is reachable as configured, and say so plainly, including where a product is clear. Doing that quickly depends on knowing the software bill of materials before the advisory lands.

The kernel RCE reaching PIC iX 4.x is the one to watch. A patient information center is the box a hospital never wants to reboot. Which is exactly where patch lag runs longest.

A single upstream advisory rarely ends the matter. It sets off a slower cascade in which each integrator works through its own catalog and issues follow-on notices as it confirms exposure, some quickly, many never. For a hospital, one underlying flaw can arrive as a scattering of separate advisories across the vendors whose equipment fills a department.

This is what working PSIRT output looks like. Fast, specific, honest about not-impacted. Forty plus large manufacturers publish nothing at all. That gap is the real story.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

None of the July advisories were for a bug the vendor wrote; they were in a security tool, a DICOM toolkit, a Windows kernel path and a Defender bypass that the product depends on. The lesson is that most device risk lives in the supply chain, so track upstream and operating-system exposure with the same rigor as first-party code.

Extend monitoring past your own code. Watch advisories for every third-party component and platform your product runs on, since that is where these four originated.
Keep the SBOM current and queryable. When an upstream advisory drops, you need to answer are we affected in minutes, which requires a live SBOM rather than a one-time export.
Pre-plan platform patch paths. Know in advance how you deliver operating-system and dependency patches to fielded devices so a kernel-level advisory does not strand you.

For Device ManufacturersAm I affected, and how to fix the class

Am I affected?

This class applies to devices with the properties below. Check them against your product to gauge exposure.

Contributing

sys_ots_software sys_named_os parse_image net_remote_access use_hospital_net sys_firmware_update data_phi

EMB3D

PID-23 PID-26

Fix the class in your product

The advisory is not for a bug you wrote; it is in a component you embed. As the maker, pin dependencies to fixed versions, generate an SBOM on every build including transitive components, and gate the pipeline on known-vulnerable components so an advisory maps to your products automatically.

Pin and inventory. Exact versions, and a CycloneDX or SPDX SBOM as a build artifact including transitive deps.
Gate on advisories. A CI scan fails a release carrying a component with a known advisory.
Own the field patch path. Know how you deliver a dependency or platform patch to fielded devices before you need it.

Mapped EMB3D mitigations

← Back to Vulnerabilities