CVE-2026-116779

How it works. When FreeSWITCH receives an inbound SIP MESSAGE (the SIP method used for text chat), sofia_presence_handle_sip_i_message() in mod_sofia splits the To user on the + character and treats the left half as the name of a chat protocol. mod_dptools registers a chat interface named api that passes its address to switch_api_execute(). According to the advisory, nothing restricts which protocol a sender selects, so a peer that can deliver a MESSAGE to a profile chooses which FreeSWITCH API command the server runs. The advisory lists the impact as arbitrary OS commands, disclosure of configuration and credentials, and full call control. Where mod_lua is loaded, as the stock configuration does, inline Lua with the full standard library is a second path.

Affected configurations, per the advisory.

• Any SIP profile that accepts inbound MESSAGE. That 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.
• The inbound ACL does not cover MESSAGE, so tightening the ACL does not take a profile out of scope.
• Where MESSAGE authentication is enforced, any one account on that profile is enough (an extension, a handset, or a trunk peer).
• Installations that still carry conf/vanilla/directory/default/default.xml need no account of their own. That file defines a user with id "default" and no password or a1-hash, and such a user authenticates successfully unless allow-empty-password is set to false for it.

Checks, in order. Run these only against FreeSWITCH servers your organization owns. The port numbers and fs_cli commands come from FreeSWITCH's stock configuration, not the advisory.

1. Version. Run fs_cli -x 'version'. Anything at 1.11.2 or earlier is affected.
2. Which profiles accept MESSAGE. List profiles with fs_cli -x 'sofia status', then check each profile's XML (for example conf/sip_profiles/internal.xml and external.xml) for enable-chat. If the parameter is absent or not set to false, the profile accepts inbound chat.
3. Loaded modules. Run fs_cli -x 'module_exists mod_dptools' and fs_cli -x 'module_exists mod_lua'. mod_dptools provides the api chat interface; mod_lua provides the second path.
4. Passwordless directory users. Check whether conf/directory/default/default.xml (from conf/vanilla) is still present, and search the directory for any user with neither a password nor an a1-hash. The advisory notes stock conf/vanilla ships two, the "default" user and the Skinny phone example.
5. Network exposure. Check whether SIP ports are reachable from the internet. In the vanilla configuration the internal profile listens on 5060 and the external profile on 5080 (UDP and TCP, plus TLS ports if enabled). Scan from outside your perimeter rather than relying on firewall rule review.
6. Trusted peers. Even if SIP is not internet-facing, list every handset, extension and trunk peer that can register or send MESSAGE to the profile, since any one account is enough where authentication is enforced.

Test each of these on the server where it matters. A setting that exists is not the same as a setting that works.

• The only pre-patch fix is enable-chat=false on each profile that does not need inbound SIP chat. The advisory says this stops the message before the protocol selector is parsed. It also disables all inbound MESSAGE chat delivery on that profile. Test it. After reloading the profile, send a MESSAGE to a harmless target such as api+version from a test host and confirm it is not executed.
• auth-messages alone does not close it. The advisory states MESSAGE authentication is on by default from 1.10.7 onward, and that combined with removing every directory user with no password or a1-hash it reduces the issue to authenticated command execution, but does not close the path.
• disable_system_api_commands=true does not close it. Per the advisory, it removes the system API but not the route, which still reaches every other registered API, including module loading and call origination. It is worth setting, but it is not a fix.
• Remove passwordless directory users (the "default" user and the Skinny example from conf/vanilla), or set allow-empty-password to false, to shrink who can send an accepted MESSAGE.
• SIP firewalling and segmentation. Restrict 5060 and 5080 to known carriers and internal phone networks. Because the inbound ACL does not cover MESSAGE, enforce this at the network firewall or a session border controller, and verify with an external scan.

What the fix changes. 1.11.3 adds a per-profile enable-chat-api-proto parameter that controls whether an inbound MESSAGE may select the api chat protocol. It is off unless explicitly set, so the route is closed by default. Messages with no protocol selector, or naming another chat protocol, route unchanged. Messages selecting the api protocol where it is disabled receive a 403 response and are logged.

• Inbound SIP MESSAGE requests whose To user begins with api+ (match case-insensitively).
• After upgrading, 403 responses and log lines for api-protocol messages, which record the source and the requested command.
• Unexpected API commands in FreeSWITCH logs, and child processes spawned by the FreeSWITCH process.

Is CVE-2026-116779 being exploited?

The FreeSWITCH maintainers' advisory says "Exploitation of this path has been observed in the wild." As of the October 28, 2026 catalog release, CISA has not added it to the Known Exploited Vulnerabilities catalog.

Does turning on auth-messages protect my FreeSWITCH server?

Not by itself. The advisory says MESSAGE authentication reduces the issue to authenticated command execution but does not close the path. Any one account on the profile is enough, and stock passwordless directory users authenticate unless allow-empty-password is false.

How do I fix CVE-2026-116779 without upgrading right away?

Set enable-chat=false on every SIP profile that does not need inbound chat, then test it. That is the only pre-patch workaround the advisory says stops the message. Setting disable_system_api_commands=true does not close it.

Which FreeSWITCH version fixes CVE-2026-116779?

Version 1.11.3. It also covers the companion CVEs CVE-2026-116785 and CVE-2026-116790, which were fixed in 1.11.2.

Oct 29, 2026. First published. Maintainers report in-the-wild exploitation; not on CISA KEV; NVD score pending.

• FreeSWITCH security advisory GHSA-mg63-h38w-8p9p (CVE-2026-116779)
• FreeSWITCH security advisory GHSA-jj89-q47c-gh94 (CVE-2026-116785)
• FreeSWITCH security advisory GHSA-rc25-33hp-6mv2 (CVE-2026-116790)
• CISA Known Exploited Vulnerabilities catalog (checked catalog version 2026.10.28)
• NIST NVD: CVE-2026-116779 (no record published yet)