Phone system security fails in most organizations because the phone system is filed under facilities rather than under IT. The box in the closet runs a database, a web interface, and usually an integration into your directory, which makes it a server by every definition except the one on the purchase order. September 2026 made that concrete: attackers began mass-exploiting an unauthenticated flaw in Sangoma Switchvox, a widely deployed private branch exchange appliance, and roughly 4,000 of those systems were reachable from the open internet at the time. Our team has opened enough of these cabinets to know how it happens. Nobody decided to expose it; the installer needed remote phones to work, and the decision was never revisited.
Overview: What IT and Operations Leaders Should Take From This
Five points carry the weight here, and they matter most to IT managers and operations directors at organizations that inherited a phone system from a previous provider or installer.
- A PBX is a server. It runs a database and a web interface, and it patches like a server, not like a handset.
- Remote phones are the usual reason it faces the internet, and the exposure typically outlives the reason.
- An unauthenticated flaw means no password is needed, so account hygiene and multi-factor authentication do not help.
- Call detail records, voicemail, and extension directories are personal data sitting in that database.
- Nobody owning the patch cycle is the root cause, and it is an ownership problem before it is a technical one.
Why a Phone System Ends Up Facing the Public Internet
A PBX faces the internet because remote handsets, softphones, and branch offices need to register to it, and the fastest way to make that work is to open the port. This is rarely a considered architecture decision. It is a commissioning shortcut made on a deadline, usually by a vendor who left the building afterward. If you are new to how these systems are put together, our explainer on what a VoIP phone system is and how it works covers the moving parts this article assumes.
The Remote Phone Problem Everyone Solves the Same Way
Remote extensions need a path back to the PBX, and the two ways to give them one are a VPN or a public listener, with most installs choosing the listener. The VPN route is more work at setup and much less work afterward, because it removes the appliance from the public attack surface entirely. There is a legitimate counter-argument from operations: a VPN dependency means a phone that stops working when the tunnel does, and phones that fail are an immediate business problem in a way that most IT failures are not. We hear that and take it seriously. The middle path we deploy most often is a session border controller or a restricted allow list at the firewall, so remote phones keep working without publishing the administrative interface to everyone.
The Web Interface Nobody Meant to Publish
Most PBX platforms expose an administrative web interface on the same host as the call services, which means opening one usually opens both. This is the detail that turns a telephony exposure into a server compromise, because the web layer is where the database queries live. In the Switchvox case the vulnerable path was an endpoint that processes requests from supported IP phones, so it was published precisely because remote phones needed it. There is no configuration in which that endpoint is optional for remote handsets, and that is what makes exposure so common. The practical response is not to argue about whether it should be reachable, but to control who can reach it.
Ownership Is the Actual Root Cause
The phone system usually has no owner in the patch cycle, which is why a critical advisory can circulate for weeks without anyone acting on it. Servers belong to IT, laptops belong to IT, and the phone system belongs to whoever answered the phone when it was installed. In our assessments, the question of who applies PBX firmware updates produces a pause more often than an answer. A fair counter-position is that many organizations buy the phone system as a managed service and reasonably expect the provider to patch it. That expectation is often correct and is almost never written down, which is why we ask clients to confirm it in the contract rather than in the relationship.
What an Unauthenticated Flaw in Your PBX Actually Costs
An unauthenticated vulnerability means an attacker needs nothing from you, so the controls most organizations have invested in do not participate in the defense. No password is required, no user makes a mistake, and no phishing email needs to land. The Switchvox flaw carried a critical severity rating and allowed escalation from a database injection to running commands on the host, which is the full range. Our vulnerability assessment work exists to find this class of exposure before the scanning campaigns do.
The Database Behind the Dial Tone
A PBX database holds call detail records, voicemail, extension directories, and often the names and mobile numbers of every employee, which is a personal data breach waiting for a trigger. Clients are frequently surprised by this. They think of the phone system as carrying conversations rather than storing them, and the storage is exactly what a database injection reaches. Who called whom and when is sensitive in many industries, and it is discoverable in litigation. A reasonable objection is that most attackers exploiting these systems are after compute rather than records, which matches what was observed in the September campaign, where second-stage payloads looked like cryptomining. That is true of the first wave and says nothing about the second.
The Route From the Phone Closet to the Rest of the Network
A compromised PBX is a foothold inside your network perimeter with credentials to other systems, which is a worse outcome than the telephony disruption people imagine. These appliances commonly integrate with a directory service for extension mapping, with email for voicemail delivery, and sometimes with a customer platform for screen pops. Each integration is a stored credential. Our network security monitoring practice treats the phone VLAN as an internal network segment rather than as a utility, because that is what an attacker treats it as. If your telephony has moved into a collaboration platform instead, the integration points differ but the principle does not, as we cover in integrating a phone system with Microsoft Teams.
The Tail Nobody Budgets For
The cost people underestimate is not the outage, it is the weeks afterward, when you have to establish what an attacker reached from an appliance that logs very little. Most PBX platforms retain thin logs by default and ship them nowhere, so the forensic question is answered by inference rather than by evidence. That drives the response longer and makes notification decisions harder. The counter-view, that a cryptominer on a phone system is a nuisance rather than an incident, only holds if you can prove the intrusion stopped there. Without logs forwarded somewhere durable, you cannot.
Why Patching a Phone System Is Harder Than Patching a Server
Knowing the PBX needs updates and being able to apply them are different problems, and the gap between them is where most of the delay actually sits. Organizations that accept the argument in this article still take months to act, and the reasons are practical rather than political. Understanding them is what turns a policy into a schedule.
The Maintenance Window Problem
A phone system cannot be restarted during business hours in most organizations, which pushes every update into a narrow overnight slot that competes with every other change. Unlike a file server, a PBX failing is immediately visible to customers, so nobody wants to be the person who tried it on a Tuesday. The result is a queue where telephony updates lose to everything with a deadline. Our team schedules these deliberately, usually a weekend morning, and we test the failback with a handful of extensions before committing to the full fleet. A reasonable objection is that this makes patching expensive in staff time. It is cheaper than the alternative by a wide margin, and it is predictable, which makes it budgetable.
The Version You Are On May Not Be Supported
The second obstacle is that a system left alone for six years is often several major versions behind, so the critical patch is not a single step. Vendors commonly require an upgrade path through intermediate releases, and each one carries its own configuration changes. This is the point where a routine patch becomes a project, and it is the honest reason many organizations stall. There is a fair argument for replacing rather than upgrading at that stage, particularly if a cloud platform would remove the patching burden entirely. We work through that comparison with clients on cost and on risk, and either answer is defensible. What is not defensible is leaving the current system reachable from the internet while the decision is pending, which is the state we find most often.
The Exposure Review We Run on a Client’s Phone System
This is the review our team runs, and it takes under a day for most organizations:
- Find out whether the PBX administrative interface and phone registration endpoint are reachable from outside your network, tested from an external address rather than assumed from a firewall rule.
- Record the platform, the exact firmware version, and the date of the last update. If nobody can supply that date, treat the system as unpatched until proven otherwise.
- Name the owner of the patch cycle in writing. If it is your provider, confirm it in the contract, including the window in which critical advisories get applied.
- List every integration the PBX holds credentials for, and confirm each credential is scoped to the least it needs.
- Put the phone system in the same monitoring and log-forwarding path as your servers, so an incident leaves evidence somewhere other than the appliance.
- Segment the telephony VLAN from general business systems, and verify the segmentation by testing it rather than by reading the diagram.
Run this alongside your normal review cycle rather than as a one-off. The general hygiene practices for distributed workforces are covered in our guidance on keeping a VoIP phone system secure for remote and hybrid teams, and the trade-offs against older infrastructure in our comparison of VoIP and traditional phone lines.
Frequently Asked Questions
How do I tell whether our phone system is exposed?
Test from outside your network rather than checking a firewall rule, because rules drift and vendor installs sometimes add their own. Our cyber security audits include an external view of what your organization publishes, and the phone system is a frequent surprise in that report.
Does multi-factor authentication protect the PBX?
Not against an unauthenticated flaw. Multi-factor authentication protects accounts, and this class of vulnerability is triggered before any account is involved. It is still worth having on the administrative interface for every other reason.
Our provider manages the phone system, so are we covered?
Possibly, and it is worth confirming in writing. Ask specifically who applies firmware updates, within what window for a critical advisory, and how you will be told it happened. A verbal understanding is common and is not an answer.
Is a cloud phone system safer than an on-premises PBX?
It moves the patching responsibility to the provider, which removes the most common failure mode here. It does not remove the integration credentials or the call data, so the review above still applies to what connects to it.
What should we do first if we find our PBX is reachable?
Restrict who can reach it at the firewall today, then confirm the firmware version against the vendor’s current release. Our managed security services team handles both in the same visit, and the restriction is the part that cannot wait for a maintenance window.
Who Is Behind This Guidance
Our team runs external exposure reviews as a standard part of onboarding, and the phone system is one of the two or three findings that appear most often in organizations that otherwise have their security in reasonable shape. It is not a sophistication problem. It is a boundary problem: the appliance sits between the people who buy telephony and the people who patch servers, and it falls into that gap for years at a time.
Mindcore is led by Matt Rosenthal, whose focus has been on security work that closes ownership gaps rather than adding tools on top of them. That is the shape of the advice here: the fix that matters is writing down who patches the phone system, and the technical controls follow from that.
Find Out What Your Organization Publishes to the Internet
If nobody at your organization can say today whether your phone system is reachable from outside, that is the finding, and confirming it takes minutes rather than a project. The organizations caught in the September campaign were not careless; they simply had no owner for a box that had worked perfectly for six years. Six years of working is exactly what makes it invisible.
Our team will run the external view with you, tell you what your network publishes, and hand you the patch-ownership question in a form your provider can answer. Book a free strategy call and bring whoever installed your phones. You will leave knowing whether your PBX is on the public internet, which is the question this whole article exists to make you ask.
