A Medical Device on End-of-Life Linux: What You Do When You Cannot Patch
A large medical-equipment company came to us for a penetration test of a product running on an old Linux, and after a few hours of work I understood that there was a far more complex problem here than I had expected.
The product runs on a version of Linux that is no longer supported. End of Life. No security updates. No security patches. No vendor support. And the company cannot update the operating system wholesale, because that version was declared EOL and official support for it has stopped.
This is not a situation where you can simply upgrade a version or apply one uniform fix across the whole system. In practice we are talking about hundreds of thousands of devices installed in the field – in hospitals, in operating theatres, in critical medical environments – where you cannot simply say “upgrade your version”.
That is the situation where you know an ordinary penetration test will not be enough. (Ours is very thorough in any case, because we do not send a list of findings and forget about it – we always propose a route to a fix as well.) In this medical company’s case it was clear that there was no single magic solution, and that the problem had to be broken into parts. Because if you cannot update the version itself, perhaps you can work out what is genuinely hurting security and deal with that specifically. If in the end the problem is with particular packages or libraries carrying known vulnerabilities, perhaps we simply deal with those.
Breaking the problem into parts
So we started by understanding where the problem really exists and where it does not, and by working precisely inside the existing constraints – beyond what a standard penetration test can do.
We began with a detailed analysis of every package installed on the system: all of the packages and all of the libraries. Then we divided them into cases.
We found packages that were not in use at all, but that carried known vulnerabilities – packages expanding the product’s attack surface without giving it any functional value whatsoever. We recommended removing them completely. At that stage alone we had already reduced roughly 50% of the problem. Not because we “fixed everything”, but because the act of breaking it into parts, and understanding what is genuinely in use and what is not, made it possible to strip out components that were there only because “that is how it has always been”.
With the other 50% remaining, we went through them one by one. We checked which packages really are critical to the product, and where the problem could be solved in a targeted way. For the critical packages the product depends on, we looked for targeted updates, or alternative solutions that work without upgrading the entire Linux version.
In some cases that meant updating one specific package. In some cases it meant replacing a library with a supported alternative. And in some cases the solution was at the level of the product’s own logic.
There were cases where the solution was completely creative. Not standard. Not “by the book”. Mitigation at the level of understanding what their product actually needs and uses from the OS. We analysed their code. What we did, in effect, was hardening – and deliberately blocking vulnerabilities even without an official patch. But it worked, and the risk to the company came down significantly.
What surprised the client
What surprised the client was not only the findings, but the approach we brought with them. They expected a classic security assessment with a list of vulnerabilities. What they got was a practical work plan that takes their reality into account: an old system, a vendor who is not there, a critical product that cannot be pulled out of the field.
And this is where the difference between a technical test and real consulting comes in. You cannot always do the ideal thing. Sometimes you have to work with what there is, find the solution that works inside the constraints, and understand that security is not only scans and tools – it is also the ability to think outside the box. Especially when the client is in that much difficulty. That is our job at AppSec Labs: to help them until the problem is solved from every possible angle. That is my personal mission, too.
I first shared a version of this as a LinkedIn post on 2026-01-10. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula
