LIVE FEED

CISA: every Flow Neuroscience FL-100 tDCS headset shares one hardcoded BLE credential, CVE-2026-18164 rated 8.1 Coalition for Health AI convenes 100 member cyber work group, AI attack and defense playbooks due by year end CRA Article 14 reporting obligations take effect September 11 EU MDR revision proposal adds a 30 day exploited-vulnerability reporting clock via Eudamed Mira hormone monitor cloud API handed session tokens to any password, CVE-2026-68067 rated 9.8 Pulsetto vagus nerve stimulator ships hidden BLE commands: no patch, no vendor response CISA: every Flow Neuroscience FL-100 tDCS headset shares one hardcoded BLE credential, CVE-2026-18164 rated 8.1 Coalition for Health AI convenes 100 member cyber work group, AI attack and defense playbooks due by year end CRA Article 14 reporting obligations take effect September 11 EU MDR revision proposal adds a 30 day exploited-vulnerability reporting clock via Eudamed Mira hormone monitor cloud API handed session tokens to any password, CVE-2026-68067 rated 9.8 Pulsetto vagus nerve stimulator ships hidden BLE commands: no patch, no vendor response

Vulnerability

One AES key, shared across every install of a cardiovascular system

MedDevice Cyber Staff · Mar 13 · 3 min read · Via CISA

Philips IntelliSpace Cardiovascular, versions 4.1 and 5.1 and prior, drew ICSMA-25-072-01. Two CVEs, both 7.7. The auth token is built from a fixed AES-128 key that ships identical across every installation, and separately the Windows login token can be replayed to bypass authentication.

A shared static key means breaking one install breaks all of them. There is no per-customer secret isolating the blast radius, so recover the key once and you can forge tokens against any site running the software. What that buys an attacker is patient cardiovascular records and active sessions. Joe Dillon reported it.

Generate keys per install, store them properly, rotate them. Shipping the same secret to every customer keeps landing on this advisory page because it is convenient to build and impossible to fix after the fact.

Remediation Desk

Philips IntelliSpace Cardiovascular built its auth tokens on a fixed AES-128 key identical across every install and let the login token be replayed to bypass authentication (ICSMA-25-072-01). Apply the fix and, going forward, derive keys per install and bind tokens so they cannot be replayed.

Apply the vendor fix. Update IntelliSpace Cardiovascular to the remediated version from ICSMA-25-072-01.
Use per-install keys. A key shared across every deployment means one recovered key breaks them all; derive a unique key per installation.
Bind tokens against replay. Tie session tokens to time, nonce and session context so a captured token cannot be replayed to bypass login.

Sources

CISA ↗

Questions & Answers

What is wrong with authentication in Philips IntelliSpace Cardiovascular?

ICSMA-25-072-01 covers two flaws, both 7.7, in versions 4.1 and 5.1 and prior. The auth token is built from a fixed AES-128 key that ships identical across every installation, and the Windows login token can be replayed to bypass authentication.

Why is one shared AES key across installs a problem?

Recover the key once and you can forge tokens against any site running the software. There is no per-customer secret to contain the blast radius, and the fix, per-install key generation, cannot be retrofitted quietly.

← Back to Vulnerabilities