When the Safety Limit Was Just a Command Handler: The Pulsetto Vagus Nerve Stimulator Advisory (ICSMA-26-223-02) Through an IEC 60601-2-10 and ISO 14971 Lens

On August 11, 2026, CISA published a medical advisory about a neck-worn consumer gadget. The single vulnerability is not a memory-corruption bug or a crypto mistake. It is that the firmware quietly accepts commands nobody documented, from anyone in Bluetooth range, and one class of those commands turns off the electrical safety mechanisms. That is a sentence about architecture, not about security.

I keep a small list of advisories where the interesting part is where the safety property lives rather than how it was breached. This one goes near the top. If a stimulation output ceiling can be lifted by a message, the ceiling was never a limit. It was a policy, enforced by the same software that talks to the network.

1. The public record

CISA advisory ICSMA-26-223-02, Pulsetto Vagus Nerve Stimulator, published August 11, 2026, in the Healthcare and Public Health sector. Vendor: Pulsetto, headquartered in Lithuania. Affected product: the Pulsetto Vagus Nerve Stimulator, all versions. (CISA ICSMA-26-223-02)

The single CVE reads as follows:

CVE-2026-18844 — "The firmware of the Pulsetto Vagus Nerve Stimulator accepts several undisclosed commands over its Bluetooth Low Energy (BLE) interface. These commands are sent without authentication or encryption, and are never issued by the companion mobile application, yet are fully processed by the device when it is powered on."

CWE-912, Hidden Functionality. CVSS v4.0 base 7.2 High — AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N. CVSS v3.1 base 8.1 High. Reserved August 4, published August 11, assigned by the ICS-CERT CNA. Reported by A.C. Buglione. (CVE-2026-18844)

Read the vector string as an engineer, not a scorer. AV:A means adjacent network — BLE range, so the attacker is in the room, the gym, the airport lounge. PR:N/UI:N means no credentials and no user interaction. VC:N but VI:H/VA:H means nothing is read; integrity and availability of the device are fully compromised. That is a precise description of a control channel with no gate on it.

CISA's impact statement is the line that matters: successful exploitation "could allow an attacker to use hidden commands to disable electrical safety mechanisms or modify other stimulation output settings."

And the mitigation section is where this stops being an ordinary advisory. Per CISA, Pulsetto has not responded to CISA's attempts to coordinate, and users are directed to contact the vendor themselves at their published support address. There is no firmware fix referenced, no version boundary, no CVSS-reduction workaround. The recommendation set collapses to generic defensive measures.

For contrast, the sibling advisory published the same day — ICSMA-26-223-01, covering the Mira Hormone Monitor, where an unauthenticated BLE write of 0x01 reboots the device into bootloader mode — has an actual remedy: update the companion app to iOS v3.5.18 / Android v4.5.18, which pushes firmware v01.07.01.53. Same disclosure day, same class of BLE trust failure, two very different postmarket organisations behind them. (CISA ICSMA-26-223-01)

The thing this device does to a person

Vagus nerve stimulation is not a haptic buzz. The vagus is the principal parasympathetic outflow to the heart, and transcutaneous cervical stimulation is deliberately targeting it. There is already a serious-injury report on the public record.

FDA MAUDE report MW5178610 (MDR key 23497093), event date October 12, 2025, received by FDA November 7, 2025, filed against product code IPF — "Stimulator, Muscle, Powered." A 72-year-old male lay user reported palpitations immediately after a session, exercise intolerance the same day, and an urgent-care diagnosis of frequent ventricular arrhythmias. A three-day monitor showed 7.4% of beats ventricular. Clinical codes on the report: Arrhythmia, Fatigue, Palpitations, Unspecified Heart Problem. Event type: Serious Injury. Outcome attributed: Disability. The reporter states the device was not available for evaluation. (FDA MAUDE MW5178610)

That report describes the device operating as designed. CVE-2026-18844 describes a path to operating it well outside design. Those two facts belong in the same risk file, and I would be surprised if they are.

