Self-Hosted PBX Security: Patching, Exploited Vulnerabilities and Who Carries the Risk (2026)

This guide shows small businesses running their own office phone-system server how to assign patching responsibility, set deadlines for urgent fixes, check whether the software is still supported, and decide whether to keep hosting it. Unlike general VoIP security advice, it uses published vendor incidents and Australian government patching guidance to focus on ownership and version lifecycle. By the end, you should be able to name the person responsible today, state your urgent patch deadline, and identify whether self-hosting remains defensible.

A private branch exchange, or PBX, is the system that connects your extensions, phone numbers and call routes, much like a reception desk that automatically directs every call. Many businesses with a self-hosted PBX inherited it: somebody installed FreePBX (an open-source PBX platform), Asterisk (the open-source phone-system engine that FreePBX runs on) or 3CX (a software-based PBX platform popular with IT providers) years ago, it kept working, and the original administrator eventually left.

That history is normal. The security problem begins when nobody can answer, in writing, who checks for vulnerabilities and who is authorised to install an urgent update.

This article does not repeat general coverage of toll fraud, network separation or router configuration. See the Australian VoIP security basics guide for those controls.

The Security Question Is Ownership, Not the PBX Brand

Self-hosting does not merely mean that the PBX runs in your office. It means your business, or a provider contracted by your business, operates some or all of the server beneath the phone system.

The work normally spans five layers:

1. The server operating system, such as Debian or Windows.
2. The PBX application, such as Asterisk, FreePBX or 3CX.
3. Modules, desktop applications, phone firmware and integrations.
4. Internet exposure, administrative access and account controls.
5. Backups, monitoring, alert handling and recovery.

Moving a server from the communications cupboard to a cloud virtual private server, or VPS, changes its location. A VPS is a rented server in a provider's data centre, like leasing an empty office rather than employing someone to run the office. Unless the service is explicitly managed, the cloud company generally supplies infrastructure while the customer still maintains the operating system and PBX.

A current example of that split appears in the 3CX hosted-service description. It says 3CX manages its software, operating system, security patches and monitoring, but makes the system administrator responsible for configuring and maintaining backups. The useful lesson is not that one model is perfect, but that “hosted” still needs a line-by-line responsibility check.

Our view: Self-hosting is reasonable when a named employee or contracted provider owns patching, monitoring and lifecycle management in writing. If the answer is “our IT person probably handles it,” ownership has not been established.

Exploited Vulnerabilities Show Why Delay Matters

A Common Vulnerabilities and Exposures identifier, or CVE, is a public number assigned to a specific security flaw. Think of it as the recall notice number for a particular car part: it lets vendors and administrators refer to the same problem without ambiguity.

The examples below are included to show how exposure, updates and responsibility interact. They are not instructions for exploiting a system.

FreePBX and CVE-2025-57819

On 26 August 2025, the Sangoma FreePBX Security Team warned about a potential exploit affecting some systems whose administrator control panel was exposed to the public internet. Its security advisory for CVE-2025-57819 says that, starting on or before 21 August 2025, an unauthorised user began accessing FreePBX 16 and 17 systems connected directly to the internet with inadequate IP filtering, through a flaw in the commercial Endpoint module. The advisory lists all supported versions (15, 16 and 17) as affected, and the fix reached the stable update channel on 28 August 2025.

The community notice told administrators to update and to lock the management interface down to their own address. The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalogue on 29 August 2025. That catalogue, commonly shortened to KEV, lists vulnerabilities for which CISA has evidence of active exploitation.

Old flaws stay on the list too. In February 2026 CISA added two more FreePBX vulnerabilities to KEV: CVE-2019-19006, an administrator authentication bypass first published in 2019, and CVE-2025-64328, a flaw in the admin interface's filestore module that needs a valid login. A system that missed a 2019 fix was still a target six years later.

The lesson is not that every FreePBX installation is inherently unsafe. It is that an exposed administrator interface, an affected module and a delayed update can combine into a serious incident before a monthly maintenance visit arrives.

The 3CX desktop-app compromise and CVE-2023-29059

