FreeSWITCH: one SIP MESSAGE is enough to run commands on your VoIP server

What happened

FreeSWITCH is an open-source telephony platform. Organisations use it to build their own PBXs, contact centres, conferencing systems and voice applications, and telecoms providers run it too. It's maintained by SignalWire.

On 28 October 2026 SignalWire published advisory GHSA-mg63-h38w-8p9p for a critical flaw now tracked as CVE-2026-116779. An attacker can send an ordinary SIP MESSAGE request (a text message within the SIP protocol) and get FreeSWITCH to run any API command they choose. Some of those commands execute operating system commands, so the attacker can take over the server with the privileges of the FreeSWITCH process, read its configuration and credentials, and control calls.

The advisory states that exploitation has been observed in the wild. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 9 November 2026 and gave US federal agencies only until 12 November 2026 to deal with it – an unusually short deadline that signals urgency.

How serious is it?

A compromised PBX is more than a phone problem. An attacker can run commands on it, read stored SIP account and trunk credentials, and place calls at your expense – for example to premium-rate international numbers. The server can also be a stepping stone into the rest of your network.

Technical details

The bug sits in mod_sofia, the FreeSWITCH SIP module, in sofia_presence_handle_sip_i_message(), the handler for inbound MESSAGE requests. It splits the user part of the To header on + and treats the left-hand side as the name of the "chat protocol" that should deliver the message.

That selector wasn't restricted. Meanwhile mod_dptools registers an api chat protocol that hands the message body to switch_api_execute() – in other words, it runs a FreeSWITCH API command. The vendor puts the root cause down to FreeSWITCH not separating message-delivery protocols from command-execution ones. There's a second route through mod_lua, which the stock configuration loads: it allows inline Lua with the full standard library.

The conditions, according to the vendor:

• Default settings are enough. Chat is on by default, and the stock conf/vanilla configuration enables it on both the internal and external SIP profiles.
• ACLs don't help. The inbound ACL doesn't apply to MESSAGE requests, so tightening it won't stop the attack.
• One account is enough. Where MESSAGE authentication is enforced, any account on the profile will do – even one that can only register a phone.
• Sometimes no account at all. Installations that still carry conf/vanilla/directory/default/default.xml include a default user with no password. That user authenticates unless allow-empty-password is set to false.

We don't publish exploitation details or sample payloads.

Who is affected

According to the vendor and NVD, every FreeSWITCH version up to and including 1.11.2 is vulnerable. Version 1.11.3 contains the fix.

That covers businesses, public bodies, hospitals and anyone else running their own PBX or contact centre on FreeSWITCH, VoIP providers, and vendors who ship FreeSWITCH inside their own products. If someone else runs your phone system, ask them whether it's built on FreeSWITCH and which version they use. Ordinary phone users don't need to do anything; this is a job for whoever administers the server.

How to tell if you were compromised

The vendor hasn't published specific indicators of compromise such as IP addresses or sample payloads. It recommends watching for:

• Rejected messages in the log. After upgrading to 1.11.3, FreeSWITCH answers any MESSAGE that selects the api protocol with a 403 and logs the source and the requested command. Those entries mean someone tried the attack.
• Suspicious MESSAGE requests in SIP traces. Inbound MESSAGE requests whose To user contains a + with api on the left.
• Users without passwords. Directory users with no password or a1-hash, especially default.
• Unexpected API activity. Module loads, call originations or system calls with no matching legitimate admin session.

We'd also suggest reviewing call detail records (CDRs) for unusual international or premium-rate calls, processes running as the FreeSWITCH user, and recent configuration changes. Paste exported log lines into our IOC extractor to pull out source IP addresses – it runs entirely in your browser. If you can't rule out a compromise, treat the server as compromised: rebuild it from a clean install and rotate every credential it held, including your carrier trunk credentials.

What to do

1. Check the version on every FreeSWITCH server (fs_cli -x version).
2. Upgrade to FreeSWITCH 1.11.3 or later. The fix adds a per-profile enable-chat-api-proto setting that stays off unless you explicitly turn it on. Leave it off.
3. If you can't upgrade straight away, set enable-chat to false on every SIP profile that doesn't need inbound chat. That stops the message before the protocol selector is parsed, but it also disables all inbound MESSAGE chat on that profile. Reload the profile after the change.
4. Remove users without passwords (the stock default user and the Skinny example from conf/vanilla) and keep allow-empty-password set to false. According to the vendor this doesn't fix the flaw on its own; it only limits the attack to authenticated accounts.
5. Don't rely on partial measures. Neither auth-messages on its own nor disable_system_api_commands=true stops the attack, the vendor says.
6. Limit SIP exposure to your carrier's and remote sites' addresses wherever you can. Our subnet calculator helps you get CIDR ranges right for firewall rules. This is general good practice, not vendor guidance.
7. Run the compromise checks above, especially on internet-facing servers.
8. Report incidents to your national CERT – in the UK the NCSC, in the US CISA.

Timeline