CVE-2019-6538
Executive Summary
CVE-2019-6538 is a critical vulnerability (CVSS 9.3) in the Conexus Radio Frequency Telemetry Protocol used by several Medtronic implantable cardiac devices and their associated programmers and home monitors. The protocol fails to implement authentication or authorization, allowing an attacker with short-range, adjacent access to inject, replay, modify, and/or intercept telemetry data when the affected device's radio is enabled. Because the protocol supports reading and writing memory values within implanted cardiac devices, a successful attacker can modify the device's memory, potentially disrupting device functionality. This vulnerability affects patients using the listed Medtronic CRT-D and ICD devices, as well as healthcare environments that use the associated CareLink monitors and programmers. Medtronic has released patches for a subset of affected models, delivered during regular office visits.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability lies within the Conexus Radio Frequency Telemetry Protocol, a proprietary over-the-air (OTA) communication protocol employed by the affected Medtronic devices for wireless programming, interrogation, and data retrieval. The core flaw is an improper access control condition (CWE-284): the protocol design does not incorporate authentication or authorization mechanisms at the telemetry layer. Any entity within radio range that can transmit on the appropriate frequency and encode the protocol frames can interact with the device as if they were an authorized programmer.
The attack surface is limited in range — the NVD description characterizes access as "adjacent short-range" — meaning the exploit radio must be physically proximal to the target device. However, no other precondition exists beyond the device's radio being turned on. Notably, the impacted telemetry interface provides the ability to read and write memory on the implanted cardiac device. This is significant: the protocol was designed with full read/write capability for legitimate programming operations, but the lack of access control means that the same capabilities are exposed to any adjacent radio that can speak the protocol.
There is insufficient technical detail available in the public description to enumerate specific opcodes, packet structures, or memory-mapped registers used by the Conexus protocol. The vulnerability class, however, is well understood: unauthenticated remote (short-range) memory manipulation over a wireless telemetry link. The radio systems used in these devices operate in the Medical Device Radiocommunication Service (MedRadio) band (roughly 401–406 MHz) and are also compatible with a 2.4 GHz ISM-band communication for some of the monitors and programmers, but specific band details are not explicitly provided in the NVD description.
The attack surface includes not only the implanted devices themselves but also the Medtronic MyCareLink Monitor (models 24950 and 24952), CareLink Monitor (model 2490C), and CareLink 2090 Programmer — these are the intermediary devices that healthcare professionals and patients use to interact with the implants. An attacker who compromises these intermediary devices (or who simply intercepts telemetry traffic between an implant and a legitimate monitor) can redirect, modify, or replay data. The NVD description also states that the attack is only possible in situations where the product's radio is turned on — a crucial operational prerequisite for exploitation.
Exploitation Scenarios
Step 1 — Reconnaissance/Target Identification: The attacker must physically position themselves within short-range radio distance of the target. In a clinical setting, this could mean being in proximity to a patient's home monitoring station or in a hospital room where a programmer is active. In a home environment, an attacker could position a software-defined radio (SDR) or a modified telemetry wand near the patient's residence. The attacker would also need to determine when the device's radio is active — during programmed interrogation windows, or continuously if the implant is configured for constant monitoring.
Step 2 — Triggering the Flaw: The attacker tunes their radio equipment to the MedRadio band (or alternatively the 2.4 GHz band used by some newer monitors/programmers) and begins transmitting Conexus protocol frames. Since the protocol has no authentication or authorization checks, the device will process traffic from any valid protocol speaker as if it were a legitimate Medtronic programmer. No credentials must be bypassed; no encryption or signing must be circumvented — the protocol simply has no such mechanisms.
Step 3 — Payload/Execution Method: At the vulnerability-class level, the payload is a crafted telemetry command that maps to one of the supported protocol functions: read memory, write memory, replay previous sessions, or modify in-transit data (man-in-the-middle). Because the description confirms that "read and write memory values" are possible, the attacker can craft a write command targeting arbitrary memory addresses in the device's firmware/control space. The exact memory map and command format are not disclosed in the NVD description but are knowable through protocol reverse engineering of the legitimate devices. No public PoC available; attack chain is inferred from vulnerability class.
Step 4 — Post-Exploitation Impact: The attacker can modify device memory content, which may corrupt device configuration, alter therapy parameters, or change device behavior. Depending on the memory regions touched, the attack can produce effects ranging from benign data corruption to disabling of therapeutic functions or changing pacing/sensing parameters — with potentially life-threatening consequences for the patient. Interception of telemetry data can also expose patient-specific device configuration or diagnostic data to the attacker, enabling further targeted operations. Replay attacks could cause the device to re-execute previous commands, potentially reverting to unsafe states or re-enabling prior configurations that were intentionally changed.
Impact Assessment
The CVSS score of 9.3 places this in the Critical severity band. The most severe impact of CVE-2019-6538 is to patient safety. These are implantable cardiac devices — CRT-D (cardiac resynchronization therapy defibrillators) and ICDs (implantable cardioverter-defibrillators) — whose primary function is to deliver life-sustaining therapy including shock delivery for ventricular fibrillation and pacing for bradycardia. An attacker who can modify the device memory could theoretically alter therapy thresholds, disable shock delivery, change pacing timing, or otherwise compromise device function in a way that leads to patient harm.
The affected population includes patients implanted with the listed Evera, Maximo II, Mirro, Nayamed ND, Primo, Protecta, Secura, Virtuoso, Virtuoso II, Visia AF, and Viva models, as well as the multiple CRT-D variants (Amplia, Claria, Compia, Concerto, Concerto II, Consulta, Maximo II, Viva, Brava). The blast radius extends beyond the individual patient to the healthcare enterprise: hospitals and clinics that use the CareLink 2090 Programmer for device interrogation expose their telemetry infrastructure to the same flaw. Because the protocol lacks authentication, a malicious actor could potentially replay captured telemetry sessions to spoof device data, mislead clinicians about device status, or corrupt clinic-side databases that ingest telemetry.
CISA has not listed this vulnerability in the Known Exploited Vulnerabilities (KEV) catalog, and the EPSS score (0.00895) rates the probability of exploitation as low in the near term. However, for an in-healthcare, safety-critical context, the low EPSS must be weighed against the catastrophic consequence of a successful attack — the potential for patient death. Two attack-precondition constraints limit real-world risk: the need for radio-on state and the need for physical proximity. Still, the attack surface is inherently wireless, which undermines physical security at the boundary.
Detection Guidance
Sigma Rule
title: Medtronic Conexus Telemetry Unauthorized Access Attempt
id: 9f4e13c0-6a24-4e88-9a7e-3c15e78f9d42
status: experimental
description: Detects anomalous wireless communications in the MedRadio band or anomalous Conexus protocol traffic on Medtronic programmer/monitor devices.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2019-6538
author: Valtersit Threat Intelligence
date: 2024/12/20
logsource:
product: medtronic
category: telemetry
detection:
selection_radio_state:
radio_state: enabled
event_type: unexpected_device_connect
selection_unsolicited:
event_type: connection_request
source_type: unknown
selection_programming:
programming_activity: true
authorized_session: false
condition: selection_radio_state and (selection_unsolicited or selection_programming)
level: high
falsepositives:
- Legitimate Medtronic equipment serviced by vendor during office visits
- Device setup by authorized healthcare personnel during onboarding
tags:
- attack.initial_access
- attack.t1190
- cve.2019-6538
YARA Rule
rule Medtronic_Conexus_Telemetry_Unauth
{
meta:
author = "Valtersit Threat Intelligence"
description = "Detects binaries or firmware images that implement or reference the Conexus unauthenticated telemetry protocol, indicating potential attack tooling or vulnerable firmware."
cve = "CVE-2019-6538"
date = "2024-12-20"
strings:
$prot_header = "Conexus" ascii
$proto_str1 = "Radio Frequency Telemetry" ascii
$proto_str2 = "MedRadio" ascii
$model_1 = "24950" ascii
$model_2 = "24952" ascii
$model_3 = "2490C" ascii
$model_4 = "2090" ascii
condition:
uint16(0) == 0x5A4D // MZ header
and filesize < 5MB
and ($prot_header or $proto_str1 or $proto_str2)
and (any of ($model_*))
}
Suricata IDS Rule
alert tcp any any -> any any (msg:"Potential Medtronic Conexus Telemetry Unauthorized Access, CVE-2019-6538"; flow:established; content:"Conexus"; nocase; content:"24950" or content:"24952" or content:"2490C" or content:"2090"; threshold:type both, track by_src, count 3, seconds 60; classtype:attempted-admin; reference:cve,2019-6538; sid:200903406; rev:1;)
Note: This Suricata rule targets network-level telemetry traffic that may originate from a compromised programmer or monitor. For actual radio-frequency attacks, network-based detection is ineffective — the attack occurs over an RF channel. See Mitigation & Patch Guidance for compensating controls.
Elastic Detection
sequence by host.name, process.entity_id with maxspan=5s
[process where event.type == "start" and process.name : "*sdr*" or process.name : "*rtl*" or process.name : "*gqrx*"]
[network where event.type == "connection" and destination.port == 8047 or destination.port == 3768]
This EQL rule is designed for a case where an attacker has compromised a laptop or workstation on the healthcare network and uses software-defined radio (SDR) tooling to interact with Medtronic devices. It assumes a controlled environment where SDR software is not typically installed on clinical workstations.
Splunk SPL Query
index=netflow OR index=firewall AND (dest_port=8047 OR dest_port=3768)
| stats count by src_ip, dest_ip
| where count > 10
| search "Conexus" OR "Medtronic" OR "radio telemetry"
This Splunk query searches firewall/netflow logs for unusual volumes of traffic to known Medtronic device communication ports. The actual telemetry uses RF, but network events associated with the programmer/monitor may indicate a compromised intermediary device being leveraged in the attack chain.
Wazuh OSSEC Rule
<group name="medtronic,">
<rule id="100345" level="12">
<decoded_as>json</decoded_as>
<field name="event_type">^connection_request$</field>
<description>Medtronic Conexus unauthenticated telemetry connection attempt, CVE-2019-6538</description>
<group>attack.initial_access,</group>
<mitre>
<id>T1190</id>
</mitre>
</rule>
</group>
Mitigation & Patch Guidance
Patch Confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed). Medtronic has stated that patches for a subset of affected models are available and can be installed during regular office visits. Patched models include Protecta ICD and CRT-D (all models); Amplia MRI CRT-D, Claria MRI CRT-D, Compia MRI CRT-D (U.S. only); Visia AF MRI ICD and Visia AF ICD (all models); Brava CRT-D; Evera MRI ICD and Evera ICD; Mirro MRI ICD; Primo MRI ICD; and Viva CRT-D. Patches for additional models are being developed.
Immediate Mitigations:
- Ensure the radio on implanted devices is disabled when continuous monitoring is not clinically necessary — the attack is only feasible when the radio is powered on.
- Maintain strict environmental control of all home monitors and programmers; do not leave them unattended in unsecured areas.
- Do not connect any unapproved devices to home monitors or programmers via USB or other physical interfaces — such connections could be leveraged as a gateway to the telemetry radio.
- Use programmers only in physically controlled hospital/clinic settings.
- Use home monitors only in private, physically controlled environments (home, apartment, secured residence).
- Instruct patients and caregivers to report any unusual device behavior, unexpected telemetry sessions, or unexplained programmer/monitor activity to their healthcare provider.
- For enterprises: maintain security monitoring on all networks encompassing Medtronic devices; treat all telemetry and programming sessions as sensitive data flows.
Patch/Upgrade Steps:
- Coordinate with Medtronic (or your device vendor representative) to schedule firmware patch installation during the patient's next regular office visit for the applicable models listed above.
- Verify patch installation by confirming firmware version updates through the programmer or monitor display.
- For U.S.-only patches (Amplia, Claria, Compia MRI CRT-D), confirm geographic eligibility with Medtronic directly.
Long-Term Hardening:
- Follow Medtronic's published security guidance at https://www.medtronic.com/security for future advisories and patch releases.
- Monitor Medtronic's CNA advisories for updates when additional models receive patches.
- For SOC teams: establish monitoring for any attempts to enumerate or interrogate Medtronic devices beyond clinically prescribed sessions.
- Encourage clinical environment network segmentation so programmer/monitor traffic cannot reach the broader hospital IT network in the event of a programmer compromise.
- Consider physical-layer monitoring in high-security environments — RF spectrum monitoring can detect anomalous signals in the MedRadio band.
References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2019-6538 — NIST National Vulnerability Database entry for this CVE (NVD description used for this analysis).
- Vendor Advisory: https://www.medtronic.com/security — Medtronic's published security guidance and patching status for this and related Conexus vulnerabilities.
- CISA ICS Advisory (if applicable): Search CISA ICS-CERT advisories for related Medtronic Conexus notifications — CISA has coordinated disclosure of medical device vulnerabilities. Per the data provided, this CVE is NOT listed in the CISA KEV catalog.
- MITRE ATT&CK for ICS: Refer to MITRE's ATT&CK for ICS knowledge base, specifically T0855 "Unauthorized Command Message" and T0854 "Spoof Reporting Message" — the Conexus vulnerability maps closely to these ICS techniques.
- EPSS Data Source: FIRST.org EPSS scoring API — EPSS score for CVE-2019-6538 is 0.00895 (56.2% percentile among scored CVEs).
Threat Actor Campaigns: No known active exploitation campaigns or exploit-in-the-wild evidence exist for CVE-2019-6538 as of the data provided. CISA KEV does not include this CVE. The lack of public exploitation activity should not be interpreted as an absence of risk — adjacent RF attacks on unauthenticated medical telemetry protocols are well-documented in security research, and this vulnerability class has been demonstrated at security conferences for other medical device vendors.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.