2. The standards lens

Three distinct gaps, in the order a reviewer would find them.

2.1 IEC 60601-2-10 — the output ceiling is a basic safety property, not a feature flag

IEC 60601-2-10 is the particular standard for the basic safety and essential performance of nerve and muscle stimulators. It exists precisely because the therapeutic mechanism is the hazard. It bounds output current on a 500 Ω resistive load, bounds maximum pulse energy to 300 mJ, bounds peak output voltage to 500 V, and requires the applied parts to be Type BF or Type CF. It also invokes the general standard's escalation for equipment capable of delivering output in excess of 10 mA or 10 V — above that threshold, you are no longer allowed to treat the output as ordinary. (IEC 60601-2-10:2012 + A1; Applus+ Keystone summary)

The word that does the work in IEC 60601-1 is single fault condition. A limit that satisfies 60601-1 has to hold when one thing has gone wrong. A limit enforced by a firmware state variable that a BLE writer can change does not hold under single fault — the "single fault" is one packet, and the packet does not even have to be malicious to be catastrophic. It just has to be one of the undocumented commands, sent by a fuzzer, a curious researcher, or an app from a different product that happens to reuse a GATT characteristic UUID.

This is the finding, stated in standards language: the output-limiting risk control is allocated to a software element that is directly reachable from an untrusted external interface, with no independent enforcement below it. In a hardware-limited design, the ceiling lives in the compliance current source, the transformer turns ratio, a series resistance, or a comparator that gates the H-bridge drive — components that no message can reprogram. In this design, the ceiling apparently lives in the same firmware layer that parses BLE writes.

2.2 ISO 14971 — risk control at the wrong tier of the hierarchy

ISO 14971 gives a strict priority order for risk control options: inherently safe design first, protective measures second, information for safety last. Nothing in the standard forbids implementing an output limit in software. What the standard demands is that the effectiveness of the chosen control be verified, and that you evaluate whether the control introduces new hazards or new hazardous situations.

A remotely writable output ceiling is a new hazardous situation created by the risk control itself. That is exactly the analysis ISO 14971 Clause 7.4 asks you to perform and record. Its absence is not a security oversight; it is an incomplete risk management file.

There is a second 14971 gap. The MAUDE report shows a cardiac adverse event from nominal use — vagal stimulation modulating cardiac rhythm is a foreseeable sequence of events, not an exotic one. If nominal-output cardiac effects were assessed as acceptable on the basis of the output being bounded, then the bound was load-bearing for the entire acceptability argument, and CVE-2026-18844 removes it.

2.3 The regulatory frame — the wellness carve-out was never available here

Pulsetto is marketed as a consumer wellness product. FDA's General Wellness: Policy for Low Risk Devices — reissued January 6, 2026, superseding the September 27, 2019 version — draws the line at product risk, not marketing claims. A product does not qualify for the low-risk general wellness policy if it presents risks to safety from, among other things, electrical stimulation; FDA's own worked example in that guidance is a neurostimulation product with a memory-improvement claim, excluded specifically because of the electrical risk. (FDA General Wellness guidance; Troutman Pepper Locke summary of the 2026 update)

And there is a third rail. Under section 524B of the FD&C Act, a "cyber device" — software-containing, internet-connectable, with characteristics vulnerable to cybersecurity threats — must arrive at premarket review with a postmarket vulnerability monitoring plan, secure development processes, a patch and update commitment, and an SBOM. (FDA Cybersecurity in Medical Devices guidance)

Note what the CISA advisory tells us: no coordinated response, no patch commitment, no version boundary. Those are precisely the 524B deliverables. A device that never went through a premarket submission never had to produce them — which is the actual structural finding here. The cybersecurity obligations attach to the regulatory pathway, and the product took a pathway that has none.

For a manufacturer building the same architecture properly, IEC 81001-5-1 supplies the secure development lifecycle — threat modelling of every external interface, and a defect-management process that would have caught undocumented command handlers before release rather than after a researcher enumerated them.

3. A worked snippet

