Hundreds of Microsoft Exchange servers in Australia and New Zealand were still exposed to a known security flaw weeks after a fix became available.
The obvious response is to update them. Fair enough.
What interests me is the conversation that might have to happen before somebody can do that. Who looks after the server? What else uses it? Does anyone know whether the last backup can actually be restored? And is this the machine everyone has been told to leave alone?
That last question deserves some attention.
What the Exchange Report Actually Says
iTnews reported on 8 September 2026 that Shadowserver's scanning had identified 382 vulnerable Microsoft Exchange servers in Australia and 56 in New Zealand as of 31 August. The relevant security update had been available since 11 August, roughly three weeks earlier.
Those are exposure figures from a particular date. They are not evidence that all 438 servers were compromised, nor a count of how many remain vulnerable today.
The flaw is CVE-2026-62911. Microsoft's published CVE record describes an authentication weakness involving captured authentication being replayed, allowing an authorised attacker to gain greater privileges over a network. Its severity assessment includes low privileges and user interaction as requirements. That is more specific than saying anybody on the internet can simply take over an Exchange server.
Affected releases include Exchange Server 2016 CU23, Exchange Server 2019 CU14 and CU15, and Exchange Server Subscription Edition RTM. Subscription Edition is also affected; this is not exclusively a problem with obsolete releases.
Public proof-of-concept code is available, also recorded in CISA's contribution to the CVE record. At the time of the iTnews report, Microsoft had not confirmed active exploitation in the wild. In checking sources for this article on 9 September, I found no newer confirmation of active exploitation and no entry for this CVE in CISA's published KEV data, dated 8 September. Neither observation proves that exploitation has not occurred.
There has also been a subsequent release: Microsoft lists September Exchange security updates, published on 8 September. Administrators should check the current release guidance for their installation rather than treat August's patch as the finish line.
One practical complication is already documented. Microsoft's August update guidance says Exchange 2016 and 2019 are out of ordinary support, with those updates available through its Period 2 Extended Security Updates programme. Running an old release does not establish that an organisation has enrolled in that programme.
How a Useful System Becomes Technical Debt
We cannot tell from an internet scan why an individual organisation has delayed an update. It might involve a failed installation, a maintenance window, support arrangements or something else entirely. The figures do not diagnose hundreds of IT departments.
But they do raise a useful business question. How easily can you maintain the systems you depend on?
A system usually arrives for a sensible reason. The business needs email, shared files, remote access or a connection between two applications. Someone installs it, gets it working and moves on to the next job.
Over time, other things start depending on it. A reporting tool uses an account on the server. An old application sends invoices through it. Someone adds an exception to get a supplier's software working. The documentation explains the original installation, but misses most of what happened afterwards.
Then the person who understood it leaves.
Replacing it sounds expensive. Updating it sounds risky. Nobody has a spare afternoon to investigate, and certainly nobody wants to be responsible for stopping the invoices going out.
It still works.
Those three words have probably secured more infrastructure renewals than any sales presentation.
This is technical debt in ordinary business terms: decisions and maintenance deferred earlier make today's changes harder and more expensive. The cost appears in staff time, awkward dependencies, specialist support and the growing possibility that a routine update will interrupt something important.
Old equipment can be well maintained. New equipment can be poorly understood. Age alone tells you less than whether somebody can explain how the system works, update it safely and recover it when something goes wrong.
A system that has become too frightening to update is already telling you something about its operational risk.
Email Has Rather a Lot of Responsibility
Mail infrastructure deserves particular care because of what people put through it.
A mailbox can contain invoices, supplier negotiations, confidential attachments, client conversations and password-reset messages. Calendar entries and old email threads reveal who works with whom, which payments are expected and how people normally ask for things.
Someone with access to that mailbox may also have a trusted identity from which to send messages. A fraudulent request arriving within a familiar supplier conversation has advantages over an obviously strange email from an unknown address. That is one route into business-email compromise.
So email often acts as part of the business's identity and trust system. Keeping messages flowing is only one part of looking after it.
There can be sound operational, regulatory, sovereignty or architectural reasons to run your own mail infrastructure. Self-hosting can be perfectly appropriate. It brings a continuing job: somebody needs to monitor the system, apply updates, understand its logs, test recovery and plan its eventual replacement.
Microsoft 365 changes where some of that work happens. Accounts, permissions, integrations, recovery arrangements and dependence on the provider still need attention. Moving to a cloud service does not automatically tidy up years of unclear ownership.
I have been building sovereign data infrastructure, including email servers, in both Europe and Australia. Part of that work is giving the small businesses I work with a practical way to move their business email, websites and associated services away from the big tech cloud platforms, if that is the direction they want to take. I understand the appeal of having more control over where business data lives and who looks after it. But building the servers is only the beginning. The maintenance responsibility described above comes with them, and it needs to be part of the arrangement from the start.
You Probably Have a Smaller Version Somewhere
An Australian small business does not need an Exchange server to recognise this problem.
It might be a NAS that was made accessible from outside the office so someone could collect files. An ageing VPN appliance that nobody wants to upgrade. Remote desktop access enabled for a contractor who finished years ago.
On the website side, it could be the old staging copy left online after launch, or a hosting control panel maintained by a supplier the business no longer uses. The main website gets attention while its forgotten relative keeps running the old software.
There is a similar ownership problem when a former supplier still controls the domain or DNS account. That is an access dependency rather than an unpatched server, but it can make an otherwise straightforward change surprisingly difficult.
In my article about the fake Telstra support call, I kept coming back to knowing who actually provides and manages your technology. The same information matters when the support request is legitimate. Who administers this thing, and does the business still have a way in without that person?
If the answer requires finding an old invoice and hoping someone still answers the phone, there is some work to do.
Sometimes You Can Remove the Problem
Before buying another product to protect an old service, establish whether the service still needs to exist.
Sometimes removing an obsolete service is a better security control than buying something else to protect it. You also stop spending time maintaining a function the business no longer needs.
This is part of why I favour static websites for suitable brochure sites. If publishing a few service pages does not require a live database, PHP, an exposed CMS login and dozens of plugins, there is a reasonable case for removing those components. Hosting, deployment access, DNS and forms still need care, but there is less application software permanently exposed to visitors.
The same reasoning applies beyond websites. Retire an unused portal. Consolidate duplicate services. Replace an unsupported appliance. Redesign an integration that keeps an entire old server alive.
Where something must stay, consider whether it needs to be publicly reachable and how access can be restricted. ASD's Exchange security guidance covers reducing exposure and hardening the systems that remain. Isolation needs proper design and ongoing maintenance too.
None of this means pulling a plug because a server looks old. Find its dependencies, preserve the records the business needs and arrange a controlled retirement. An undocumented shutdown can create its own expensive afternoon.
Start With the Thing Everyone Avoids
I would start with a short conversation between the business owner and whoever manages the technology.
What is reachable from the internet? When was it last reviewed? Is the software still supported, and who is responsible for updating it? Ask for answers specific enough that another person could pick up the work.
Then ask which system people are most reluctant to change, and why. A clear answer about a dependency can become a plan. A vague answer about how it has always been that way needs investigation.
For each doubtful system, establish whether it is still needed and what retiring it would involve. Check old staff and supplier access along the way. Put a name and a date against the next action, even if that action is simply to map the dependencies and test recovery before scheduling an update. This fits naturally alongside a practical small-business security review.
The Exchange exposure needs prompt attention from the people responsible for those servers. The longer-term work is making the next update less difficult: fewer unnecessary services, understood dependencies and someone clearly responsible for keeping the remaining systems maintainable.
If one machine immediately came to mind while you were reading this, start there.
Tags: security, small-business, australia, hosting