CISA has published ICS Medical Advisory ICSMA-26-223-02 covering a serious firmware weakness in the Pulsetto Vagus Nerve Stimulator, a consumer/clinical neuromodulation wearable manufactured by Lithuania-based Pulsetto and deployed worldwide — including within the Healthcare and Public Health critical infrastructure sector.
Tracked as CVE-2026-18844 (CVSS v3.1: 8.1 — High), the vulnerability is classified as Hidden Functionality: the device's firmware accepts several undisclosed commands over its Bluetooth Low Energy (BLE) interface, transmitted without authentication. Successful exploitation could allow an attacker within BLE radio range to disable electrical safety mechanisms or modify stimulation output settings on a device that delivers electrical current directly to a patient's vagus nerve.
Let that sink in from a risk perspective: this is not a data-theft bug. This is an unauthenticated wireless pathway to alter the physical electrical output of a therapeutic device worn on a person's neck. All versions of the product (vers:all/*) are affected. There is no version to which you can simply downgrade or selectively patch today — mitigation strategy matters.
Technical Analysis
Affected Product
| Attribute | Detail |
|---|---|
| Vendor | Pulsetto (Lithuania) |
| Product | Pulsetto Vagus Nerve Stimulator |
| Affected Versions | All versions (vers:all/*) |
| CVE | CVE-2026-18844 |
| CVSS v3.1 | 8.1 (High) |
| Weakness Class | Hidden Functionality (undocumented, unauthenticated commands) |
| Attack Vector | Bluetooth Low Energy (BLE) — adjacent/radio proximity |
| Advisory | CISA ICSMA-26-223-02 |
How the Vulnerability Works
The advisory is truncated at "These commands are sent without authenti[cation]," but the vulnerability class tells us what defenders need to know:
-
Undocumented command handlers in firmware. The device firmware contains BLE GATT characteristics or command opcodes that are not part of the documented, supported API used by the legitimate companion application. These are typically debug, manufacturing-test, or calibration routines that were never removed before production.
-
No authentication or authorization gating. The hidden commands do not require pairing-level authentication, application-layer tokens, or any proof that the sender is the legitimate companion app. Any BLE-capable device — a phone, a laptop with a BLE dongle, a Raspberry Pi with a $10 USB adapter — can transmit these commands to the stimulator.
-
Safety-critical impact. Among the functions reachable through these hidden commands are controls that can disable electrical safety mechanisms (current limiting, session duration caps, impedance checks) and modify stimulation output parameters. On a vagus nerve stimulator, unsafe stimulation parameters carry real physiological risk — cardiac effects, laryngeal spasm, and vagally mediated bradycardia are documented concerns in the neuromodulation literature.
Exploitation Requirements
- Proximity: The attacker must be within BLE range — typically 10–30 meters, extendable to 100+ meters with a directional antenna and high-gain BLE front end.
- No user interaction required beyond the device being powered on and advertising/connectable.
- No prior access, credentials, or pairing with the target device required.
Exploitation Status
At the time of this writing, there is no confirmed in-the-wild exploitation reported and CVE-2026-18844 has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was published through CISA's coordinated ICS medical advisory process. However, the bar to weaponization is extremely low: BLE command fuzzing and replay tooling is mature and freely available, and the attack requires nothing more exotic than commodity hardware and radio proximity. Treat this as exploitable today, not theoretical.
Defensive Context: Why This Is Hard to Detect
I want to be candid with practitioners here, because this is where most coverage of medical device advisories falls apart. There is no EDR agent on a vagus nerve stimulator. There is no Sysmon log, no Windows event, no syslog stream from the device itself. Detection for this class of threat lives in three places:
- The environment around the device — wireless/BLE monitoring infrastructure in clinical settings that can observe anomalous BLE connection behavior.
- The endpoints an attacker would stage from — laptops, phones, or single-board computers running BLE reconnaissance and exploitation tooling (gatttool, bluetoothctl, Bettercap, BtleJack, custom Python scripts using the
bleakorbluepylibraries). These ARE observable with standard telemetry. - The companion app ecosystem — paired smartphones and management workstations, which are conventional endpoints subject to conventional hunting.
The detections below target #2 and #3, plus network/OT-adjacent hunting in Sentinel. They are written to be high-signal, not high-volume. If your environment is a hospital or clinic where these devices are used or stored, these hunts are worth running even absent any indicator of compromise — this is a low-noise hunting exercise, not an always-on rule set.
Detection & Response
Sigma Rules
These rules target the endpoint behaviors most associated with BLE offensive tooling being staged or executed from managed systems. Deploy them scoped to workstations and systems in clinical environments — broad deployment on developer workstations will generate noise from legitimate IoT/embedded engineers.
---
title: BLE Offensive Tooling Execution on Managed Endpoint
id: 3b7c2f91-4d8a-4e5b-9c1d-2a6f8e0b3d51
status: experimental
description: Detects execution of common BLE reconnaissance and manipulation tooling (gatttool, hcitool, bettercap BLE modules, btlejack) that could be used to discover and interact with vulnerable BLE medical devices such as the Pulsetto Vagus Nerve Stimulator (CVE-2026-18844).
references:
- https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-223-02
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: linux
detection:
selection_tools:
Image|endswith:
- '/gatttool'
- '/btlejack'
- '/bettercap'
- '/hcitool'
selection_ble_commands:
CommandLine|contains:
- 'bettercap -eval'
- 'ble.recon'
- 'ble.enum'
- 'ble.write'
- 'gatttool -b'
- '--char-write-req'
condition: 1 of selection_*
falsepositives:
- Legitimate IoT or embedded development work
- Authorized medical device security assessments
level: high
---
title: Python BLE Library Usage for Device Interaction
id: 8f1a4c27-6e93-4b2d-8a7c-5d3e9f1b6a42
status: experimental
description: Detects Python processes invoking BLE client libraries (bleak, bluepy) or raw BLE write operations, consistent with scripts used to send unauthenticated commands to vulnerable BLE devices such as CVE-2026-18844-affected stimulators.
references:
- https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-223-02
author: Security Arsenal
date: 2026/01/15
tags:
- attack.execution
- attack.t1059.006
logsource:
category: process_creation
product: linux
detection:
selection:
CommandLine|contains:
- 'import bleak'
- 'from bleak import'
- 'import bluepy'
- 'write_characteristic'
- 'BleakClient'
- 'btmgmt'
- 'hcidump'
falsepositives:
- Legitimate BLE application development
- QA testing of companion applications
level: medium
---
title: Suspicious Bluetooth Service Manipulation on Windows
id: c4d9e183-2f57-4a8b-b6e1-9d0a3c7f5e28
status: experimental
description: Detects unusual use of Windows Bluetooth command-line utilities or PowerShell Bluetooth LE interaction, which may indicate staging of BLE attacks against nearby medical devices from a Windows endpoint in a clinical environment.
references:
- https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-223-02
author: Security Arsenal
date: 2026/01/15
tags:
- attack.discovery
- attack.t1046
logsource:
category: process_creation
product: windows
detection:
selection:
CommandLine|contains:
- 'Windows.Devices.Bluetooth'
- 'GattCharacteristic'
- 'BluetoothLEDevice'
- 'btpair'
- 'bluetoothview'
- 'WriteValueAsync'
falsepositives:
- Companion application development and testing
- IT-managed Bluetooth device provisioning
level: medium
KQL — Microsoft Sentinel / Defender Hunting
This query hunts across process telemetry for BLE offensive tooling and BLE scripting activity. Ingest Linux syslog/auditd data via the Syslog or CommonSecurityLog connectors if your clinical workstations aren't onboarded to Defender for Endpoint.
// Hunt: BLE offensive tooling and scripting activity on managed endpoints
// Context: CVE-2026-18844 (Pulsetto hidden BLE commands) — ICSMA-26-223-02
let bleIndicators = dynamic([
"gatttool", "btlejack", "bettercap", "ble.recon", "ble.enum", "ble.write",
"--char-write-req", "hcitool lescan", "hcidump", "btmgmt",
"BleakClient", "write_characteristic", "import bleak", "import bluepy",
"Windows.Devices.Bluetooth", "GattCharacteristic", "BluetoothLEDevice"
]);
union isfuzzy=true
(DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where ProcessCommandLine has_any (bleIndicators)
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, ReportId
| extend Source = "DefenderProcess"),
(Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any (bleIndicators)
| project TimeGenerated, Computer, HostName, ProcessName, SyslogMessage
| extend Source = "Syslog")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Count = count()
by DeviceName, Computer, AccountName, FileName, ProcessName, ProcessCommandLine, Source
| order by LastSeen desc
For environments with wireless intrusion detection feeding into Sentinel (via CEF), also hunt for anomalous BLE connection density around clinical areas:
// Hunt: Anomalous BLE device interaction alerts from WIDS/wireless sensors (CEF ingestion)
// Tune DeviceVendor and DeviceProduct to your actual WIDS platform
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceEventClassID has_any ("bluetooth", "ble", "rogue-device")
or Message has_any ("BLE", "Bluetooth Low Energy")
| where Message has_any ("unpaired", "unauthorized", "unknown", "rogue")
| project TimeGenerated, SourceIP, DeviceName = DeviceProduct, Message, SourceHostName
| summarize EventCount = count(), DistinctSources = dcount(SourceIP)
by SourceHostName, bin(TimeGenerated, 1h)
| where EventCount > 10
| order by EventCount desc
Velociraptor VQL
Use this artifact to sweep clinical workstations and IT-managed laptops for evidence of BLE tooling installation or recent execution — useful for scoping after a physical security incident near a treatment area:
-- Hunt: BLE offensive tooling artifacts on endpoints
-- Context: CVE-2026-18844 — Pulsetto Vagus Nerve Stimulator hidden BLE commands
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(gatttool|btlejack|bettercap|ble\\.(recon|enum|write)|BleakClient|bluepy|hcitool|btmgmt)'
OR Exe =~ '(?i)(gatttool|btlejack|bettercap|bluetoothview)'
-- Hunt: Installed BLE exploitation tooling via filesystem glob (Linux hosts)
SELECT FullPath, Size, Mtime
FROM glob(globs=[
'/usr/bin/gatttool',
'/usr/local/bin/btlejack*',
'/usr/bin/bettercap',
'/usr/local/bin/bettercap',
'/opt/**/bleak*',
'/home/*/.local/lib/python*/site-packages/bleak*',
'/home/*/.local/lib/python*/site-packages/bluepy*'
])
ORDER BY Mtime DESC
Remediation / Hardening Script
Because the vulnerable component is device firmware (all versions affected, no patched firmware confirmed at time of writing), the immediate remediation is compensating control enforcement: inventory the devices, restrict their operational context, and harden the endpoints that interact with BLE in clinical spaces. This Bash script audits Linux clinical workstations for BLE attack tooling and verifies Bluetooth service exposure; a PowerShell variant inventories Windows Bluetooth pairing state.
#!/bin/bash
# CVE-2026-18844 compensating-control audit — Linux clinical workstations
# Checks for BLE offensive tooling and unnecessary Bluetooth service exposure.
# Run with sudo. Review output before making changes.
echo "=== [1] BLE offensive tooling presence check ==="
for tool in gatttool btlejack bettercap hcitool btmgmt; do
if command -v "$tool" &>/dev/null; then
echo "[FINDING] $tool installed at: $(command -v $tool)"
fi
done
echo "=== [2] Python BLE library check ==="
for py in python3 python; do
command -v "$py" &>/dev/null || continue
"$py" -c "import bleak; print('[FINDING] bleak installed:', bleak.__file__)" 2>/dev/null
"$py" -c "import bluepy; print('[FINDING] bluepy installed:', bluepy.__file__)" 2>/dev/null
done
echo "=== [3] Bluetooth service state ==="
systemctl is-active bluetooth 2>/dev/null | while read -r state; do
echo "bluetooth service: $state"
done
hciconfig 2>/dev/null | grep -E "UP RUNNING|PSCAN|ISCAN" && \
echo "[FINDING] Bluetooth adapter up/discoverable — disable if not clinically required"
echo "=== [4] Optional: hard-disable Bluetooth on systems with no clinical BLE need ==="
echo "To disable: systemctl stop bluetooth && systemctl disable bluetooth && rfkill block bluetooth"
echo "=== Audit complete. Escalate any [FINDING] entries to the IR team. ==="
# CVE-2026-18844 compensating-control audit — Windows clinical endpoints
# Run as Administrator. Inventories paired BLE devices and Bluetooth radio state.
Write-Host "=== [1] Paired Bluetooth devices inventory ===" -ForegroundColor Cyan
Get-PnpDevice -Class Bluetooth -ErrorAction SilentlyContinue |
Where-Object { $_.FriendlyName -match 'Pulsetto|Vagus|Stim' -or $_.Status -eq 'OK' } |
Select-Object FriendlyName, InstanceId, Status |
Format-Table -AutoSize
Write-Host "=== [2] Pulsetto-specific device check (flag for clinical engineering) ===" -ForegroundColor Cyan
$matches = Get-PnpDevice -ErrorAction SilentlyContinue |
Where-Object { $_.FriendlyName -match '(?i)pulsetto' }
if ($matches) {
Write-Host "[FINDING] Pulsetto device associated with this endpoint:" -ForegroundColor Yellow
$matches | Select-Object FriendlyName, InstanceId | Format-List
} else {
Write-Host "No Pulsetto devices detected on this endpoint."
}
Write-Host "=== [3] Bluetooth radio state ===" -ForegroundColor Cyan
Get-NetAdapter -ErrorAction SilentlyContinue |
Where-Object { $_.InterfaceDescription -match 'Bluetooth' } |
Select-Object Name, Status, InterfaceDescription |
Format-Table -AutoSize
Write-Host "=== Audit complete. Report Pulsetto findings to clinical engineering and security. ===" -ForegroundColor Cyan
Remediation
There is no patched firmware version confirmed as of this advisory. All versions are affected, so version-based remediation is not currently available. Defenders should execute the following in priority order:
-
Immediate risk reduction — power and proximity control. The attack surface only exists when the device is powered on and its BLE radio is active. Instruct patients and clinical staff to keep the device powered off when not in active therapeutic use, and to avoid operating it in crowded public spaces where an attacker could sit within BLE range undetected. This single behavioral control eliminates the majority of practical exposure.
-
Inventory and scope. Identify every Pulsetto device in your environment — prescribed devices, clinic stock, demonstration units. Because these are frequently patient-owned consumer devices used adjacent to clinical care, work with clinical engineering and patient-facing staff to build the inventory. You cannot protect what you have not counted.
-
Enforce the CISA-recommended defensive measures from ICSMA-26-223-02, which for this class of advisory include: minimizing exposure of control system and medical devices, locating them behind firewalls and isolating them from business networks, and using secure remote access methods (VPNs kept current) where remote connectivity is required.
-
Monitor the vendor and CISA for firmware updates. Track the official advisory page (https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-223-02) and Pulsetto's security communications. When a firmware revision addressing CVE-2026-18844 is released, establish a recall/update process through the companion app update channel and verify application on every inventoried unit. Do not assume patients will self-update.
-
Restrict BLE on adjacent managed endpoints. Clinical workstations and staff phones that do not require Bluetooth should have it disabled via policy (see the scripts above). This shrinks the pool of systems from which an attacker — or a compromised internal host — could reach the device.
-
Physical security integration. Alert physical security and clinical staff in treatment areas to report individuals loitering with laptops or unusual electronic equipment near neuromodulation therapy spaces. BLE attacks are short-range; the human element is observable.
-
Patient safety escalation path. Ensure clinical staff know the escalation route if a patient reports unexpected stimulation behavior (changes in intensity, sessions that don't terminate, device behavior inconsistent with app settings). Treat such reports as potential security incidents, not just device malfunctions, and preserve the device for forensic review rather than resetting it.
-
Report observations. If you observe suspicious activity consistent with exploitation, report it to CISA (central@cisa.gov or via the CISA incident reporting portal) — coordinated reporting directly informs whether this CVE escalates to KEV status and drives vendor remediation timelines.
Bottom Line
CVE-2026-18844 is a reminder that the medical device threat model is not confined to hospital networks. A wearable therapeutic device with unauthenticated, undocumented firmware commands that can disable electrical safety controls is a patient-safety issue delivered through a cybersecurity weakness. With no patch available, defense is behavioral, environmental, and procedural: power management, proximity control, endpoint hardening, and a standing hunt for the tooling an attacker would need. Do those four things well, and this 8.1 CVSS vulnerability becomes a very difficult attack to execute in your environment.
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.