Memory-safety bugs in medtech: The defect that waits in the field

By Alexander Walter (ERNI Switzerland)

Medical devices are becoming software products. Insulin pumps talk to smartphones, infusion pumps sit on hospital networks and diagnostic instruments upload results to the cloud. Every connection is a door that has to stay secure, while regulators increasingly treat cybersecurity as a patient safety issue. This raises a question for every medtech manufacturer: how many of tomorrow’s field actions are already sitting in today’s code?

This article is the Part 1 of 3 in the series Rust in medtech: Prevention beats cure. It follows one real bug from a single commit to a patient data breach, shows how often the same class of defect appears in medical device advisories and explains why regulators are shifting the burden of proof to manufacturers. Part 2 of the series shows how Rust, a systems programming language with strong memory-safety guarantees, prevents these defects at the source. Part 3 explains how to introduce it without putting a certified product at risk.

One missing check, two years undetected

On New Year’s Eve 2011, a developer committed a new feature to OpenSSL, the cryptographic library behind a large share of the world’s web servers and many connected devices. The code took a length value from an incoming message and copied that many bytes back to the sender. It never checked whether the requested data was really that long.

In March 2012, the code shipped with OpenSSL 1.0.1. For two years, nobody noticed. In April 2014, researchers at Google and at the security company Codenomicon found the flaw independently. It was published as CVE-2014-0160 and became known as Heartbleed. With a single crafted request, an attacker could read up to 64 KB of server memory, including private keys, passwords and session data, without leaving a trace in the logs. At the time of disclosure, around 17% of trusted HTTPS servers were believed to be vulnerable.

The consequences quickly reached healthcare. In August 2014, a large US hospital operator reported that the personal data, but not the medical records, of around 4.5 million patients had been stolen. A security firm later reported, citing a source close to the investigation, that the attackers had entered through Heartbleed. The company itself never confirmed the attack path.

This is a textbook example of one of the most common classes of serious vulnerability in C and C++ software, and it follows a pattern that every MedTech engineer will recognise. The defect is created in seconds, survives review and testing, and is only found after years in the field, when it is most expensive to fix.

Figure 1: Heartbleed in C and in safe Rust

A common cause of serious vulnerabilities

Heartbleed was a memory-safety bug: the program read memory it was never meant to access. Such bugs are widespread. In 2019, Microsoft reported that around 70% of the vulnerabilities it assigns a CVE (an ID in the public catalogue of known security flaws) each year are memory-safety issues, and the Chromium project reports a similar share for its high-severity security bugs. C and C++ leave memory management to the developer, and even excellent teams make mistakes.

Why healthcare is especially exposed

Medical devices are particularly exposed. Much of their firmware is written in C and C++. Much of it parses data from the outside world, such as Bluetooth messages, network packets or update packages. And much of it stays in the field for 10 years or more. URGENT/11 shows what this means in practice. Memory-corruption bugs in a third-party TCP/IP stack, used in a widely deployed real-time operating system, survived about 13 years of releases. In October 2019, the FDA warned that infusion pumps, anaesthesia machines and imaging systems could be affected, and several large device manufacturers confirmed affected products.

What does this look like for medical devices? ERNI analysed all 119 medical device advisories that the US agency CISA published between January 2020 and early October 2026. Memory-safety flaws appear in about one in five advisories and one in eleven vulnerabilities, rising from 4% of advisories in 2020 to a peak of 39% in 2025 (Figure 2). Two-thirds of these flaws sit in code that parses external data, mainly DICOM image files and network packets: exactly the code where Rust protects best. Flaws in shared components such as URGENT/11, which CISA publishes as general industrial advisories, are not included in these figures.

Figure 2: Memory-safety flaws in CISA medical device advisories, 2020 to 8 Oct 2026 (ERNI analysis)

Regulation is raising the bar

Regulators have taken notice:

