FreeSWITCH Vulnerability CVE-2026-116779: One SIP Message Can Execute Server Commands, Upgrade to 1.11.3

CVE-2026-116779 is a vulnerability in FreeSWITCH that allows incoming SIP MESSAGE messages to select chat protocol api and execute server API commands, with a CVSS score of 9.8. All versions up to 1.11.2 are affected, a fix is ​​in 1.11.3, and CISA listed it in the Known Exploited Vulnerabilities (KEV) catalog on November 9, 2026 because it was used in a real attack.

FreeSWITCH is widely used as the engine behind PBX, call center, and VoIP services, often with an open SIP port to the internet. This article explains how the vulnerability works without exploit details, how to check the version with tested scripts, temporary mitigations, and upgrade steps.

Quick summary

How does this loophole work?

This loophole works because FreeSWITCH allows SIP message senders to determine the chat protocol used to deliver their messages. One of the available protocols turns out to be a door to server API commands.

What went wrong in message handling?

When receiving a SIP MESSAGE, FreeSWITCH breaks up the user portion of the destination address at the plus sign and considers the left portion to be the chat protocol name. The choice of protocol is not limited. Because the built-in module registers a chat protocol called api, senders can route their messages to the FreeSWITCH API command processor.

What is the impact?

The impact is the execution of the command with the FreeSWITCH process privileges. According to the developer advisory, this includes reading configuration and credentials, full control over calls, and additional paths through Lua scripts when module mod_lua is loaded.

Who is affected?

Affected are FreeSWITCH servers version 1.11.2 and below whose SIP profile accepts incoming chat messages, and that is the default setting.

• PBX and call center operators building services on top of FreeSWITCH.
• Users of FreeSWITCH based PBX distributions, whose versions follow the distribution provider's packages.
• Servers with SIP ports open to the internet, especially those that still use an example user directory.
• Forgotten installations: test servers, containers, and old images that are still running.

How serious is this loophole?

This flaw is very serious: the score is 9.8, the path is active in the default configuration, and the exploit is confirmed.

• The CVSS vector refers to attacks over the network, without access rights, and without user interaction.
• Inbound chat is active by default on both internal and external SIP profiles.
• Message authentication ( auth-messages) is not sufficient: any permitted account can still choose protocol api.
• The example directory contains users without passwords, which can pass authentication unless allow-empty-password is set to false.
• The developer said the exploit had been observed, and CISA gave US federal agencies a deadline of November 12, 2026.

Which version is safe?

The safe version is FreeSWITCH 1.11.3 or later.

How do I check if my server is affected?

Check the current version past fs_cli, then look at the chat settings in the SIP profile. We have tested the following script with versions 1.10.12, 1.11.2, 1.11.3, and 1.12.0.

#!/usr/bin/env bash
# Cek versi FreeSWITCH dan setelan chat di profil SIP
AMAN="1.11.3"
VER=$(fs_cli -x "version" 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [ -z "$VER" ]; then
  echo "FreeSWITCH tidak terdeteksi (fs_cli tidak merespons)"; exit 0
fi
if [ "$(printf '%s\n' "$AMAN" "$VER" | sort -V | head -1)" = "$AMAN" ]; then
  echo "Versi $VER: sudah memuat perbaikan"
else
  echo "Versi $VER: TERDAMPAK, upgrade ke $AMAN atau lebih baru"
fi
echo "--- setelan chat di profil SIP ---"
grep -rnE 'enable-chat|auth-messages' "${FS_CONF:-/etc/freeswitch}/sip_profiles/" 2>/dev/null \
  || echo "tidak ada setelan eksplisit (chat masuk mengikuti bawaan: aktif)"

If your configuration is not at /etc/freeswitch, run with FS_CONF=/lokasi/konfigurasi. Vendor packages that backport fixes may still display the old version number, so check that with the provider's release notes as well.

How to update safely?

The safe way is to install mitigations first if the upgrade is not possible today, then upgrade to 1.11.3 and verify the version is running.

Step 1: temporary mitigation

Turn off incoming chat on any SIP profiles that don't need it. First check whether there is a text message feature that the user is using, because this setting turns off all incoming chat sending on that profile.

<!-- di dalam <settings> tiap profil SIP -->
<param name="enable-chat" value="false"/>

After that, reload the profile and delete or give the directory user a password that doesn't have one. According to the advisory, turning off commands system through disable_system_api_commands or relying on auth-messages alone does not close the path.

Step 2: upgrade and verify

1. Back up the configuration directory.
2. Upgrade to 1.11.3 or later via the official repository or packages from your vendor.
3. Restart the service, then run the above check script again.
4. Leave enable-chat-api-proto at the default value (off), unless you really need it.
5. Check other copies of FreeSWITCH: test server, container, and appliance.

How to detect signs of attack?

Signs of attacks are looked for by matching incoming SIP MESSAGE messages with anomalous server activity. In version 1.11.3, attempts to select protocol api were rejected with a 403 reply and logged along with the source. Older versions don't necessarily log these attempts, so also check the following.

• A SIP MESSAGE message from an IP address that is not your user or trunk.
• New child processes of the FreeSWITCH service and unusual outbound connections.
• Modules loaded without the team's knowledge, routing changes, or odd calls and billing.
• Read access to the configuration file that stores the credentials.

If you find signs of a burglary?

1. Secure the logs first before changing anything.
2. Disconnect the server from the internet or restrict SIP ports to trusted addresses.
3. Replace all service-readable credentials: SIP passwords, trunk, database, and API keys.
4. Reinstall from clean sources if there is evidence of system commands being executed.

Frequently asked questions

Does an attacker need a SIP account?

Not always. If the profile receives messages without authentication or there are still users without a password, an account is not required; if authentication is required, any one valid account is sufficient.

Is turning off system commands enough?

Not enough. Setting disable_system_api_commands only deletes one command, while the path to other API commands remains open.

Do inbound ACLs protect my server?

Unreliable. According to public analysis, FreeSWITCH inbound ACLs do not cover MESSAGE traffic, so use network firewalls to limit the source.

I am using a FreeSWITCH based PBX distribution, what should I do?

Check the version of FreeSWITCH in it with the script above, install mitigation enable-chat=false, then follow the updates from your distribution provider.

Is the chat feature broken after upgrading to 1.11.3?

No. Regular SIP chat continues to run; The only thing that is turned off by default is selecting protocol api via incoming messages.

Also read about other loopholes from the same KEV wave: OpenSSH sshole loophole and GPUStack loophole CVE-2026-102895, as well as Node-RED without login.

Source

• GitHub Security Advisory GHSA-mg63-h38w-8p9p (signalwire/freeswitch)
• CISA: Adds Four Known Exploited Vulnerabilities to Catalog (9 November 2026)
• NVD: CVE-2026-116779
• The Hacker News: CISA warns of active exploitation of OpenSSH, GPUStack, FreeSWITCH, and IBM flaws