FreeSWITCH SIP MESSAGE injection exploited to run API and OS commands
One SIP MESSAGE can make FreeSWITCH 1.11.2 and earlier run arbitrary API and OS commands. Installs that keep the sample passwordless user need no account. It is exploited in the wild and in CISA KEV. Upgrade to 1.11.3 before the 2026-11-12 KEV deadline.
What you need to know
- Affects FreeSWITCH 1.11.2 and earlier on any SIP profile that accepts inbound MESSAGE. Stock configs enable this on both internal and external profiles.
- A single accepted SIP MESSAGE can run any FreeSWITCH API command. That gives OS command execution, credential disclosure and full call control.
- Exploited in the wild per the vendor. In CISA KEV since 2026-11-09 with a 2026-11-12 due date and forensic triage required.
- Upgrade to 1.11.3, which closes the api chat route by default. If you cannot patch yet, set enable-chat=false on profiles that do not need inbound chat.
- After patching, watch for 403 responses to MESSAGE requests that try to select the api proto. The logs record the source and the requested command.
What's happening
A command injection flaw in SignalWire FreeSWITCH lets a SIP peer choose which FreeSWITCH API command the server runs by sending one SIP MESSAGE 1. The result is command execution with the FreeSWITCH process's privileges. That includes arbitrary OS commands, reading configuration and credentials, and full call control 1. Versions up to and including 1.11.2 are affected and 1.11.3 contains the fix 1,2. The vendor rates it critical at CVSS 9.8 1.
Default deployments are exposed. Inbound chat stays enabled unless a profile sets enable-chat=false, and the shipped conf/vanilla configuration keeps it enabled on both its internal and external SIP profiles 1. Where MESSAGE authentication is enforced, any account that can register is enough 1. Installations that still carry the sample default.xml directory file need no account at all. That file defines a default user with no password, and such users authenticate unless allow-empty-password is set to false 1. CISA notes that FreeSWITCH is an open-source component that other products may embed 3.
SignalWire's advisory, published 2026-10-28, says exploitation of this path has been observed in the wild 1. CISA added the CVE to its KEV catalog on 2026-11-09 "based on evidence of active exploitation" 4. It set a 2026-11-12 remediation date and flagged the entry for forensic triage 4,3. KEV lists ransomware use as unknown 3. Neither source names an actor, publishes indicators or gives a first-exploitation date 1,3. It is therefore unknown whether attacks began before the fix shipped.
How it works
The bug is in mod_sofia's inbound MESSAGE handler, sofia_presence_handle_sip_i_message. The handler treats part of the To user as a chat-protocol selector and hands the message to whichever chat interface matches 1. mod_dptools registers an api chat interface that passes its address to switch_api_execute(). As a result, the sender of an accepted MESSAGE decides which API command runs 1. Nothing limits the selector, and protocols meant for message delivery are not separated from ones that execute commands 1.
mod_lua adds a second reachable sink. The stock configuration loads mod_lua, and it accepts inline Lua with the full standard library 1. Two common hardening steps do not help. The inbound ACL does not apply to MESSAGE, so tightening it leaves a profile in scope 1. MESSAGE authentication has been on by default since 1.10.7, but it only raises the bar to one valid account or a passwordless directory user 1.
The 1.11.3 release also adds the new gate to mod_verto and bounds the To-user split in the mod_sofia MESSAGE handler 2. The advisory describes only the mod_sofia path, so it is not confirmed whether mod_verto was independently exposed 1.
What to do
In order of priority- 1
Upgrade to FreeSWITCH 1.11.3 or later. The vendor describes it as an important release with critical security fixes and urges all users to upgrade 2,1.
- 2
Leave the new per-profile
enable-chat-api-protoparameter unset. It defaults to off, which closes the api route on every profile, while normal chat messages route as before 1. Enable it only where a trusted use case truly needs it. - 3
If you cannot patch immediately, set
enable-chat=falseon every profile that does not need inbound SIP chat. This drops the message before the selector is parsed, but it also disables all inbound MESSAGE chat on that profile 1. - 4
Treat other hardening as partial. Enforcing auth-messages and removing passwordless directory users still leaves authenticated command execution 1.
disable_system_api_commands=trueremoves thesystemAPI but still leaves module loading and call origination reachable 1. - 5
Restrict SIP exposure with network-level filtering so only known peers and trunks can reach FreeSWITCH profiles. Do not rely on the FreeSWITCH inbound ACL, which does not cover MESSAGE 1.
- 6
Investigate hosts that were reachable while unpatched as possibly compromised. The flaw exposes configuration and credentials and runs OS commands 1,3. Rotate SIP account, trunk and other credentials stored in the FreeSWITCH configuration, and review the host for persistence.
- 7
Federal agencies must apply vendor mitigations per BOD 26-04 by 2026-11-12, or stop using the product if mitigations are unavailable 3.
Detection
- Inventory FreeSWITCH builds at 1.11.2 or earlier. Check for products that embed FreeSWITCH, since CISA notes it is an open-source component used elsewhere 3.
- Audit SIP profiles for
enable-chat(on unless explicitly false). Audit the directory for users with neither a password nor ana1-hash, especiallydefaultfromconf/vanilla/directory/default/default.xmland the Skinny example user 1. - On 1.11.3 and later, a MESSAGE that tries to select the
apiproto on a profile withoutenable-chat-api-protogets a 403 response. The log entry includes the source and the requested command, so alert on these entries 1. - On unpatched hosts, review SIP logs or packet captures for inbound MESSAGE requests whose To user carries a chat-proto selector. Treat any reference to
apior Lua as suspicious, and correlate with the source IPs and accounts that sent them. - Hunt for child processes of the FreeSWITCH process, such as shells, downloaders or interpreters. Also look for unexpected module loads, unexplained call originations and new files in the FreeSWITCH install and config directories. These match the impact the vendor describes 1.
- CISA has flagged this CVE for forensic triage under BOD 26-04. Federal agencies must check whether systems were compromised before the patch was applied, not just install it 4. Other organizations should do the same. Do not delay patching to do this.
Timeline
Sources
- 1Inbound SIP MESSAGE can select the api chat proto and run FreeSWITCH API commandsSignalWire / FreeSWITCH (GitHub Security Advisory) · Vendor · Oct 28, 2026
- 2FreeSWITCH v1.11.3 ReleaseSignalWire / FreeSWITCH · Vendor
- 3CISA KEV entry for CVE-2026-116779CISA · Government · Nov 9, 2026
- 4CISA Adds Four Known Exploited Vulnerabilities to CatalogCISA · Government · Nov 9, 2026
Confirmed by vendor and government. Researched and drafted by the VulnDigest briefs agent from 4 sources, then checked against them by a separate review step on Nov 9, 2026.
Exploitation is confirmed by the vendor advisory and the CISA KEV listing. No actor, campaign details, scale data or first-exploitation date has been published.
It is not known whether exploitation began before the fix was released.
Neither the vendor nor CISA has published indicators of compromise for this flaw.
The 1.11.3 release also adds the api-proto gate to mod_verto. The vendor has not said whether mod_verto was independently exploitable.
Products that embed FreeSWITCH have not been listed. Check with your suppliers whether their products include a vulnerable build.
Spotted an error? Open an issue on sochub.io.