• Swiss Information Security Act: since 1 April 2025, critical infrastructure operators, including hospitals on cantonal hospital lists, must report cyberattacks to the National Cyber Security Centre within 24 hours. The obligation also covers manufacturers of hardware or software used by critical infrastructure if their products have remote maintenance access. Since 1 October 2025, failure to report can be fined up to CHF 100,000.
• MDR and Swiss MedDO: both require manufacturers to address IT security according to the state of the art.
• IEC 81001-5-1: the security lifecycle standard for health software calls for secure coding practices and for avoiding known vulnerable constructs. A memory-safe language covers a large part of this by construction instead of by review.
• NIS2: in the EU, medical device manufacturers of medium size and above fall under the directive, with incident reporting within 24 hours (early warning) and 72 hours (notification). Swiss manufacturers are affected through their EU subsidiaries and through supply chain requirements from EU hospitals.
• FDA section 524B: premarket submissions for cyber devices need cybersecurity documentation and a software bill of materials.
• CISA and FBI: in non-binding guidance, the US agencies call developing new products for critical infrastructure in memory-unsafe languages such as C and C++ a bad practice when alternatives exist. They also asked manufacturers of existing products to publish a memory-safety roadmap by 1 January 2026.

The EU Cyber Resilience Act does not apply to devices covered by the MDR or IVDR. However, it may still apply to connected products in a MedTech portfolio that are not medical devices themselves.

None of these rules prescribes a programming language. But all of them shift the burden of proof to the manufacturer: you will increasingly be asked how you prevent vulnerabilities in the first place, alongside how fast you patch them.

What this means for manufacturers

Heartbleed was created in seconds, survived review and testing and stayed in the field for two years. Its relatives are still being written every day, in every industry that relies on C and C++, including MedTech. Reviews, static analysis and tests remain essential, but they catch mistakes after they have been written. The stronger lever is to stop this class of defect from being written in the first place.

That is where Rust comes in. In part 2 of this series, we look at how its compiler rejects most memory errors before the software ever runs, what evidence exists and where the language pays off in medical device software.

Want to know how exposed your own products are? With a memory safety roadmap, ERNI assesses your codebase and defines where Rust, hardening or other measures reduce risk most, documented so that you can share it with customers, hospitals and auditors. Speak to our medtech team.

References

Heartbleed and URGENT/11

1. The Heartbleed Bug – Codenomicon / Synopsys: affected versions, disclosure, no traces in the logs
2. Heartbleed – Wikipedia: timeline from the commit on 31 Dec 2011 to disclosure, and the ~17% estimate (Netcraft, cited by Wikipedia)
3. Heartbleed to blame for Community Health Systems breach – CSO Online, 2014: 4.5 million patients, attack path reported by TrustedSec
4. URGENT/11 – Armis: the vulnerabilities and the affected IPnet stack
5. FDA informs patients, providers and manufacturers about potential cybersecurity vulnerabilities for connected medical devices – FDA press release of 1 Oct 2019 (BioSpace copy)
6. Third-party software vulnerability could endanger medical devices – MedTech Dive, 2019: manufacturers confirming affected products

Memory safety and regulation

• The Urgent Need for Memory Safety in Software Products – CISA: Microsoft’s ~70% figure
• Memory safety – The Chromium Projects: ~70% of high-severity security bugs
• NIS2 Directive, Article 23 – reporting obligations (24 h / 72 h)
• The NIS2 Directive: implications for the healthcare sector and manufacturers of medical devices – Fieldfisher
• Reporting obligation for cyberattacks – Swiss National Cyber Security Centre (Information Security Act)
• New obligation to report cyber incidents in Switzerland – Baker McKenzie: covered entities, incl. hospitals and manufacturers with remote maintenance access
• Regulation (EU) 2017/745 on medical devices (MDR) – EUR-Lex; Swiss counterpart: Medical Devices Ordinance (MedDO), Art. 6
• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions – FDA guidance (section 524B)
• Product Security Bad Practices – CISA and FBI, Oct 2024 (non-binding guidance)
• Regulation (EU) 2024/2847 (Cyber Resilience Act) – EUR-Lex: exclusion of MDR and IVDR products
• CISA CSAF security advisories – CISA: machine-readable ICS medical advisories (ICSMA), basis of ERNI’s analysis of 119 ICSMA advisories, 2020 to 8 Oct 2026
• EN IEC 81001-5-1 guide: cybersecurity for MDR and IVDR – Thema Med, Feb 2026: the security lifecycle standard for health software