FreeSWITCH flaw lets one SIP MESSAGE run server commands

FreeSWITCH flaw lets one SIP MESSAGE run server commands

28 October 2026: The FreeSWITCH project has disclosed CVE-2026-116779, a critical flaw rated 9.8 that lets a peer run FreeSWITCH API commands by sending a single SIP MESSAGE. The advisory says that "exploitation of this path has been observed in the wild". The fix shipped in version 1.11.3 on 28 August 2026, two months before the advisory was published on 28 October. Any phone system, contact centre or VoIP service built on FreeSWITCH 1.11.2 or older is affected in its default setup.

Not yet independently verified. The project states the exploitation but does not say by whom or how widely; we found no CISA or national CERT report of it with detail. We will update this when it can be confirmed, and remove this note.

How the MESSAGE handler hands over the server

The flaw sits in mod_sofia's inbound MESSAGE handler, which splits the To user on a plus sign and treats the first half as the name of a chat protocol. mod_dptools registers a chat interface called "api" that passes its address to FreeSWITCH's API executor. A sender can therefore choose which API command the server runs. The advisory lists the impact as operating system commands with the privileges of the FreeSWITCH process, disclosure of configuration and credentials, and full call control. Where mod_lua is loaded, as the stock configuration does, inline Lua is a second route.

Chat handling is on unless a profile sets enable-chat=false, and the shipped vanilla configuration leaves it on for both the internal and external profiles. The inbound ACL does not cover MESSAGE. Where MESSAGE authentication is enforced, any one account is enough. And the stock directory file defines a user called "default" with no password, which authenticates unless allow-empty-password is set to false.

Upgrade, or turn chat off

Version 1.11.3 adds a per-profile setting, enable-chat-api-proto, that is off unless set, so the api route is closed by default. A MESSAGE that tries it is answered 403 and logged with its source. Until an upgrade, the project's workaround is enable-chat=false on every profile that does not need inbound SIP chat. It warns that auth-messages alone does not close the route, nor does disable_system_api_commands=true, which removes only the system command. It also advises removing directory users that have neither a password nor an a1-hash: the vanilla configuration ships two.

A second command execution flaw, fixed in 1.11.2

The same day the project published CVE-2026-116786, rated 8.8. A registered user on a bridged call can send a REFER whose Refer-To URI injects channel variables into the outbound leg FreeSWITCH creates. One of them, execute_on_originate, can reach the system application and so the shell. It is fixed in 1.11.2, and the workaround is disable-transfer=true, which also stops all SIP-initiated transfers on that profile. Products that bundle FreeSWITCH carry their own release schedules, so customers of those should ask their vendor which FreeSWITCH version they ship. We list 15 VoIP products.

Related on TrustList:

• Openreach says 300,000 business lines are still on copper before PSTN ends
• Mitel fixes OpenScape Endpoint Management bypass; Brotli fix planned
• Slican fixes three flaws in IPx phone exchanges; old models stay exposed

Sources

• FreeSWITCH security advisory GHSA-mg63-h38w-8p9p: Inbound SIP MESSAGE can select the api chat proto and run FreeSWITCH API commands, 28 October 2026
• FreeSWITCH security advisory GHSA-xjxm-9qx6-w3fj: Channel-variable injection via SIP REFER leads to command execution in mod_sofia, 28 October 2026
• FreeSWITCH release notes: v1.11.3, 28 August 2026