FreeSWITCH SIP MESSAGE Flaw Turns Chat Into Server Control

CISA added CVE-2026-116779 to the Known Exploited Vulnerabilities catalog on November 9. SignalWire's FreeSWITCH advisory says the flaw lets an accepted inbound SIP MESSAGE select the internal api chat protocol and execute FreeSWITCH commands. The resulting authority includes operating-system command execution with the FreeSWITCH process's privileges, configuration and credential access, module loading and full call control. The maintainer reports that this path has been exploited in the wild.

FreeSWITCH 1.11.3 is the fixed release for this issue. Operators should upgrade every exposed instance, restart it, confirm the running build and inspect every SIP profile that accepts MESSAGE. Disabling chat on profiles that do not need it closes the route temporarily. MESSAGE authentication, inbound ACL settings and disabling only the system API do not independently remove the dangerous dispatch path. Because exploitation crosses from a signaling message into server control, previously reachable systems need process, configuration, call and credential review in addition to patching.

FreeSWITCH is a real-time communications platform that terminates SIP signaling, routes calls, handles chat messages and exposes administrative APIs. That concentration of functions makes protocol separation essential. The published flaw begins as an inbound SIP MESSAGE, a normal request used for instant messaging and related signaling. It ends inside an API dispatcher that can control calls, read configuration or invoke operating-system commands.

SignalWire published GHSA-mg63-h38w-8p9p on October 28, assigned CVE-2026-116779, rated it critical at 9.8 and stated that exploitation had been observed in the wild. CISA added it to the KEV catalog on November 9 with a November 12 federal remediation deadline. The vendor does not publish a campaign timeline, victim count, indicators or an attribution, so the confirmed statement is exploitation of the path, not a named actor or uniform payload.

The lack of campaign detail should not postpone containment. A communications server commonly holds trunk credentials, directory data, call routing, event-socket access and integrations with databases or billing systems. Code execution under the FreeSWITCH service account can therefore change live communications and provide a route to adjacent systems even when the process is not running as root.

The vulnerable mod_sofia handler splits the destination user in an inbound MESSAGE at a plus sign and treats the left portion as the name of a chat protocol. That mechanism can dispatch ordinary messages to a registered delivery interface. The problem is that mod_dptools also registers an interface named api, and that interface passes its address into FreeSWITCH's general API executor.

The handler did not distinguish a message-delivery protocol from a command-execution protocol. A peer able to get one MESSAGE accepted by the SIP profile could therefore select the api interface and supply the command address. The vendor lists arbitrary FreeSWITCH API execution, full call control, configuration and credential disclosure, and operating-system command execution with the service's privileges. When mod_lua is loaded, as in stock configuration, inline Lua with its standard library is another reachable sink.

This is more than shell metacharacter filtering. The message should never have been authorized to choose a privileged internal interface in the first place. A safe design makes protocol registration carry an explicit purpose and checks that purpose before dispatch. The 1.11.3 change implements a narrower compatibility gate, but deployments should still treat chat, call control and administration as separate authorities.

The advisory says any SIP profile accepting inbound MESSAGE is in scope. Chat handling remains on unless the profile sets enable-chat to false, and the stock vanilla configuration leaves it enabled on internal and external profiles. FreeSWITCH's current SIP profile documentation likewise describes enable-chat as on by default. The maintainer also warns that the inbound ACL does not cover MESSAGE for this purpose, so tightening that application setting alone does not prove the path is unreachable.

MESSAGE authentication has been enabled by default since FreeSWITCH 1.10.7, but authentication is not authorization for server commands. Any account on the profile, including an extension, registered handset or trunk peer, can satisfy the prerequisite. If a handset is compromised or a trunk relationship is abused, a low-authority signaling identity can cross into the server control plane.

Some installations have an even lower bar. The vendor calls out deployments that still carry stock example directory users without a password or A1 hash. Unless allow-empty-password is disabled for those users, they can authenticate without a secret. Inventory therefore needs to include SIP profiles, MESSAGE settings, registered and static peers, directory records, example configuration retained from installation and the actual network paths that can deliver signaling.

SignalWire lists FreeSWITCH 1.11.2 and earlier as affected and 1.11.3 or later as patched. The 1.11.3 release adds a per-profile enable-chat-api-proto setting and leaves it off unless an administrator explicitly enables it. When an inbound MESSAGE tries to select the api protocol without that opt-in, the server answers with a 403 response and records the source and requested command. Other chat protocols and messages without the privileged selector continue to route normally.

Upgrade every instance, downstream PBX image and standby node, restart the service and verify the loaded binary rather than only the package database. Test inbound and in-dialog messaging, registrations, trunks, call routing, event-socket integrations and monitoring before returning full traffic. The release also dropped Debian 11 from its tested support path, so operators on older packaged systems should coordinate the FreeSWITCH and operating-system migration rather than silently pinning an affected build.

Do not re-enable enable-chat-api-proto as a shortcut for a broken application unless there is a documented, isolated dependency and an explicit risk decision. The new switch is a compatibility escape hatch that restores the dangerous authority. If an application truly needs command execution, place it behind a separately authenticated management interface with scoped commands, source restrictions and auditable identities instead of encoding that authority in a general chat address.

Setting enable-chat to false on every profile that does not need inbound SIP chat stops processing before the protocol selector and is the maintainer's direct temporary closure. It also disables legitimate MESSAGE delivery, so the operational effect should be tested. External network controls that restrict signaling to known session border controllers, trunks or managed endpoints add containment, but they do not substitute for the version fix when any allowed peer can deliver MESSAGE.

Requiring authentication for MESSAGE is useful hygiene and removing every passwordless directory example reduces unauthenticated reachability. Neither closes the command route for valid low-privilege peers. The advisory also says disable_system_api_commands removes one operating-system execution interface but leaves other registered APIs, including module loading and call origination, reachable. Treat it as defense in depth rather than remediation.

Containment should preserve evidence. Save SIP traces or packet captures where policy permits, mod_sofia and console logs, service journals, configuration snapshots, call-detail records, registration history and process telemetry before rotating everything at once. Restrict SIP exposure, end unneeded registrations and disable affected profiles or chat handling while the patch is staged. Avoid deleting unfamiliar files or accounts until their timestamps and provenance are captured.

Look for unusual inbound MESSAGE activity, destinations that select a protocol rather than a normal user, unexpected API execution, module loads, call origination, recording or routing changes and new child processes of the FreeSWITCH service. Review filesystem changes under configuration, scripts, recordings and service directories; new scheduled tasks or startup entries; outbound connections; database queries; and access to credential files. Patched 403 logs are useful for new attempts but cannot reconstruct commands already accepted by an older build.

Scope the authority of the service account and loaded modules. Rotate SIP and trunk secrets, event-socket passwords, database credentials, provider tokens, TLS private keys and application secrets only when the affected process could read them. Validate downstream call routing, billing, voicemail, recordings and conferencing state. If commands ran or host integrity cannot be established, isolate and rebuild the server from a trusted image before reconnecting trunks or restoring secrets.

The long-term control is purpose-bound dispatch. A message parser should be able to deliver a message, not name any registered server function. Low-privilege endpoints should receive identities and permissions that cannot administer the switch. Management APIs should live on a separate network boundary with explicit command allowlists and complete audit records. CVE-2026-116779 is urgent because exploitation is confirmed, but its durable lesson is architectural: real-time signaling and server administration cannot safely share an untyped routing namespace.