3.1 The risk row that should already exist

An ISO 14971 row for the hazardous situation this CVE creates. Severity and probability scales are illustrative five-point; substitute your own.

| ID | Hazard | Foreseeable sequence of events | Hazardous situation | Harm | S | P1 | P2 | Risk (pre) | Risk control | Risk (post) | |---|---|---|---|---|---|---|---|---|---|---| | RM-014 | Excessive electrical energy delivered to cervical tissue | Attacker in BLE range issues undocumented command; firmware clears output-limit state; user starts a normal session | Stimulation output exceeds validated therapeutic envelope over the vagus nerve | Cardiac arrhythmia, syncope, burn at electrode site | 5 (Critical) | 3 | 4 | Unacceptable | Hardware-enforced compliance-current clamp independent of firmware state | 5 / 1 / 2 → Acceptable | | RM-015 | Loss of stimulation control authority | Undocumented command alters pulse width, frequency or duty cycle outside labelled range | Device delivers a waveform never characterised in verification | Unpredictable autonomic response | 4 | 3 | 4 | Unacceptable | Authenticated, allow-listed command set; parameter range check in an independent monitor | 4 / 1 / 2 → Acceptable | | RM-016 | Risk control defeated by external interface (new hazard introduced by RC) | Output ceiling implemented in the same firmware layer that services BLE writes | Single message defeats the primary protective measure | Same as RM-014 | 5 | 4 | 4 | Unacceptable | Re-allocate ceiling to hardware; firmware may only request values within the clamp | 5 / 1 / 1 → Acceptable |

RM-016 is the row that most files are missing. It is not a hazard of the device function. It is a hazard of the architecture chosen to control the device function, and ISO 14971 Clause 7.4 explicitly asks for it.

3.2 Fault tree — the top event has one gate too few

TOP: Stimulation output exceeds validated envelope during a session
                          │
                        [OR]
        ┌─────────────────┼───────────────────────┐
        │                 │                       │
  E1: Firmware       E2: Undocumented        E3: Hardware
  parameter          BLE command             drive-stage
  corruption         clears limit            fault
  (random)           (CVE-2026-18844)        (random)
        │                 │                       │
      [AND]             [AND]                   [AND]
        │                 │                       │
  ┌─────┴─────┐     ┌─────┴─────┐           ┌─────┴─────┐
  │           │     │           │           │           │
 SW fault  NO INDEP  Attacker  NO INDEP     HW fault  NO INDEP
 occurs    CLAMP     in range  CLAMP        occurs    CLAMP
                     + no auth

Every branch terminates in the same basic event: NO INDEPENDENT CLAMP. When one basic event appears under every AND gate in the tree, it is not a contributor — it is a common-cause element, and the tree is telling you that the architecture has exactly one line of defence. Adding a hardware clamp does not remove E2; it removes E2's path to the top event, and E1's, and E3's, simultaneously. That is the highest-leverage single change available, and it costs a current-sense resistor and a comparator.

Note also what the tree makes obvious about the attacker: the attacker is optional. E1 and E3 reach the same top event with nobody in the room. This is why I dislike filing this purely as a security issue — a random firmware fault and a hostile BLE write are the same event as far as the patient is concerned.

3.3 Threat row, in the shape a 81001-5-1 threat model would use

| Threat ID | Interface | STRIDE | Description | Existing control | Result | |---|---|---|---|---|---| | T-BLE-03 | BLE GATT write characteristic | Tampering | Undocumented opcode alters output-limit state | None — no pairing requirement, no authentication, no encryption on the command path | Exploitable, CVSS v4.0 7.2 | | T-BLE-04 | BLE GATT write characteristic | Elevation of Privilege | Command set exposed to any central is a superset of the set the companion app uses | None — no interface segregation between production and engineering command spaces | Exploitable | | T-BLE-05 | BLE GATT write characteristic | Denial of Service | Malformed or repeated commands render device unusable | None | VA:H in the published vector |

