SignalWire FreeSwitch Code Injection Vulnerability

🚨SEVERITY: CRITICAL — CVSS 9.8Security Advisory

TL;DR 📌

  • SignalWire FreeSwitch contains a code injection vulnerability that permits configuration and credential disclosure, arbitrary call control, and command execution.
  • Highest CVSS: 9.8 (Critical).
  • Listed in CISA KEV (2026-11-09) — this is being exploited in the wild.
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2026-116779.

What it is

CVE-2026-116779 is a code injection flaw in FreeSWITCH’s SIP handling. The function sofia_presence_handle_sip_i_message() takes the “To” user field of an inbound SIP MESSAGE and splits it on a plus sign, treating the portion to the left as a chat protocol selector. If that selector is set to api, the request reaches switch_api_execute(), which runs FreeSWITCH API commands — including commands that execute operating system binaries — with the privileges of the FreeSWITCH daemon.

The access path is via SIP messaging rather than the call signalling or media plane itself. Any authenticated profile account is sufficient to trigger the flaw, and inbound chat is enabled by default on the stock internal and external SIP profiles. The advisory also notes that in affected configurations, stock directory users without password material can satisfy the authentication requirement, which in practice removes much of the barrier to reaching the vulnerable code path.

The impact covers configuration and credential disclosure, arbitrary call control, and command execution on the host. This is listed in CISA’s Known Exploited Vulnerabilities catalogue, added on 2026-11-09, so it is known to be exploited.

What to do

  • Upgrade to FreeSWITCH 1.11.3, which contains the fix.
  • Review internal and external SIP profile configurations for directory users that have no password set, and assign credentials or disable those accounts — this is the condition the advisory flags as removing the authentication barrier.
  • If upgrading cannot happen immediately, consider disabling inbound chat handling on the internal and external profiles, or restricting which accounts can send SIP MESSAGE requests, as a stopgap.
  • Check FreeSWITCH logs for SIP MESSAGE requests with a “To” user containing a plus sign followed by api, as a sign of attempted exploitation.
  • Given the KEV listing, treat this as a priority patch target and confirm the fixed version is deployed across all FreeSWITCH instances reachable from untrusted networks.

For leadership 🧭

Executive summary. FreeSWITCH deployments running the stock internal or external SIP profiles can be driven to execute operating system commands by a single crafted SIP MESSAGE, with no special privilege beyond basic SIP authentication and, in some configurations, no password at all. This is in CISA’s Known Exploited Vulnerabilities catalogue, so patching to 1.11.3 and locking down directory accounts should happen this week, not at the next maintenance window.

Why it matters:

  • The vulnerable function sits in SIP presence handling, not call signalling, so standard call-plane access controls do nothing to stop it.
  • Inbound chat via SIP MESSAGE is enabled by default on both the internal and external profiles, meaning most stock FreeSWITCH setups expose the path out of the box.
  • Stock directory users without password material can satisfy the authentication check, so the attacker may not need valid credentials at all in affected configurations.
  • Successful exploitation yields configuration and credential disclosure, arbitrary call control, and arbitrary command execution with the daemon’s privileges — a full compromise of the telephony host, not just a denial of service.

Now / Next / Later:

  • Now: Check FreeSWITCH logs for SIP MESSAGE requests with a To user field containing a plus sign followed by api, and audit internal/external profile directories for users with no password set.
  • Next: Upgrade all FreeSWITCH instances to 1.11.3; where that can’t happen immediately, disable inbound chat handling on the internal and external profiles or restrict which accounts can send SIP MESSAGE requests.
  • Later: Require passwords on all directory accounts as a standing policy and review SIP profile defaults (chat handling, anonymous/guest accounts) whenever new FreeSWITCH instances are provisioned.

Source