What happened
FreeSWITCH is open source software that powers IP phone systems, call centres and VoIP provider services. It is developed by SignalWire. On October 28, 2026, the developers published security advisory GHSA-mg63-h38w-8p9p on GitHub for a critical flaw tracked as CVE-2026-116779. The NVD entry followed on November 5, 2026.
The bug sits in mod_sofia, the module that handles SIP traffic. When the server accepts a SIP text message of type MESSAGE (used for chat between phones), the sender can steer it into FreeSWITCH’s internal command interface instead of having it delivered. The server then runs the command with the privileges of the FreeSWITCH service.
The vendor states in its advisory that exploitation has been observed in the wild. On November 9, 2026, the US agency CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, and ENISA’s European vulnerability database EUVD lists it as exploited since November 9, 2026. The fix is in version 1.11.3.
Why it is dangerous
This is a command injection flaw (CWE-77 and CWE-78) combined with an unprotected dangerous function (CWE-749). Picture a mailroom that is only supposed to deliver letters. Write the right word on the envelope, though, and the clerk does not deliver it but carries out whatever the letter says. The server simply does not tell “deliver this message” apart from “run this command”.
The attack works over the network and only needs one SIP message to be accepted. Where message authentication is enforced (the default since version 1.10.7), the attacker needs any single account on that SIP profile, such as an extension, a handset or a trunk peer. Installations that kept the passwordless “default” user from the sample configuration do not even need that.
According to the vendor, an attacker can run arbitrary operating system commands with the privileges of the FreeSWITCH process, obtain configuration and credentials, and take full control of calls. Where mod_lua is loaded, as the sample configuration does, Lua scripting offers a second route.
More generally, a taken-over server can be used as a foothold into the wider company network. Stolen SIP credentials can be abused for expensive calls billed to the company.
- CVSS 9.8 out of 10 (version 3.1): an international severity scale. The score appears in the vendor’s security advisory on GitHub, and its source is GitHub, not NVD. It means a critical flaw exploitable over the network with no user action.
- CISA KEV: the US agency CISA’s list of vulnerabilities with confirmed exploitation. US federal agencies must remediate it by November 12, 2026. CISA does not yet know whether ransomware groups use it.
- EPSS 1.3%: an estimate of the probability of exploitation within the next 30 days. That sounds low, but the flaw ranks above roughly 71% of scored vulnerabilities. What matters most is that exploitation is already confirmed.
Who is affected
FreeSWITCH 1.11.2 and all earlier versions are affected. Any SIP profile that accepts inbound MESSAGE requests is vulnerable. That is the default: chat stays on unless a profile explicitly sets enable-chat=false, and the sample conf/vanilla configuration leaves it on for both the internal and external profiles.
The vendor warns that tightening the inbound ACL does not help, because it does not cover MESSAGE requests.
FreeSWITCH typically runs on company IP phone systems, in call centres and at VoIP and hosted telephony providers, often with the SIP port reachable from the internet. CISA notes that it is a component other products may use. If your phone system comes from a supplier, ask them whether it is built on FreeSWITCH and which version it ships.
Version 1.11.3 and later are not affected, nor are phone systems that do not contain FreeSWITCH at all.
How to check if you are affected
All commands below only read information and change nothing. Run them on the FreeSWITCH server. The configuration path depends on the installation, commonly /etc/freeswitch or /usr/local/freeswitch/conf. The commands search both.
Version of the running FreeSWITCH and installed packages (Debian/Ubuntu, or RHEL and derivatives):
fs_cli -x "version"
dpkg -l | grep -i freeswitch
rpm -qa | grep -i freeswitchWhich SIP profiles are running and whether chat is disabled on them:
fs_cli -x "sofia status"
grep -rn "enable-chat" /etc/freeswitch/sip_profiles/ /usr/local/freeswitch/conf/sip_profiles/ 2>/dev/nullWhether the sample “default” user is still in the user directory:
grep -rln 'id="default"' /etc/freeswitch/directory/ /usr/local/freeswitch/conf/directory/ 2>/dev/nullIf you run version 1.11.2 or older and a profile lacks enable-chat=false, you are affected.
How to fix it
The fixed version is FreeSWITCH 1.11.3. The vendor’s release notes call it an important release with critical security fixes and strongly encourage all users to upgrade as soon as possible. This release drops Debian 11 Bullseye, so factor that into your planning.
Recommended order of steps:
- Right now: set
enable-chat=falseon every SIP profile that does not need inbound SIP chat. According to the vendor, this stops the message before it is processed, but it also disables all inbound chat messages on that profile. - Remove every directory user that has neither a password nor an a1-hash. The sample configuration ships two: “default” and the Skinny example account.
- Set
disable_system_api_commands=true. The vendor recommends it, although on its own it does not close the vulnerable path. - Back up your configuration and upgrade to 1.11.3. If your phone system comes from a supplier, ask them for the update.
- Do not enable the new
enable-chat-api-protoparameter. It is off by default and commented out in the sample profiles, and that is exactly what closes the vulnerable path. The same switch was also added to mod_verto. - Verify the version and use a firewall to restrict internet access to SIP ports to known carrier and branch office addresses.
The vendor warns that message authentication (auth-messages) alone is not enough. Combined with removing passwordless users, it narrows the risk to attacks from a logged-in account but does not close the path. The real fix is version 1.11.3.
What if you may already be compromised
Because the flaw is actively exploited, assume that vulnerable servers reachable from the internet may have been compromised. The vendor has not published specific indicators of compromise yet, so look for general signs:
- FreeSWITCH logs (often
/var/log/freeswitch/freeswitch.log): MESSAGE requests from unknown addresses and unexpected API commands. - Unknown processes started by the user FreeSWITCH runs as, new
cronjobs, unknown system accounts and SSH keys. - Configuration changes, unexpectedly loaded modules and unfamiliar files in FreeSWITCH directories.
- Call detail records (CDR): calls to expensive international or premium numbers, night-time calls, an unexpectedly high carrier bill.
After upgrading to 1.11.3, the server rejects every such attempt with a 403 response and logs it together with the source and the requested command. Your logs will show whether someone is probing you.
The attacker may have obtained configuration and passwords, so change SIP account passwords, carrier credentials and other secrets stored on the server. If you find signs of compromise, disconnect the server from the network, preserve the logs and bring in an incident response specialist.