FreeSWITCH: a single SIP message can run commands on the server, and the flaw is being exploited

Top-Secured cyber watch: independent analysis based on the sources listed below. Top-Secured is not affiliated with the companies mentioned and will never ask you for your bank details or passwords.

A flaw in FreeSWITCH, the open-source telephony server, lets a SIP MESSAGE request run commands on the machine, in the default configuration. The maintainers report exploitation in the wild and CISA added CVE-2026-116779 to its catalogue of exploited vulnerabilities on 9 November 2026; version 1.11.3 fixes it.

What happened

The FreeSWITCH maintainers published a security advisory on 28 October 2026 for CVE-2026-116779, a flaw in the open-source telephony server used for IP PBXs, call centres and SIP gateways. The advisory rates it 9.8 out of 10 and states that exploitation has been observed in the wild. On 9 November, the US agency CISA added it to its catalogue of actively exploited vulnerabilities, giving federal agencies until 12 November to act and requiring a forensic check.

How attackers get in

When FreeSWITCH receives a SIP MESSAGE, the instant-messaging request of the SIP protocol, it reads the recipient name to choose which chat module delivers it. One of these modules, called api, hands its content straight to the FreeSWITCH command interpreter. An attacker can therefore pick a command and have it run with the rights of the FreeSWITCH process: system commands, reading the configuration and passwords, placing calls. Where the Lua module is loaded, as in the stock configuration, arbitrary Lua code can run too.

The default configuration is exposed: chat is on for the internal and external profiles, and the inbound ACL does not filter these messages. If message authentication is enforced, one SIP account, such as a handset or a trunk, is enough. Servers that kept the sample user named default, which has no password, need no account at all.

All versions up to 1.11.2 are affected. Version 1.11.3 adds the enable-chat-api-proto parameter, off by default: such messages are then refused with a 403 and logged.

What to do now

1. Check the version with fs_cli -x version and upgrade to 1.11.3 or later.
2. Until then, set enable-chat to false on every SIP profile that does not need inbound chat. Message authentication or disable_system_api_commands reduce the risk but do not close the hole.
3. Delete directory users without a password: the vanilla configuration ships two, default and the Skinny example.
4. Look for traces: SIP MESSAGE requests whose recipient starts with api+ in your logs or captures, unknown processes started by the freeswitch user, recently changed files. If in doubt, rotate SIP and trunk passwords.
5. Restrict the SIP ports to your operator and your own sites instead of the whole Internet.

Our take

A telephony server is a server like any other, often installed once and then forgotten. Put it in your inventory and patch cycle, and remove sample accounts and unused features: here, a chat function nobody needed was enough to hand over the machine.

Sources

• FreeSWITCH (GitHub) — Inbound SIP MESSAGE can select the api chat proto and run FreeSWITCH API commands (GHSA-mg63-h38w-8p9p)
• CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-116779 (SignalWire FreeSWITCH)

How we choose, verify and write our analyses →