EOL Software in a Public Environment: How a Postponed Migration Ended in a Compromised Server
Why We Are Sharing This Case
Most incidents in IT infrastructure don't happen suddenly. They build up quietly — with every postponed decision, every skipped upgrade, every "we'll do it next quarter".
The case below traces exactly that kind of build-up: from our first review several years ago to the call saying the server had stopped. We tell it anonymously, because the lessons apply to any organisation that currently relies on unsupported software.
How It Started
A few years ago, an employee of a mid-sized company reached out to us — a mutual acquaintance had given him our contacts. At first glance the request was clear:
- upgrade a very outdated Zimbra installation;
- fix a problem with outgoing mail delivery;
- diagnose and optimise the file server.
The arrangement was our standard one: first a preliminary review and analysis of the environment, and only then a conversation about scope, timelines and budget. We don't quote for something we haven't seen yet.
What We Found
The review revealed an environment in which every single component carried its own risk:
- "The server" was a desktop machine in the office, with no UPS, on a standard business internet service — no guaranteed SLA, with a static public address.
- The public IP address was listed on several RBL (Realtime Blackhole List) lists. And not only that address — the provider's entire subnet range was affected.
- The operating system was a badly outdated Linux distribution, long out of support (EOL).
- The RAID1 array was running in degraded mode — one of the disks had failed at some point over the years.
- There was no regular backup.
- The Zimbra server was a very old version, also EOL.
- The file server turned out to be just a SAMBA service installed on the same machine.
In other words: a single physical machine with no backup power, one working disk and no backup was serving both the email and the files of the entire organisation — and it was directly exposed to the internet.
What We Recommended
The conversation after the analysis was direct: this was an unacceptably high risk for the organisation. We made three recommendations:
- Server: an immediate backup to external media and restoration of the RAID array.
- Mail server: migration to external hosting, or better still — to Microsoft 365 Exchange Online.
- File server: removal from direct exposure and placement behind a firewall.
What the Client Accepted
- Backup + RAID restoration — Accepted
- Mail migration to 365 or external hosting — Declined (Bulgarian shared hosting was ruled out for security reasons, and 365 seemed too expensive)
- File server behind a firewall — Accepted
Two of the three recommendations were accepted. The one that was declined was precisely the one that addressed the root of the problem.
The Compromise
The RBL problem was serious. On a non-guaranteed service, the provider's network contains compromised machines that generate spam, and the reputation of the entire range suffers — no matter how well-behaved a particular sender is.
With no budget for a permanent solution, we reached a workable compromise: we moved the Zimbra server to VPS hosting with a clean IP address. This solved the problem of sending mail and of it being accepted by recipients.
That left the Zimbra upgrade the client had asked for at the very beginning. The problem was that the latest available free version was also out of support — meaning that even the "newest" option available to them was software that no longer receives security fixes. We explained the risk and all the considerations. The permanent-solution options were rejected once again.
We migrated to the latest possible version, took the file server out of direct exposure and stated explicitly that we could not take responsibility for an unsupported system. Its administration remained with the client.
The Call
Everything worked — until the day we got a call saying the server had stopped, asking whether we could help.
A few weeks earlier I had come across a publication about a serious Zimbra exploit. I had other commitments at the time and didn't pay it much attention — the server wasn't under our support. In hindsight, that was the first link in the chain.
The Diagnosis
At first glance everything looked fine: clean access logs, plenty of free resources. After a closer look, I noticed that Zimbra's own services were restarting in a loop.
The first step was to restart the VPS. The system came up, everything looked normal, and for a moment both we and the client breathed a sigh of relief. Twenty minutes later it stopped again.
The next step was to restore yesterday's backup. Same symptoms.
That was the moment it became clear the problem was on a completely different scale: the machine had been compromised. The attackers had used the very exploit I had read about weeks earlier — CVE-2026-73570, through the SNMP module.
This also explains why yesterday's backup didn't help: the compromise predated it.
About the Vulnerability
CVE-2026-73570 is an OS command injection in the SNMP notification handling of Zimbra Collaboration, rated CVSS 8.9. Specially crafted SMTP requests allow an unauthenticated attacker to execute operating system commands with the privileges of the zimbra user. Affected are versions before 10.1.20 that have the zimbra-snmp package installed and SNMP notifications enabled — a configuration that is active by default in the vulnerable versions.
Timeline:
- Public disclosure of the vulnerability, with a temporary mitigation — 26 June 2026
- The fix is released — ZCS 10.1.20 — 20 July 2026
- CERT Polska reports active exploitation in the wild — 17 August 2026
- CISA adds the vulnerability to the KEV catalog with a three-day deadline for federal agencies — 21 August 2026
- Shadowserver reports hundreds of compromised instances and more than 8,200 unpatched servers — 20–25 August 2026
And here is the core of this whole case: a fix existed. It was released on 20 July in version 10.1.20. But the client's installation was EOL — no such version exists for it, and none ever will. That is what "unsupported software" means in practice: not just older, but cut off from the mechanism by which the world protects itself.
The Recovery
This is where a detail decided years earlier paid off — a sensible backup policy with a longer retention period. There were older copies, and among them I found an uncompromised backup.
After researching how to secure the machine, I restored the system from the clean backup, removed the vulnerable module and disabled additional non-critical features related to it.
The most unpleasant part remained, though: between the clean backup and the present day there was a gap of two weeks of correspondence.
The solution was to bring up the compromised server in a controlled, isolated environment, work out how to extract exactly those messages and export them. We then applied them to the users' mailboxes. The correspondence was recovered.
Several days passed between the first call and the final resolution, with a few hours of focused work each day. Throughout that time the organisation was working with unreliable email.
What Was Exposed
The damage ran along two lines at the same time.
The first was visible: the email service went down and the organisation was left without its main communication channel — with clients, with suppliers, and internally.
The second was quieter and more serious. The vulnerability grants command execution with the privileges of the zimbra user — the same user that has access to the mailboxes. For the entire period between the compromise and its discovery, the attacker had that access.
There are no indications of data exfiltration. But in an incident of this kind, the absence of indications is not proof of the absence of access. That is why the right approach is "assume compromise": review for traces and created files, change passwords, and make a sober assessment of what was accessible during that period. That no data leak or extortion followed is a good outcome — not a credit to the configuration.
What Remains
The client is happy with the result. But let's be honest about what actually happened: once again, we applied a patch and postponed the inevitable.
The difference is that this time, migrating to 365 is being seriously discussed. A reliable and secure email service is not a luxury — it is core infrastructure for any business.
Key Takeaways
1. EOL doesn't mean "older". It means "cut off from the protection mechanism".
For supported versions, the fix came out in less than a month. For an EOL version, there simply isn't one. Every published vulnerability becomes a permanently open door — and a documented one, with a publicly available description of how to exploit it.
2. The window between disclosure and mass attack is measured in weeks, not quarters.
About seven weeks passed from public disclosure to confirmed exploitation in the wild, and compromised servers numbered in the hundreds within days. Automated scanning is continuous and doesn't discriminate by company size.
3. A backup without retention is half a backup.
Yesterday's backup was useless because it already contained a compromised system. The rescue came from the older copies. If you only keep the last few days, in a slowly developing incident you will be backing up the problem, not the solution.
4. Disable functionality you don't use.
The vulnerable module wasn't needed for the organisation's work. Every active service is part of the attack surface — whether anyone uses it or not.
5. Postponing isn't saving — it's deferring a cost with interest.
The bill for this incident: several calendar days, a few hours of specialised work each day, diagnosis of a compromised system, restoration from backup, hardening, bringing up a second machine in an isolated environment and manually extracting two weeks of correspondence. Plus the days the business ran on unreliable email. Compare that with the annual price of a subscription — the maths takes a minute.
6. A breach of the mail server is a breach of all correspondence.
The service going down is an inconvenience that is seen immediately and gets fixed. Access to the content is damage that may never surface — or may surface months later, as a convincing fraud attempt built on real data from internal correspondence.
7. The limits of responsibility must be stated in advance.
When a client declines a recommendation, the conversation doesn't end — it gets documented. That doesn't stop you from picking up the phone when you're needed.
If This Sounds Familiar
If you rely on a system and aren't sure whether it still receives security updates, start with the cheapest possible step: a review of your environment. It commits you to nothing, but it removes the most expensive thing in IT — the surprise.