In March 2023, 3CX disclosed that specified Windows and macOS releases of its Electron desktop application were affected by a supply-chain compromise. A supply-chain compromise means trusted software reaches customers with a compromised component, much like a sealed replacement part being altered before it reaches the workshop.

The 3CX security alert identified Windows versions 18.12.407 and 18.12.416, plus macOS versions 18.11.1213, 18.12.402, 18.12.407 and 18.12.416. The NVD record for CVE-2023-29059 describes the affected application as exploited in the wild in March 2023, and 3CX's notice strongly recommended its web-based PWA app instead while a clean desktop app was prepared.

This was an endpoint application incident rather than proof that every self-hosted 3CX server was compromised. It still illustrates a wider ownership problem: a PBX administrator needs an inventory covering client applications and integrations, not only the server in the cupboard.

Asterisk advisories and release status

Asterisk publishes project security notices through its security advisories page and maintains a separate version lifecycle table. An Asterisk security notice can apply beneath a FreePBX installation even when the FreePBX web interface looks normal.

The practical response is to record both versions. “FreePBX 17” is not a complete inventory entry if nobody knows which Asterisk release and operating system it is running.

Check Whether Your Version Still Receives Security Fixes

End of life, or EOL, means the maintainer no longer supplies changes for that release. It is similar to owning equipment for which the manufacturer has stopped making safety-related replacement parts: continued operation is possible, but a newly discovered defect may remain uncorrected.

Check the running major version against the vendor's live lifecycle page, not an old installation proposal or a cached search result.

Asterisk

The Asterisk lifecycle table distinguishes fully supported releases, security-fix-only releases and EOL releases. A long term support (LTS) release is fully supported for four years, plus one more year of security fixes only. As read on 17 October 2026, Asterisk 18 and older were EOL, Asterisk 21 was in security-fix-only maintenance ending 18 October 2026, and Asterisk 20 was due to move to security fixes only from 19 October 2026. Those labels change every few months, so the live Asterisk Versions page is the source to use on the day of the check.

FreePBX

Sangoma's FreePBX versions table records that version 15 reached EOL on 1 October 2025, leaving 16 and 17 supported. It also says the SNG7 operating system beneath FreePBX 16 is itself EOL and not supported, and that FreePBX 16 may reach EOL sooner because of it. That is why a supported application label does not settle the status of the whole server.

If you are planning a new installation, use the FreePBX setup guide alongside the current lifecycle table. If you already have FreePBX, record the PBX version, Asterisk version, operating-system release and installed commercial modules separately.

3CX

3CX states that Version 18 is EOL. Its March 2026 notice says components including the Remote Provisioning Service and the Automatic Global IP Blacklist no longer receive security updates on Version 18, and directs remaining users towards Version 20.

For a self-hosted installation, check both the 3CX build and the supported operating-system requirements. The self-hosted versus cloud guide covers the broader deployment trade-offs.

Our view: An unsupported production version is the strongest reason to schedule an upgrade or migration. Reducing internet exposure helps while work is organised, but it does not create future security fixes for abandoned software.

Internet Exposure Changes the Urgency

Session Initiation Protocol, or SIP, is the signalling language that sets up internet phone calls, much like the receptionist exchanging details before connecting two people. A PBX may need selected SIP traffic from its carrier, but that does not mean its administration page needs to accept connections from the entire internet.

Ask the administrator to document which management and voice services are reachable externally, by whom, and why. Do not accept “it has a firewall” as the complete answer, because a firewall can intentionally permit a service that is still exposed too broadly.

Exposure changes the consequence of delay. A vulnerable component reachable only through a controlled administration path presents a different operating condition from the same component exposed globally, although both still need a supported version and a patch plan.

A Patch Cadence a Small Business Can Run

A workable process separates alert monitoring from routine maintenance. Checking updates once a month is not enough if nobody receives an urgent vendor notice between visits.

Use this operating rhythm:

