FreeSWITCH CVE-2026-116779: Critical SIP MESSAGE Flaw Exploited in the Wild, Fixed in 1.11.3

On 28 October 2026, SignalWire, the maintainer of the open-source FreeSWITCH telephony platform, published advisory GHSA-mg63-h38w-8p9p for CVE-2026-116779 (SignalWire GHSA-mg63-h38w-8p9p). A single inbound SIP MESSAGE that the server accepts can make it run FreeSWITCH API commands, including operating system commands, with the privileges of the FreeSWITCH process. SignalWire rates it Critical, CVSS 3.1 9.8, and states: "Exploitation of this path has been observed in the wild."

The fix is not new. FreeSWITCH 1.11.3, released on 28 August 2026 (UTC; just after midnight on 29 August, Cyprus time), closes the path by default (FreeSWITCH v1.11.3 release). What changed on 28 October is that the details became public, while servers that never took the August update remain exposed. As of 29 October 2026 the CVE is not in CISA's Known Exploited Vulnerabilities (KEV) catalog, and NVD and the CVE Program had not yet published a record for it.

FreeSWITCH is a building block: it sits inside many hosted voice, contact-centre, conferencing and SIP trunking services, often out of sight. That makes this a supplier question as much as an internal patch.

Technical Information

What the flaw is. According to SignalWire, when FreeSWITCH receives a SIP MESSAGE (the SIP method used for text chat), its mod_sofia module splits the To user of the message on a + sign and treats the first part as the name of a chat protocol. One registered chat protocol, api, passes its address straight to FreeSWITCH's API command handler. Nothing restricts which protocol a sender selects, so a peer that can get a MESSAGE accepted chooses which API command the server runs. SignalWire lists the weaknesses as CWE-77, CWE-78 and CWE-749.

What an attacker can do, per SignalWire. Command execution as the FreeSWITCH process: arbitrary OS commands, disclosure of configuration and credentials, and full call control. Where mod_lua is loaded, which SignalWire says the stock configuration does, inline Lua with the full standard library is a second route.

Who is exposed. SignalWire says any SIP profile that accepts inbound MESSAGE is affected, and that this is the default:

• Chat handling is on unless a profile sets enable-chat=false, and the stock conf/vanilla configuration leaves it on for both the internal and external profiles. No non-default setting is needed.
• The inbound ACL does not cover MESSAGE, so tightening it does not take a profile out of scope.
• Where MESSAGE authentication is enforced, any one account on the profile is enough: an extension, a handset or a trunk peer with no permission beyond registering.
• Installations that still carry the sample file conf/vanilla/directory/default/default.xml need no account at all. That file defines a directory user with no password and no hash, and SignalWire says such a user authenticates successfully unless allow-empty-password is set to false for it.

