FreeSWITCH 1.11.3 Fixes a SIP MESSAGE Flaw Already Used in Attacks

A remote peer that can get one SIP MESSAGE accepted by a FreeSWITCH profile can choose which FreeSWITCH API command the server runs, with the privileges of the FreeSWITCH process. SignalWire fixed the flaw, CVE-2026-116779, in FreeSWITCH 1.11.3 and says in its advisory that "Exploitation of this path has been observed in the wild."

CISA added the flaw to its Known Exploited Vulnerabilities list on Nov. 9. SignalWire published its advisory, GHSA-mg63-h38w-8p9p, on Oct. 28, which puts a 12-day gap between the vendor's warning and the federal one.

How a chat message becomes a command

The SIP handler treats part of the To user of an inbound MESSAGE as the name of a chat protocol. The api protocol, registered by mod_dptools, passes its address straight to the FreeSWITCH API executor. SignalWire's description: "A peer that can deliver a MESSAGE to a profile therefore selects which FreeSWITCH API command the server runs."

The impact is arbitrary operating-system commands, exposure of configuration and credentials, and full call control. If mod_lua is loaded, inline Lua is a second route. The advisory rates it 9.8 on the CVSS severity scale with the vector AV:N/AC:L/PR:N/UI:N, meaning network reachable, low complexity, no privileges and no user interaction. It credits Örn Arnarson as reporter and Gunnlaugur as analyst.

What the default configuration exposes

Chat is on by default and stays on in the stock conf/vanilla setup for both the internal and external profiles. The inbound ACL, the allow-list of source addresses, does not cover MESSAGE, so tightening it removes nothing.

The score overstates the risk where authentication is enforced and no passwordless users exist, because the attacker then needs an account on the profile. It understates the risk on installs that still carry conf/vanilla/directory/default/default.xml. The default user there has no password or hash, and per the advisory such a user authenticates successfully unless allow-empty-password is set to false for it.

Version	Status
1.11.2 and earlier	Affected
1.11.3 and later	Fixed, API proto off unless set

Workarounds that work and ones that do not

Setting enable-chat=false on any profile that does not need inbound SIP chat fully blocks the path on that profile. Switching on auth-messages alone does not: removing directory users without a password and enforcing authentication leaves authenticated command execution. Setting disable_system_api_commands=true removes only the system API, and the other APIs stay reachable.

The GPUStack admin bypass, listed in the same CISA bulletin, is a similar story of a default that trusts the network. The 1.11.3 fix adds a per-profile enable-chat-api-proto parameter, off unless explicitly set. A rejected request gets a 403 and a log line carrying the source and the requested command, which gives operators something to search for in old logs. Messages with no proto selector, or naming other protos, route as before.

A second MESSAGE problem, five years apart

This is not the first time FreeSWITCH's MESSAGE handling has been the problem. Enable Security's advisory ES2021-07, published Oct. 25, 2021 as CVE-2021-37624, found that MESSAGE requests were not authenticated by default through 1.10.6, so a sender could forge identities such as "911". The fix in 1.10.7 left auth-messages as an opt-in. That 2021 problem was spoofing; the 2026 one reaches the command interpreter.

SignalWire's advisory names no attacker and no victim count, and CISA's bulletin does the same. Operators on 1.11.2 or earlier should upgrade to 1.11.3, and those who cannot should set enable-chat=false first and then search SIP logs for MESSAGE requests addressed to api. For another exploited command-injection class bug in telephony software, see the Cisco BroadWorks XXE flaw.