On August 12, 2026, CISA published ICS Medical Advisory ICSMA-26-225-01 covering CVE-2026-18164, a CVSS v3 8.1 (High) vulnerability in the Flow Neuroscience FL-100 — a transcranial direct current stimulation (tDCS) headset prescribed for at-home treatment of depression. The flaw is stark: an undocumented hard-coded credential, identical across every device unit, is authorized to bypass authentication entirely. A successful exploit allows an attacker within Bluetooth range to arbitrarily manipulate brain stimulation parameters and override built-in safety limits.
Let that land for a moment. This is not a data-exfiltration bug or a privacy exposure. This is a vulnerability class where the impact is measured in patient physiology. The FL-100 is deployed worldwide, sits squarely in the Healthcare and Public Health critical infrastructure sector, and — because it is used by patients at home, in clinics, and in transit — its Bluetooth attack surface is exposed to anyone within radio range: a waiting room, an airport, an apartment building.
For healthcare security teams, biomedical engineering groups, and any organization whose clinicians prescribe or support the FL-100, this advisory demands action now — even before a vendor patch ships.
Technical Analysis
Affected Products
- Flow Neuroscience FL-100 (all versions, per the advisory)
- Halo Neuroscience FL-100 (all versions)
The vendor is Flow Neuroscience, headquartered in Sweden, with devices deployed worldwide. The FL-100 is a prescription tDCS headset that delivers low-intensity electrical current to the prefrontal cortex via electrodes, controlled through a companion mobile application over Bluetooth Low Energy (BLE).
CVE-2026-18164 — Use of Hard-coded Credentials (CWE-798)
- CVSS v3 Base Score: 8.1 (High)
- Vulnerability class: Use of Hard-coded Credentials
The device firmware contains an undocumented credential that is shared by all units — there is no per-device keying. That credential is authorized to bypass the normal BLE authentication flow. In practical terms, this means the confidentiality of the credential is the only thing standing between an attacker and full control of stimulation parameters, and a credential burned into every unit of a consumer-distributed medical device will not stay secret. Firmware extraction from a single unit — or a captured and replayed session — collapses the security model fleet-wide.
From a defender's perspective, the exploitation requirements and attack chain look like this:
- Proximity: The attacker must be within Bluetooth range of an active FL-100 (typically tens of meters for BLE, longer with directional antennas).
- Credential possession: The attacker uses the hard-coded credential — extracted from firmware or obtained once leaked — to authenticate to the device's BLE GATT interface, bypassing the pairing/authentication controls the companion app relies on.
- Parameter manipulation: With authenticated access, the attacker issues commands to alter stimulation session parameters — current intensity, duration, session state — overriding the firmware's safety limits.
The critical detail is the third step: the safety interlocks that cap stimulation amplitude and session length are enforced behind the same authentication boundary the credential bypasses. This is a design failure, not an implementation bug — which means remediation almost certainly requires a firmware update that removes the credential path and re-keys the fleet, not a configuration tweak.
Exploitation Status
- No public proof-of-concept exploit has been confirmed at time of publication.
- CISA has not added CVE-2026-18164 to the Known Exploited Vulnerabilities catalog as of this writing.
- However, hard-coded credential flaws in medical devices have a well-established pattern: credential extraction is trivial for a motivated researcher, and once published, the credential is unchangeable for every unpatched unit in the field. Treat exploitation capability as imminent and low-complexity, not theoretical. The proximity requirement limits scale but does not limit targeted attacks against known patients — a realistic concern for high-profile individuals receiving tDCS therapy.
Detection & Response
This is a firmware-level flaw in a BLE peripheral, so traditional network IDS sees nothing — the attack never touches your LAN. Detection has to happen at the endpoints and clinical workstations an attacker would stage from, and through physical/administrative controls around device usage. The most defensible telemetry: adversaries attacking BLE medical devices at close range will almost always stage from a laptop or SBC running standard BLE reconnaissance and exploitation tooling — gatttool, bluetoothctl/btmgmt, hcitool, bettercap (BLE module), blesuite, or Nordic's nrfutil — and they will often tamper with or restart Bluetooth host services to get raw HCI access. Those behaviors are observable and worth hunting, especially on clinical workstations and any endpoint in proximity to where FL-100 devices are used or charged.
---
title: BLE Reconnaissance or Exploitation Tooling Execution on Clinical Endpoints
id: 3c8f2a14-6b71-4e59-9d02-8f4a1c7e5b3a
status: experimental
description: Detects execution of common Bluetooth Low Energy reconnaissance and manipulation tools (gatttool, bluetoothctl, hcitool, bettercap BLE, blesuite, nrfutil) that could be used to discover and interact with BLE medical devices such as the Flow Neuroscience FL-100 within radio range.
references:
- https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-225-01
- https://attack.mitre.org/techniques/T1200/
author: Security Arsenal
date: 2026/08/13
tags:
- attack.initial_access
- attack.t1200
logsource:
category: process_creation
product: linux
detection:
selection_img:
Image|endswith:
- '/gatttool'
- '/bluetoothctl'
- '/btmgmt'
- '/hcitool'
- '/bettercap'
- '/nrfutil'
selection_cli:
CommandLine|contains:
- 'blesuite'
- 'bleah'
- 'ble.recon'
- 'ble.enum'
- 'ble.write'
condition: selection_img or selection_cli
falsepositives:
- Biomedical engineering staff performing authorized BLE device diagnostics
- IT administrators managing legitimate Bluetooth peripherals
level: high
---
title: Windows Bluetooth Host Service Tampering or Unexpected Pairing Tooling
id: 91d4e7b2-3f68-4a1c-b5d9-2e6c9a4f7d18
status: experimental
description: Detects stopping or disabling of the Windows Bluetooth Support Service (bthserv) or use of command-line Bluetooth device management tooling on endpoints, which may indicate staging for raw radio access to attack nearby BLE medical devices such as the FL-100.
references:
- https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-225-01
- https://attack.mitre.org/techniques/T1562.001/
author: Security Arsenal
date: 2026/08/13
tags:
- attack.defense_evasion
- attack.t1562.001
logsource:
category: process_creation
product: windows
detection:
selection_service:
CommandLine|contains:
- 'bthserv'
CommandLine|contains:
- 'stop'
- 'disable'
- 'disabled'
selection_tools:
Image|endswith:
- '\btpair.exe'
- '\btinfo.exe'
- '\bluetoothview.exe'
condition: selection_service or selection_tools
falsepositives:
- Helpdesk troubleshooting of Bluetooth peripherals
- Biomedical or clinical engineering maintenance activity
level: medium
// Hunt: BLE attack/recon tooling execution across endpoints (Windows + Linux via Defender and Syslog ingestion)
// Relevant to close-range attacks against BLE medical devices (e.g., CVE-2026-18164, Flow FL-100)
let BleToolNames = dynamic(["gatttool", "bluetoothctl", "btmgmt", "hcitool", "bettercap", "nrfutil", "blesuite", "bleah", "btpair.exe", "btinfo.exe", "bluetoothview.exe"]);
let BleCliPatterns = dynamic(["ble.recon", "ble.enum", "ble.write", "blesuite", "bleah"]);
union
(DeviceProcessEvents
| where TimeGenerated > ago(30d)
| extend ProcName = tolower(FileName), Cmd = tolower(ProcessCommandLine)
| where ProcName has_any (BleToolNames) or Cmd has_any (BleCliPatterns)
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, FolderPath
),
(Syslog
| where TimeGenerated > ago(30d)
| extend Cmd = tolower(ProcessName), Msg = tolower(SyslogMessage)
| where Cmd has_any (BleToolNames) or Msg has_any (BleCliPatterns)
| project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage
)
| sort by TimeGenerated desc
-- Hunt: Identify endpoints with BLE attack tooling installed or recently executed
-- Scope: clinical workstations and endpoints near FL-100 usage/charging areas
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(gatttool|bluetoothctl|btmgmt|hcitool|bettercap|nrfutil|blesuite|bleah|btpair|btinfo|bluetoothview)'
OR CommandLine =~ '(?i)(ble\\.recon|ble\\.enum|ble\\.write|blesuite|bleah)'
-- Complementary artifact: enumerate paired Bluetooth devices on Windows endpoints for unauthorized pairing review
SELECT Name, FullPath, Mtime
FROM glob(globs='C:\\Windows\\System32\\config\\systemprofile\\AppData\\Local\\*')
# CVE-2026-18164 - FL-100 Bluetooth exposure: endpoint audit and hardening script
# Run on clinical workstations and any endpoint in FL-100 usage/charging areas.
# PURPOSE: inventory paired Bluetooth devices, review for unauthorized pairings,
# and disable the Bluetooth stack on endpoints that do not require it.
$ReportPath = "$env:ProgramData\FL100-BT-Audit-$(Get-Date -Format 'yyyyMMdd-HHmmss').txt"
"=== Bluetooth Support Service Status ===" | Out-File $ReportPath
Get-Service -Name bthserv -ErrorAction SilentlyContinue |
Select-Object Name, Status, StartType | Format-List | Out-File $ReportPath -Append
"=== Paired Bluetooth Devices (review for unauthorized/unexpected pairings) ===" | Out-File $ReportPath -Append
Get-PnpDevice -Class Bluetooth -ErrorAction SilentlyContinue |
Select-Object FriendlyName, Status, InstanceId | Format-Table -AutoSize | Out-File $ReportPath -Append
"=== Bluetooth Radio State ===" | Out-File $ReportPath -Append
Get-NetAdapter -ErrorAction SilentlyContinue |
Where-Object { $_.InterfaceDescription -match 'Bluetooth' } |
Select-Object Name, InterfaceDescription, Status | Format-Table -AutoSize | Out-File $ReportPath -Append
# HARDENING: Uncomment the following block ONLY on endpoints that do not require Bluetooth.
# Coordinate with clinical/biomedical engineering before disabling.
#
# Stop-Service -Name bthserv -Force
# Set-Service -Name bthserv -StartupType Disabled
# Get-NetAdapter | Where-Object { $_.InterfaceDescription -match 'Bluetooth' } |
# Disable-NetAdapter -Confirm:$false
# "Bluetooth stack disabled on $(hostname) at $(Get-Date)" | Out-File $ReportPath -Append
Write-Output "Audit report written to $ReportPath. Review paired devices against authorized asset inventory."
Remediation
Immediate Actions (This Week)
- Inventory and locate every FL-100 unit. Work with clinical leadership and biomedical engineering to enumerate all Flow Neuroscience FL-100 and Halo Neuroscience FL-100 devices across your organization, including units issued to patients for home use. You cannot protect what you have not counted.
- Contact Flow Neuroscience for the patch timeline. Monitor the CISA advisory page (https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-225-01) and the vendor's CSAF feed for remediation guidance. Because this is a hard-coded credential in firmware, expect remediation to require a firmware update that re-keys the fleet — ask the vendor directly whether updated units will receive per-device credentials and how legacy units are handled.
- Issue interim patient guidance. Until patched, advise patients and clinicians to power the device off when not in an active, supervised session and to avoid using the headset in public or semi-public spaces (clinics' open waiting areas, transit, shared housing) where an attacker could sit within BLE range. This is the only control that meaningfully reduces the attack window pre-patch.
- Review companion app workflows. Ensure the FL-100 companion application and any associated mobile devices are kept updated, and restrict which staff devices can pair with clinical units.
Hardening and Monitoring (30 Days)
- Disable Bluetooth on clinical workstations that do not require it (see the audit script above). Every disabled radio is one fewer staging point an attacker can co-opt inside your walls.
- Deploy the hunting queries above against endpoints in proximity to device usage and charging areas. Alert on any BLE reconnaissance tooling — in a clinical environment,
gatttoolandbettercaphave essentially zero legitimate presence outside biomedical engineering. - Physical access controls: store and charge FL-100 units in access-controlled areas, not open nurses' stations. The vulnerability requires proximity — deny the proximity.
- Update your medical device risk register. Record CVE-2026-18164 with its patient-safety impact classification under your medical device security program (align with NIST CSF and your HIPAA security risk analysis). This CVE is a textbook entry for demonstrating due diligence on connected medical devices.
Strategic Actions
- Procurement leverage: require per-device credentialing, documented SBOMs, and coordinated vulnerability disclosure processes in all future connected medical device procurements. Hard-coded fleet-wide credentials in a Class II-equivalent stimulation device should be a disqualifying finding in 2026.
- Track CISA KEV and vendor CSAF updates. If CVE-2026-18164 is added to the Known Exploited Vulnerabilities catalog, remediation timelines become binding for federal agencies and should be treated as binding for your organization.
The bottom line: this advisory converts a home-use wellness device into a patient-safety attack surface. The proximity requirement buys you time, but only firmware re-keying closes the hole — everything else is attack-surface management until the vendor ships.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.