• Monitor vendor security notices and CISA KEV changes continuously through email, RSS or a managed monitoring service.
• Review the PBX inventory and available routine updates at least weekly.
• Keep an approved emergency-change path so the patch owner does not wait for a director to return from leave.
• Take or confirm a recoverable backup before material updates.
• Record the old version, new version, update time, validation result and rollback decision.
• Test inbound, outbound and internal calls, important call routes, voicemail and required integrations after maintenance.

For an online service or internet-facing server, the Australian Cyber Security Centre's patching guidance recommends applying patches or vendor mitigations within two weeks. Where the vendor identifies a critical vulnerability or a working exploit exists, it recommends action within 48 hours.

A vulnerability already listed by CISA as known exploited has, by definition, a working exploit. For a PBX in that position, “we will look at it next month” is not an adequate target.

A practical severity rule is:

The first two rows reflect ACSC guidance. The latter two are editorial operating rules designed to stop a small business from remaining indefinitely on an old release.

Automatic updates can reduce delay, but they do not remove ownership. Someone must confirm that updates ran, investigate failures and know whether an emergency mitigation is required before a stable update becomes available.

Who Carries the Operational Risk?

When the PBX fails or is compromised, the business experiences the immediate consequences: calls may stop, customer information may be exposed, staff may lose access, and unexpected call charges may appear. That statement concerns operational impact, not a conclusion about legal liability.

Responsibility for remediation or charges can depend on the contracts among the business, IT provider, PBX vendor and SIP provider. A SIP provider supplies the connection that carries internet phone calls to and from the public telephone network, like a wholesaler connecting a private switchboard to the wider telephone system.

Put these items into the managed-service scope:

• The named role responsible for the operating system, PBX, modules and client applications.
• The advisory sources that role monitors and whether monitoring continues outside business hours.
• A 48-hour response target for vendor-critical or known-exploited internet-facing vulnerabilities.
• Authority to apply an emergency vendor mitigation or restrict exposure.
• Backup ownership, storage location, retention and restore-testing frequency.
• Evidence supplied after patching, including versions and validation results.
• The response process when compromise is suspected.
• The handover process when the technician or provider changes.

Ask the SIP provider separately about international-calling controls, spend or usage alerts, service suspension triggers and the process for disputing unexpected charges. Do not assume an alert, limit or refund exists unless the contract or service description says so.

For wider comparisons of the two platforms, see 3CX versus FreePBX. The important security distinction here is not the logo, but whether the selected deployment has an accountable maintainer.

Keep Self-Hosting or Move to Hosted?

Keep self-hosting when all of the following are true:

• A named employee or contracted provider has current Linux, Windows and PBX administration capability appropriate to the installation.
• Patching, monitoring, backup and version-lifecycle duties are documented.
• The team can respond to urgent notices within the ACSC timeframe.
• Current integrations, data-location needs or specialised call flows materially benefit from direct control.
• Recovery has been tested and the business accepts the maintenance burden.

Move towards a hosted service when any of these conditions applies:

• Nobody can name the current PBX, operating-system or module versions.
• The previous administrator left and no formal handover exists.
• The business cannot monitor advisories or patch urgent vulnerabilities within 48 hours.
• The installed version is unsupported and there is no funded migration plan.
• The only reason for self-hosting is that the server already exists.

Hosted service shifts most platform maintenance to a provider, but it does not transfer every security task. Your business still needs to manage administrator accounts, user departures, permissions, desk phones, integrations, provider contacts and continuity arrangements.

The on-premise PBX decision guide covers the broader operational case, and our cloud versus office phone system comparison sets out the day-to-day trade-offs. Businesses ready to compare managed options can also use the hosted PBX provider guide to form a shortlist without assuming every hosted contract has the same scope. If you are choosing a whole phone system rather than just a host, start with our small business phone system guide.

Australian Businesses: What You Need to Know

The Australian Cyber Security Centre's patching timeframes are recommendations, not statements in this article about what the law requires. The useful operating benchmark for an internet-facing PBX is within 48 hours when the vendor rates a vulnerability critical or a working exploit exists, and within two weeks for other vulnerabilities affecting the online service.

