CVE-2026-116779: FreeSWITCH Command Injection

Detection Guidance

Start by identifying every FreeSWITCH instance and confirming the actual running version. Check package metadata, container image manifests, deployment automation, and the running binary rather than relying only on a SIP banner. Systems below 1.11.3 should be treated as exposed if they accepted SIP MESSAGE traffic from untrusted or insufficiently controlled sources.

Review SIP and FreeSWITCH logs for inbound MESSAGE requests, unusual To user values containing a plus sign, and selectors associated with api. The exact log format varies by profile, logger, distribution, and integration, so the absence of a matching line does not prove that exploitation did not occur. Correlate SIP activity with FreeSWITCH API logs, process creation telemetry, shell execution, outbound connections, and changes to configuration or directory files.

Log Review

A starting point for log review is:

grep -RniE 'SIP/2\.0|MESSAGE|chat|(^|[^[:alnum:]])api([^[:alnum:]]|\+)' \
  /var/log/freeswitch /var/log 2>/dev/null

This is a triage filter, not a definitive exploit signature. Investigators should preserve original logs and review surrounding timestamps, source addresses, usernames, destination profiles, and process events. For systems forwarding SIP logs to a SIEM, a conceptual query might be:

where application in ("freeswitch", "sofia")
  and method == "MESSAGE"
  and (
       request_uri contains "+"
       or to_user startswith "api+"
       or message contains "api"
      )

Monitor for FreeSWITCH child processes or shell interpreters launched by the service account. Example Linux process-audit logic using auditd data:

process.parent.executable == "/usr/bin/freeswitch"
or process.parent.name == "freeswitch"

Then prioritize children such as sh, bash, curl, wget, python, perl, nc, or unexpected administrative tools. Paths differ by distribution, so defenders should use the actual FreeSWITCH executable path from their host.

Also inspect:

• FreeSWITCH event and API logs for unexpected commands.
• Changes to XML configuration, directory users, dial plans, and scripts.
• New SSH keys, cron entries, systemd units, or startup scripts.
• Outbound connections from the FreeSWITCH host.
• Unexpected call records, call routing changes, or billing anomalies.
• Credential use from the service account after suspicious SIP activity.

Remediation and Patching

Upgrade FreeSWITCH to 1.11.3 or later. The supplied research identifies 1.11.3 as the fixed version. Organizations should use the package, container, or build process appropriate to their deployment and verify the resulting version after the change. A workaround is not a substitute for upgrading because the issue is an exposed command-execution path and exploitation has already been observed.

Until the upgrade is complete, restrict SIP MESSAGE access to trusted networks and known peers, remove unnecessary internet exposure, review internal and external profile settings, require strong credentials, and disable unused directory accounts. Pay particular attention to stock users without password material. Reduce the FreeSWITCH daemon’s operating-system privileges and limit its access to sensitive files and networks.

Build and Deployment Notes

For a source checkout or build workflow, first obtain the fixed upstream release and verify the resulting binary or package against your organization’s release process:

git fetch --tags
git checkout v1.11.3
# Run the project's documented dependency, configure, build, test, and install steps.
# Verify the deployed binary/package after installation.

Do not run an unreviewed build command in production. Distribution packages and vendor appliances may use different commands. The operational requirement is that the deployed FreeSWITCH build is 1.11.3 or later, not merely that a source directory has been updated.

As an interim network control, restrict SIP signaling and messaging at the firewall or SBC to known provider and administrative networks. A policy should deny unsolicited SIP traffic by default and explicitly allow only documented peers. The exact firewall syntax depends on the platform; the control should cover the signaling ports and transports actually used by the deployment, including UDP, TCP, and TLS where applicable.

If inbound chat is not required, disable or remove it according to the profile configuration supported by the deployed FreeSWITCH release. Because configuration directives vary by profile and version, validate the change in a staging system and confirm through an external test that unauthorized SIP MESSAGE requests are rejected. Strong authentication and network restrictions should remain in place even after disabling an unnecessary feature.

If compromise is suspected, preserve logs and volatile evidence before rebuilding. Isolate the host where practical, rotate exposed FreeSWITCH, SIP, database, API, and operating-system credentials, inspect connected systems, and follow applicable CISA forensic triage requirements. A clean upgrade alone may not remove attacker persistence or reverse unauthorized call-routing changes.

References

• NVD record for CVE-2026-116779
• FreeSWITCH fixing commit
• FreeSWITCH upstream pull request
• FreeSWITCH 1.11.3 release
• GitHub Security Advisory
• CISA Known Exploited Vulnerabilities Catalog

Organizations should retrieve the current NVD record directly to confirm the complete CVSS vector and any subsequent changes to affected-product metadata. At publication time, the critical facts for operational response are unchanged: FreeSWITCH versions before 1.11.3 are affected, exploitation has been observed, the vulnerability is CISA KEV-listed, and defenders should patch and investigate exposed systems immediately.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.