How it was fixed. FreeSWITCH 1.11.3 adds a per-profile setting, enable-chat-api-proto, that controls whether an inbound MESSAGE may select the api protocol. It is off unless explicitly set, so upgrading closes the route on every profile. A MESSAGE that tries it is answered 403 and logged with the source and the requested command. The release notes add the same setting to mod_verto (v1.11.3 release; pull request #3135). If anyone turns the setting back on, the route reopens.

Other FreeSWITCH advisories this week. SignalWire published 20 further advisories on 26 and 28 October, all fixed in FreeSWITCH 1.11.2 (released 9 August 2026) and therefore also in 1.11.3. SignalWire reports exploitation only for CVE-2026-116779. Three matter most for exposure:

• CVE-2026-116786 (High, 8.8): a SIP REFER (call transfer) from a registered account can inject channel variables and lead to OS command execution. SignalWire says REFER is accepted by default (GHSA-xjxm-9qx6-w3fj).
• CVE-2026-116790 (Critical, 9.1): inbound ICE connectivity checks are accepted without verifying their integrity, so an unauthenticated sender who reaches the media port of a WebRTC or ICE call can redirect its media. SignalWire says the verification added in the fix is opt-in and off by default, and is enabled with the ice_verify_message_integrity channel variable (GHSA-rc25-33hp-6mv2).
• CVE-2026-116785 (Critical, 9.1): a pre-authentication heap out-of-bounds write in the mod_xml_rpc WebSocket endpoint. SignalWire says both the module and its WebSocket endpoint are opt-in, so a default installation does not reach the code (GHSA-jj89-q47c-gh94).

The full list is in the table below. Several flaws are in modules or listeners that are off by default (mod_rtmp, mod_xml_rpc, MSRP). Many of the rest can crash the FreeSWITCH process and end every call on the instance; for several of these, SignalWire says code execution has not been demonstrated.

Earlier public reporting. Enable Security, a VoIP security firm, wrote in its August 2026 newsletter that the api chat path was already being abused to take over servers in the wild, that a public GitHub issue had described the behaviour since 14 July, and urged FreeSWITCH and FusionPBX users to upgrade to 1.11.3 (Enable Security). We have not verified that report independently; SignalWire's advisory confirms exploitation without giving dates or scale.

Exploitation status. SignalWire says exploitation has been observed in the wild. It gives no count of affected servers, and neither do we. Not in CISA KEV (catalog version 2026.10.28, checked 29 October 2026). We found no national CERT advisory. We did not look for, and do not link to, any exploit code.

Timeline (Cyprus time):

• 9 August 2026, 21:05: FreeSWITCH 1.11.2 released, with broad security hardening [v1.11.2 release].
• 26 August 2026, 16:46: Pull request #3135 adding enable-chat-api-proto is merged [PR #3135].
• 29 August 2026, 01:27: FreeSWITCH 1.11.3 released, described as "an important release containing critical security fixes" [v1.11.3 release].
• 26 October 2026, 23:10–23:12: SignalWire publishes nine advisories fixed in 1.11.2 [SignalWire advisories].
• 28 October 2026, 18:46: SignalWire publishes GHSA-mg63-h38w-8p9p for CVE-2026-116779, Critical 9.8, noting exploitation in the wild [GHSA-mg63-h38w-8p9p].
• 28 October 2026, 18:49–19:01: SignalWire publishes 11 more advisories fixed in 1.11.2 [SignalWire advisories].
• 29 October 2026: Not in CISA KEV; no NVD or CVE Program record published yet.

SignalWire credits Örn Arnarson and Gunnlaugur with reporting CVE-2026-116779.

Affected Product Versions

SignalWire lists no fixed 1.10.x release; the fixed versions are 1.11.2 and 1.11.3. Products and hosted services built on FreeSWITCH, such as FusionPBX, are only as current as the FreeSWITCH version installed underneath them. We found no downstream vendor advisory at the time of writing, so we do not name any product as affected or unaffected. Ask the supplier which FreeSWITCH version it runs.

All scores below are SignalWire's CVSS 3.1 scores from its advisories:

Workaround and Mitigation

1. Upgrade to FreeSWITCH 1.11.3. This closes CVE-2026-116779 by default and includes the 1.11.2 fixes for the other advisories (v1.11.3 release). Do not set enable-chat-api-proto to true unless a trusted, deliberate use requires it.
2. Turn on ICE integrity checking after upgrading. For CVE-2026-116790, set the ice_verify_message_integrity channel variable; SignalWire says the check is off by default (GHSA-rc25-33hp-6mv2).
3. If you cannot upgrade yet, SignalWire's workarounds for CVE-2026-116779 are:
   • Set enable-chat=false on every SIP profile that does not need inbound SIP chat. This stops the message before the protocol selector is read, and disables inbound SIP chat on that profile.
   • Remove every directory user with no password or a1-hash. SignalWire says stock conf/vanilla ships two: default and the Skinny example.
   • Do not rely on auth-messages alone. MESSAGE authentication is on by default from version 1.10.7, but with passwordless users removed it only reduces the flaw to authenticated command execution.
   • Set disable_system_api_commands=true. It removes the system API but leaves other API commands reachable, including module loading and call origination, so it narrows the risk without closing it.
4. For CVE-2026-116786 before upgrading, SignalWire's workaround is disable-transfer=true on the affected profile, which also stops SIP-initiated call transfer (GHSA-xjxm-9qx6-w3fj).
5. Leave opt-in modules off where unused. SignalWire's workarounds for several of the other advisories are to leave mod_xml_rpc, its WebSocket endpoint, mod_rtmp and the MSRP listener unloaded, and to restrict their ports and the media port range to trusted networks where they are needed.
6. Review logs as far back as you keep them, not just since 28 October. After upgrading, FreeSWITCH logs each blocked attempt to use the api chat protocol. Before upgrading, look for unexpected inbound SIP MESSAGE traffic, unexplained API activity and unfamiliar processes started by the FreeSWITCH user (Rescana guidance). Because SignalWire reports exploitation in the wild, a server that ran 1.11.2 or earlier with SIP chat enabled should be checked for compromise, not only patched (Rescana guidance).

Indicators of Compromise

SignalWire has not published indicators of compromise for CVE-2026-116779, and we have none to add. No source we checked maps this flaw to MITRE ATT&CK techniques, and we have not done so.

What we will update

We will update this post if CISA adds CVE-2026-116779 or any of the related CVEs to KEV, if SignalWire revises its advisories or publishes more detail on exploitation, if NVD or the CVE Program publishes records or scores, if a national CERT issues guidance, or if a downstream vendor that embeds FreeSWITCH publishes its own advisory.

Sources

• SignalWire (FreeSWITCH maintainer): GHSA-mg63-h38w-8p9p, "Inbound SIP MESSAGE can select the api chat proto and run FreeSWITCH API commands" (28 October 2026): https://github.com/signalwire/freeswitch/security/advisories/GHSA-mg63-h38w-8p9p; security advisory list (26 and 28 October 2026 advisories): https://github.com/signalwire/freeswitch/security/advisories; GHSA-xjxm-9qx6-w3fj: https://github.com/signalwire/freeswitch/security/advisories/GHSA-xjxm-9qx6-w3fj; GHSA-rc25-33hp-6mv2: https://github.com/signalwire/freeswitch/security/advisories/GHSA-rc25-33hp-6mv2; GHSA-jj89-q47c-gh94: https://github.com/signalwire/freeswitch/security/advisories/GHSA-jj89-q47c-gh94; FreeSWITCH v1.11.3 release notes: https://github.com/signalwire/freeswitch/releases/tag/v1.11.3; v1.11.2 release notes: https://github.com/signalwire/freeswitch/releases/tag/v1.11.2; pull request #3135: https://github.com/signalwire/freeswitch/pull/3135
• CISA: not in the KEV catalog as of catalog version 2026.10.28, checked 29 October 2026: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD and CVE Program: no published record for CVE-2026-116779 or the related CVEs as of 29 October 2026.
• Enable Security (VoIP security firm): RTCSec newsletter, August 2026: https://www.enablesecurity.com/newsletter/2026-08-rtcsec-news/

Why this matters for your vendors

FreeSWITCH rarely shows up on a supplier list by name. It runs inside the hosted phone systems, contact-centre platforms, conferencing and SIP trunking services your teams use every day, and a supplier that missed the August update may have been exposed before anyone knew to look.

Forward this to your TPRM owner: Four short questions for voice, UCaaS, contact-centre, CPaaS, SIP trunking and WebRTC suppliers (Rescana guidance):

• Do you run or embed FreeSWITCH, directly or through a product such as FusionPBX?
• Are all those instances on FreeSWITCH 1.11.3 or later, with enable-chat-api-proto left off, SIP chat disabled where unused, no passwordless directory users, and ice_verify_message_integrity set where you serve WebRTC?
• Have you reviewed logs on servers that ran 1.11.2 or earlier for unexpected SIP MESSAGE traffic or API activity, and what did you find?
• If any instance is not yet fixed, when will it be?

Working through voice and contact-centre suppliers on questions like these? We can help you track their answers alongside the rest of their security posture. Book a demo.