Medtronic CareLink CVE-2025-12997

Exploitation requires an authenticated CareLink Network account (PR:L) plus prior possession of a target's 'specific device and user information' to construct the direct object reference - this prerequisite is the primary limiter and drives the high attack complexity (AC:H), making mass or opportunistic exploitation impractical. No user interaction is needed (UI:N) and the endpoint is network-reachable (AV:N), but access is confined to reading sensitive user information (C:L; no integrity or availability impact). The affected product is the Medtronic CareLink Network as it existed before December 4, 2025; because it is a vendor-hosted service, the remediation is applied centrally rather than requiring a client-side configuration change.

This is a genuinely low-priority issue despite being remotely reachable. The CVSS 3.1 base score is 3.1 (LOW) with vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N: network vector, but high attack complexity and low-privilege authentication are both required, and impact is limited to a partial confidentiality breach (C:L) with no integrity or availability effect. All exploitation signals reinforce low real-world risk: EPSS is only 0.04% (10th percentile), there is no CISA KEV listing, and no public exploit code was identified. The high AC reflects the description's requirement that the attacker already possess 'specific device and user information' to enumerate/manipulate the object reference, which meaningfully limits opportunistic mass exploitation. This is a classic IDOR (CWE-639) that leaks sensitive user information rather than granting control - a targeted privacy/data-exposure concern in a healthcare context, not a widespread emergency. No signals conflict: low CVSS, low EPSS, no KEV, and no POC all agree. The one caveat is the sensitivity of the data (patient/medical-device information under a healthcare provider), which raises regulatory and privacy stakes even though the technical severity is low.

An authenticated CareLink Network user who already knows another patient's specific device and user identifiers crafts web requests to an API endpoint, substituting those identifiers to retrieve sensitive user information belonging to another account. No public proof-of-concept exists, and the required prior knowledge of valid device/user details plus authentication keeps this a targeted rather than opportunistic attack.