FreeSWITCH CVE-2026-116779 Lets One SIP Message Run Commands, and CISA Lists It as Exploited

A single inbound SIP MESSAGE can make a FreeSWITCH server run its own API commands, OS commands included, with the daemon's privileges. CISA put the flaw, CVE-2026-116779, in its Known Exploited Vulnerabilities catalogue on 9 November and gave US federal agencies until 12 November to deal with it. SignalWire's own advisory already said that "exploitation of this path has been observed in the wild". The CVE record scores it 9.8, critical.

How the message gets through

The bug is in mod_sofia's handler for SIP MESSAGE. Before 1.11.3 it "split the To user of an inbound SIP MESSAGE on a plus sign" and took the first half as the chat protocol, so a sender who picked api had the text executed as a FreeSWITCH command. Chat handling is on unless a profile sets enable-chat=false, and the advisory states that "no non-default setting is required".

Authentication and the ACL both leave the route open. Where messages must be authenticated, any one account on the profile is enough, and the stock directory defines a default user with no password and no a1-hash. And the inbound ACL does not cover MESSAGE, so tightening it leaves the route open.

CISA's assessment in the CVE record rates exploitation "active", the attack automatable and the technical impact total, while its catalogue gives ransomware use as "Unknown". Neither SignalWire's advisory nor CISA names an attacker.

Fixed version and stopgaps

FreeSWITCH 1.11.2 and earlier are affected; upgrade to 1.11.3.

The 1.11.3 release notes add an enable-chat-api-proto setting to gate the api chat proto in mod_sofia and mod_verto. The advisory says it's off by default, and a message that tries to select the api proto without it is refused with a 403.

Where the upgrade has to wait, SignalWire's advice is to set enable-chat=false on every profile that does not need inbound SIP chat. Turning on auth-messages is "not sufficient on its own" unless directory users without a password are removed too, and disable_system_api_commands=true removes the system API but not the route.