If the PBX is compromised, preserve relevant records and use a separate, trusted device for reporting. The Australian Government's ReportCyber pathway directs businesses to the appropriate cybercrime, cyber incident or vulnerability report, and the Australian Cyber Security Hotline is 1300 CYBER1 (1300 292 371). It does not replace contacting the PBX administrator, SIP provider, insurer or professional incident-response support required by your circumstances.

For disputed telco charges, check the provider contract and complain to the provider first. The Telecommunications Industry Ombudsman says it helps people and small businesses resolve phone and internet problems, and billing complaints are among the most common it handles. Eligibility and outcomes depend on the facts, so this is a signpost rather than a view on who must pay.

Hosting does not remove dependence on the NBN service, local network or power at each site. Security, call quality and continuity are separate checks: a well-patched hosted PBX can still deliver poor audio over a congested connection, while an on-premise server and its phones can stop when local power fails.

The ACMA emergency-calls guidance says only certain VoIP services can call Triple Zero and that most NBN-connected services will not work during a power outage. Confirm 000 support, registered service addresses, battery arrangements and a charged mobile fallback with the actual providers at each site.

The move away from legacy public switched telephone network, or PSTN, services does not make every Australian site identical. The PSTN is the traditional carrier telephone network, like the old road system beneath fixed-line calls. Confirm each site's access technology and outage behaviour instead of assuming a single national copper status.

A hosting migration also does not always require a number port. If porting is required, obtain a written estimate and prerequisites from the gaining provider rather than relying on a generic timeline. Include any 13, 1300 or 1800 routing in the migration and failover plan, but those number types do not change who owns PBX patching.

What Most Businesses Get Wrong

Mistake 1: Treating a working PBX as a maintained PBX

Uptime proves that the service is running. It does not prove that the operating system, PBX and modules are supported or patched.

Mistake 2: Assuming the cloud provider patches the application

An unmanaged VPS provider may maintain physical infrastructure while leaving the guest operating system and PBX to the customer. Confirm the managed scope in the contract.

Mistake 3: Naming a company instead of an accountable person

“IT handles it” is not an owner. Record a primary person, a backup person, their authority and the evidence they must provide after urgent work.

Your Next Steps

• Write down the PBX product, exact build, operating system, Asterisk version where applicable, modules and externally reachable services.
• Check each major component against its live vendor lifecycle page.
• Name the primary patch owner and backup owner today.
• Put the 48-hour urgent response target and evidence requirements into the support arrangement.
• Confirm off-system backups and conduct a controlled restore test.
• Ask the SIP provider about international-calling controls, alerts and disputed-charge procedures.
• If no capable owner can accept these duties, document a move to hosted service and compare the available path through the phone-system recommendation flow.

Is FreePBX safe for a small business?

FreePBX can be a reasonable choice when it runs on supported components and a capable administrator owns updates, monitoring, exposure and recovery. It is a poor fit when nobody can state the version or respond to an urgent advisory.

How quickly should a known-exploited PBX vulnerability be patched?

For an internet-facing component, use 48 hours as the outside target when a working exploit exists or the vendor rates the vulnerability critical. That reflects ACSC guidance, and a vendor mitigation may be necessary if a normal patch is not yet available.

Does putting a PBX on a cloud VPS make it managed?

No. A VPS changes where the server runs, but application and operating-system maintenance normally remain with the customer unless a management agreement explicitly includes them.

Are automatic PBX updates enough?

Automatic updates reduce some delay, but an owner must verify success, respond to failures and handle advisories that require configuration changes, isolation or client-app updates. Backups and post-update call testing also remain necessary.

Can an unsupported PBX remain in use if it is behind a firewall?

Reduced exposure lowers some risk, but unsupported software may not receive a fix for the next vulnerability. Treat isolation as a temporary control while upgrading or retiring the system, not as a permanent substitute for vendor support.

Does a hosted PBX remove all security responsibility?

No. The provider may manage infrastructure and application patches, while the customer retains user accounts, permissions, phones, integrations, backup choices and contract oversight. Confirm the actual division before signing.

What proof should an IT provider supply after patching?

Ask for the affected asset, previous and installed versions, completion time, update result, call-validation result and any follow-up action. That creates an auditable record without requiring the business owner to administer the server.