T-BLE-04 is the one I would flag in review. The advisory says these commands "are never issued by the companion mobile application." That is the signature of an engineering or manufacturing command space that was never gated out of production firmware. It is one of the oldest findings in embedded medical, and it is the reason IEC 81001-5-1 asks for an inventory of every external interface and every command it accepts — not every command the vendor's own app happens to send.

4. Derived requirements (excerpt)

Traceable, testable, and written the way they would appear in a requirements database.

VNS-SR-001 (Inherent safety by design — hardware output clamp). The stimulation output stage shall include a hardware current-limiting element, independent of all firmware-writable state, that constrains delivered r.m.s. output current, peak voltage and per-pulse energy to within the limits of IEC 60601-2-10 measured across a 500 Ω resistive load. The clamp shall remain effective with the application processor held in reset. Verification: bench test with firmware forced to command maximum output, and with MCU held in reset; measure output on a 500 Ω load. Acceptance: peak output voltage at or below 500 V and per-pulse energy at or below 300 mJ under all three conditions.

VNS-SR-002 (Command-space closure). The production firmware shall accept only the command opcodes enumerated in the released interface control document. All other opcodes shall be rejected without state change and logged. Engineering, manufacturing and diagnostic command spaces shall be absent from production images, not merely undocumented. Verification: exhaustive opcode sweep of the writable GATT characteristic across the full opcode space, plus static analysis of the dispatch table against the ICD. Acceptance: zero opcodes outside the ICD produce any observable state change.

VNS-SR-003 (Authenticated control channel). Any BLE write that modifies stimulation parameters or safety-relevant state shall require an authenticated, encrypted session bound to a user-initiated pairing event. Unauthenticated writes shall be rejected. Verification: penetration test from an unpaired central; verify rejection of every parameter-modifying write. Acceptance: no unauthenticated write alters output parameters or limit state.

VNS-SR-004 (Independent parameter monitor and safe state). An output monitor independent of the control path shall measure delivered current and pulse width each stimulation cycle and shall command the safe state — output disabled, user alerted — within 50 ms of detecting a parameter outside the labelled range. Verification: fault injection at the control path forcing out-of-range parameters; measure detection-to-disable latency on an instrumented unit. Acceptance: safe state entered within 50 ms on 100 of 100 injected faults.

VNS-SR-005 (Cardiac contraindication interlock and postmarket surveillance). The device labelling and first-use flow shall present the cardiac contraindication as an acknowledged gate rather than passive text, and the manufacturer shall maintain a postmarket vulnerability monitoring and adverse-event correlation process consistent with FD&C Act section 524B(b), including a published coordinated vulnerability disclosure contact with a defined response interval. Verification: review of the postmarket procedure and CVD policy; audit of response times against the last four reported findings. Acceptance: documented acknowledgement of every reported vulnerability within 5 business days.

5. What the headline really tells us

The headline says a wellness gadget has a Bluetooth bug. The engineering record says something narrower and more useful: a device that delivers electrical energy across the carotid sheath implemented its output ceiling in the same software layer that services untrusted radio traffic, and shipped an undocumented command set that can move it.

Every element of the fix already exists in standards that predate the product by decades. IEC 60601-2-10 tells you what the limits are. IEC 60601-1 tells you they must survive a single fault. ISO 14971 Clause 7.4 tells you to check whether your risk control created a new hazardous situation. IEC 81001-5-1 tells you to enumerate every interface and every command it accepts. Section 524B tells you what a postmarket vulnerability process looks like. None of it is exotic and none of it is expensive at design time.

What is missing is not knowledge and not technology. It is the artifact — a risk management file with an RM-016 row in it, and an architecture where the answer to "what stops the current going higher?" is a component rather than a variable. A limit you can write to is not a limit. It is a suggestion with a default value.

The MAUDE report was filed in November 2025. The CVE was published in August 2026. Nobody had to connect them, because no single file exists in which both belong. That is the real gap, and it is the one that no patch closes.

Sources

— Jherrod Thomas, The Lion of Functional Safety™