CVE-2026-116779: FreeSWITCH SIP MESSAGE Runs API Commands — Remote Command Execution

Background

FreeSWITCH is an open-source software telecom stack used for VoIP, PBX and conferencing. It processes SIP signalling received over the network. CVE-2026-116779 affects versions before 1.11.3. The GitHub advisory (GHSA-mg63-h38w-8p9p) says exploitation of this path “has been observed in the wild”, and CISA added the CVE to KEV on 9 November 2026.

Technical Mechanism

Per the advisory, sofia_presence_handle_sip_i_message() splits the To user of an inbound SIP MESSAGE on + and treats the left half as a chat protocol name, dispatching the message to the matching chat interface. mod_dptools registers an api chat interface that hands its address to switch_api_execute(). A peer able to deliver a MESSAGE to a profile can therefore pick which FreeSWITCH API command the server runs. Nothing restricts the selector, and message-delivery protocols are not distinguished from command-execution ones.

Where mod_lua is loaded, as in the stock configuration, the advisory says inline Lua with the full standard library is reachable as a second sink. The CNA (GitHub) scores it 9.8 (CWE-77, CWE-78, CWE-749 per the advisory), CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Real-World Exploitation Evidence

• The GitHub advisory states exploitation of this path has been observed in the wild. It gives no actor, campaign or victim details.
• CISA KEV: added 9 November 2026, due 12 November 2026. The ransomware-use field reads “Unknown” as of 10 November 2026.
• No threat actor attribution was found in the advisory or KEV entry as of 10 November 2026.

Impact Assessment

The advisory lists command execution with the privileges of the FreeSWITCH process: arbitrary OS commands, disclosure of configuration and credentials, and full call control. For telecom operators this includes toll fraud and call interception risk, which follow from call control; the advisory itself does not describe specific abuse.

Exposure is the default posture. Chat handling is on unless a profile sets enable-chat=false, and stock conf/vanilla leaves it on for both the internal and external profiles. The inbound ACL does not cover MESSAGE. Where MESSAGE authentication is enforced, any single account on the profile is enough. Installations still carrying conf/vanilla/directory/default/default.xml need no account of their own, because that file defines <user id="default"> with no password or a1-hash, and such a user authenticates unless allow-empty-password is set to false.

Affected Versions

Remediation Steps

1. Upgrade to FreeSWITCH 1.11.3. The fix adds a per-profile enable-chat-api-proto parameter, off unless explicitly set; a MESSAGE selecting the api proto where it is not enabled gets a 403 and a log entry with the source and requested command.
2. Until upgraded, set enable-chat=false on every profile that does not need inbound SIP chat. This stops the message before the selector is parsed.
3. Remove every directory user without a password or a1-hash. Stock conf/vanilla ships two, default and the Skinny example.
4. Do not rely on auth-messages alone, or on disable_system_api_commands=true. The advisory says neither closes the path.
5. Rotate credentials stored in FreeSWITCH configuration if a host was exposed.

Detection Guidance

Suggestions based on the advisory, not vendor signatures:

• Search SIP logs for MESSAGE requests whose To user contains + with an api prefix (for example api+...).
• After upgrading, 403 responses and log lines naming the requested command indicate attempted use of the closed route.
• Inspect FreeSWITCH child processes and outbound connections from the service account for unexpected shells.
• Review recent originate calls and module loads for activity you did not initiate.

Timeline

References

• GitHub Security Advisory GHSA-mg63-h38w-8p9p
• FreeSWITCH v1.11.3 release
• Fix pull request #3135
• CVE record
• NVD — CVE-2026-116779