Vulnerability

Philips IntelliVue MX40 WLAN monitors can drop local alarming after 802.11 faults

MedDevice Cyber Staff · Sep 12 · 3 min read · Via CISA ICSMA-17-255-01

CISA published advisory ICSMA-17-255-01 on September 12, 2017, covering the Philips IntelliVue MX40 Patient Worn Monitor, WLAN models only, on software earlier than B.06.18. It lists two vulnerabilities, each with a CVSS v3 base score of 6.5: CVE-2017-9657 (CWE-460, improper cleanup on thrown exception) and CVE-2017-9658 (CWE-755, improper handling of exceptional conditions).

CVE-2017-9657 is a state mismatch. Under specific 802.11 conditions the MX40 can partially re-associate with the central monitoring station. The central station then shows the monitor as disconnected and expects it to fall back to local monitoring with audio and screen on, while the MX40 stays in telemetry mode with audio and screen off.

The clinical consequence is the one the advisory spells out: if the patient has an alarm event and staff expect the MX40 to alarm locally, treatment can be delayed. Nobody has to compromise anything for this to happen. A degraded wireless environment is enough.

CVE-2017-9658 concerns certain 802.11 management messages that trip the access point blacklisting defenses when they should not. The monitor then needs hospital staff to reset it and re-establish its Wi-Fi connection, unless it finds another access point in range. Until reset, it can remain in local monitoring mode.

Philips told CISA it planned an additional MX40 software update in 2017 for the exception handling issue. A telemetry device has to agree with the central station about who is alarming; any state where both sides assume the other one is responsible is a patient safety defect.

Are you a representative of Philips? Submit an official response →

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

Move MX40 WLAN monitors to B.06.18 or later and apply the further Philips update when it ships. Until then, clinical staff should not assume local alarming on an MX40 that the central station shows as disconnected. Check the monitor itself and reset it when it has lost its access point.

Confirm MX40 software versions. List every MX40 WLAN unit and flag any running software earlier than B.06.18.
Brief clinical staff. A disconnected MX40 on the central station needs a bedside check, because the device may still be in telemetry mode with audio and screen off.
Watch wireless health. Track access point blacklisting events and re-association failures on the telemetry WLAN so stuck monitors are found quickly.

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

Am I affected?

This class applies to devices with the signals and properties below. Check them against your product to gauge exposure. The named product rows list what the sources state about the affected product.

Required

Wireless connectivity

Contributing

Hospital network

IntelliVue MX40 Patient Worn Monitor

Wireless connectivity Hospital network

Fix the class in your product

Malformed or excessive input pushes the service over, and on a monitor that means the screen goes dark. As the maker, validate and bound every input at the boundary, handle malformed messages as a defined error path, and watchdog the clinical display so a fault recovers to a safe view.

Validate and bound input. Enforce type, size, and rate limits; null-check before you dereference.
Fail safe. Handle malformed input as a defined error path, never an unchecked dereference.
Watchdog the display. On a monitor, restore the clinical view quickly and safely after a fault.

Mapped EMB3D mitigations

Products potentially also affected

Products whose own public documentation shares this advisory's attributes. A shared attribute is a lead, not a finding. The status column shows only what each manufacturer has said.

Product	Manufacturer	Shared with this advisory	Manufacturer status
Versana Active	GE HealthCare	Same attributes (interface and component types)WiFi, Wireless Module	No feedback feed from manufacturer
iBed Wireless with iBed Mobile	Stryker	Same attributes (interface and component types)WiFi, Wireless Module	No feedback feed from manufacturer
SafeOp 2: Neural Informatix System	Alphatec Spine	Same signals	No feedback feed from manufacturer
Welch Allyn Connex Spot Monitor; 901058 Vital Signs Monitor Core	Baxter	Same signals	No feedback feed from manufacturer
Alphenix, INFX-8000V/B, INFX-8000V/S, V9.5	Canon Medical	Same signals	No feedback feed from manufacturer
Infinity M300	Dräger	Same signals	No feedback feed from manufacturer
Optomed Smartscope M5 with Optomed Smartscope FA	Optomed	Same signals	No feedback feed from manufacturer
Connected OR Hub with Device and Voice Control	Stryker	Same signals	No feedback feed from manufacturer
Solex 7 Intravascular Heat Exchange Catheter	ZOLL	Same signals	No feedback feed from manufacturer

Questions & Answers

What are CVE-2017-9657 and CVE-2017-9658 in the Philips IntelliVue MX40?

They are two exception handling flaws (CWE-460 and CWE-755, CVSS v3 6.5 each) in Philips IntelliVue MX40 Patient Worn Monitors, WLAN only, before software B.06.18, disclosed in CISA advisory ICSMA-17-255-01 on September 12, 2017. One can leave the MX40 in telemetry mode with audio off while the central station expects local alarming; the other can force a staff reset after 802.11 management messages.

Is there a fix for the Philips MX40 WLAN alarm issue?

CISA advisory ICSMA-17-255-01 lists MX40 WLAN software earlier than B.06.18 as affected, and Philips said it planned an additional MX40 software update in 2017 to address CVE-2017-9657 and CVE-2017-9658.

← Back to Vulnerabilities