CVE-2026-116779 is a command-execution flaw in FreeSWITCH, the open-source software switch used to build SIP PBXs and voice, video, WebRTC and messaging services. It matters to the teams operating business phone systems, contact centres, IVR and conferencing platforms, SIP trunking gateways, hosted VoIP, and communications products—not merely to developers embedding the software.
The dangerous part is an inbound SIP MESSAGE, a protocol request normally used for instant-message-like traffic. On FreeSWITCH 1.11.2 and earlier, the handler parsed the user portion of the request's To address around a plus sign. The text before it selected a “chat protocol”; the text after it became that protocol's destination. Selecting api sent the destination into FreeSWITCH's API execution machinery.
A chat selector becomes a command route
That parsing choice means a peer whose MESSAGE is accepted can choose the api chat interface and make FreeSWITCH execute API commands with the privileges of the FreeSWITCH process. The consequences documented in the vendor advisory include configuration and credential disclosure, call control, operating-system command execution, and—where mod_lua is installed—another reachable command sink through inline Lua.
This is not simply “any packet from the internet owns every server.” A SIP profile must accept the inbound MESSAGE. But that can be a low bar: chat is enabled by default on FreeSWITCH's stock internal and external profiles. Where MESSAGE authentication is enforced, any account on that profile is enough. In affected configurations, stock directory users without password material can remove even that obstacle. Restricting the profile's inbound ACL is not a complete mitigation because that ACL does not cover MESSAGE traffic.
Patch the route, not just one command
SignalWire fixed the issue in FreeSWITCH 1.11.3, released August 28, 2026. The patch adds an enable-chat-api-proto control that is off unless an operator deliberately enables it. When api is selected while that flag is disabled, the server rejects the request with SIP 403 rather than handing it to the API path, as shown in the upstream change:
if (!strcasecmp(proto, "api") && !sofia_test_pflag(profile, PFLAG_ENABLE_CHAT_API_PROTO)) {
/* p is the rest of the To user, still percent-encoded and bounded by the proto buffer. */
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_WARNING,
"Profile [%s] rejected a MESSAGE from %s@%s (%s:%d) addressed to the 'api' chat proto [%s]. "
"Set enable-chat-api-proto=true on the profile to permit it.\n",
profile->name, switch_str_nil(from_user), switch_str_nil(from_host), network_ip, network_port, p);
nua_respond(nh, SIP_403_FORBIDDEN, NUTAG_WITH_THIS_MSG(de->data->e_msg), TAG_END());Upgrade every instance to 1.11.3 or later. Until that is complete, set enable-chat=false on every SIP profile that does not genuinely require inbound chat. Do not treat MESSAGE authentication as a fix, and do not rely solely on disable_system_api_commands=true: it removes one operating-system command sink but leaves other APIs, including module loading and call origination, reachable.
Exploitation is confirmed, details are not
The vendor says exploitation has been observed, and CVE-2026-116779 entered CISA's Known Exploited Vulnerabilities data on November 9, 2026, with a November 12 remediation due date for covered federal agencies. CISA records active, automatable exploitation and total technical impact. No victim, actor, campaign, geographic pattern, or ransomware connection has been publicly confirmed.
Public proof-of-concept material has surfaced, including a repository advertising a PoC, although independent validation that it works against a real vulnerable deployment was not available. The claimed November 1 first-publication date likewise could not be confirmed.
Treat exposed SIP profiles as urgent patch targets, then review which profiles need chat at all and whether their accounts, directory entries and network reachability remain justified. SecAlerts monitors an organisation's actual software stack and alerts on new vulnerabilities affecting the products it runs; for FreeSWITCH operators, that visibility needs to lead quickly to configuration review as well as patching.
