FreeSWITCH CVE-2026-116779: Patch 1.11.3 Now

FreeSWITCH CVE-2026-116779 affects versions through 1.11.2 and is being exploited. An accepted inbound SIP text message can reach FreeSWITCH API functions and run commands with the service process's privileges. Upgrade to FreeSWITCH 1.11.3, disable inbound chat where it is not required, limit SIP exposure, and preserve evidence before deciding that patching alone has closed the incident.

What FreeSWITCH CVE-2026-116779 allows

SignalWire's security advisory rates the flaw critical and says exploitation has been observed in the wild. The vulnerable code handles inbound SIP MESSAGE traffic, which is the text-messaging part of the Session Initiation Protocol. A message accepted by an affected profile can select a command-capable chat interface and reach FreeSWITCH API execution.

The result is not limited to sending unwanted chat. SignalWire lists operating-system command execution, configuration and credential disclosure, and full call control among the impacts. The advisory assigns a CVSS 3.1 score of 9.8. The CVE record identifies command injection, OS command injection, and exposure of a dangerous function as the relevant weakness classes.

This article does not include the message structure needed to trigger the flaw. Defenders do not need that detail to inventory, patch, contain, or review affected systems.

Which FreeSWITCH systems are affected

SignalWire identifies FreeSWITCH 1.11.2 and earlier as affected and 1.11.3 and later as patched. The vendor says inbound chat handling is enabled unless a SIP profile explicitly sets enable-chat=false. The stock internal and external profiles leave it enabled, so a default installation can be exposed without an administrator turning on an unusual feature.

Authentication does not make an affected profile safe. The advisory says any authenticated account on that profile can be sufficient, including an extension, handset, or trunk peer. It also warns that stock directory users without password material can remove that barrier in some configurations. Setting auth-messages or disabling only system API commands reduces some paths but does not close the vulnerable route.

If a hosted or on-premises phone platform is managed by a vendor or MSP, ask in writing whether it embeds FreeSWITCH, which version is running, and when the fixed build was installed. Do not infer that a named downstream phone product is affected without a vendor advisory. Confirm the actual software and version in your environment.

Why the November 12 KEV date matters

CISA added CVE-2026-116779 to the Known Exploited Vulnerabilities catalog on November 9, 2026, with a November 12, 2026 due date. The entry marks forensic triage as required for covered federal systems and lists ransomware campaign use as unknown.

That date is a Binding Operational Directive deadline for Federal Civilian Executive Branch agencies. It does not create a federal patch deadline for cities, private businesses, or other organizations. For everyone else, it is still a useful risk-based target because the flaw has verified exploitation, network reachability, and total technical impact.

Organizations that need a repeatable response can use the site's guide to triage a CISA KEV addition in 72 hours. Treat internet-reachable phone infrastructure as the first priority, then work inward to systems reachable only by trusted voice networks or private peers.

What should administrators do today?

Start with an asset and version inventory. Include standalone FreeSWITCH servers, virtual machines, containers, appliances, and vendor-managed platforms. Record the owner, listener addresses, exposed SIP profiles, installed version, and whether inbound SIP chat is operationally required.

Then take these actions in order:

Preserve relevant evidence before changing the system when operations permit. Capture timestamps, running processes, network connections, service logs, SIP MESSAGE records, configuration files, call detail records, and the installed package state. Follow a documented process for preserving forensic evidence before patching a network appliance.
Upgrade affected systems to FreeSWITCH 1.11.3 or later. Read back the running version after the service restarts rather than relying only on a completed package transaction.
Set enable-chat=false on every profile that does not need inbound SIP chat. Test call and messaging workflows before and after the change because this setting disables inbound MESSAGE delivery for that profile.
Restrict who can reach SIP listeners at the network boundary. Limit public exposure to required providers, session border controllers, VPN paths, or other reviewed sources. Network restriction is defense in depth, not a replacement for the fixed release.
Remove unused directory users and accounts without password material. Review trunks, extensions, handsets, and service accounts for credentials that should be changed.
Document the patch, configuration change, exposure decision, and triage result. If a vendor owns the platform, retain its written version and patch confirmation.

The 1.11.3 fix closes the command-capable chat route by default. SignalWire says attempts to select that route when it is not enabled receive a 403 response and are logged with the source and requested command. Those records can support post-update monitoring without publishing a trigger format.

How do you check whether the server was already hit?

Patching stops the known path, but it does not prove the server was clean beforehand. Review the evidence collected before the upgrade and compare it with a known-good baseline. Look for unusual inbound SIP MESSAGE activity, unexpected child processes, command execution under the FreeSWITCH service account, changed configuration, newly loaded modules, altered directory users, and outbound connections that do not match normal operations.

Review call detail records for unexplained call origination, routing changes, toll activity, or control actions. Check adjacent systems for credentials that may have been stored in readable FreeSWITCH configuration. If the evidence indicates command execution or credential access, isolate the system as operations allow, escalate to incident response, and rotate every secret exposed by the server.

CISA's forensic triage guidance recommends scoping, preserving volatile and persistent evidence, patching after collection where possible, containment, analysis, and an explicit escalation decision. A lack of obvious log entries is not proof that exploitation did not occur. Record what data was available, what was missing, and the confidence of the conclusion.

What evidence should the organization retain?

Keep an asset inventory entry showing the phone server and running version, the change ticket or vendor confirmation for the 1.11.3 upgrade, configuration evidence for disabled chat where applicable, firewall or session border controller rules limiting SIP exposure, and notes from the compromise review. This supports internal governance and a defensible response to an insurer's patching question.

The site's guide to answering cyber insurance patching questions explains how to distinguish policy, operating practice, and evidence. If the review finds weak or empty credentials, also address the broader control failure described in how default secrets and phantom credentials break authentication.