FreeSWITCH CVE-2026-116779: CISA KEV SIP MESSAGE api Proto RCE

CISA added FreeSWITCH CVE-2026-116779 to its Known Exploited Vulnerabilities catalog on November 9, 2026, with a remediation deadline of November 12. SignalWire's advisory GHSA-mg63-h38w-8p9p describes a CVSS 9.8 flaw: an inbound SIP MESSAGE can select the api chat protocol, which hands attacker-controlled text to switch_api_execute() and run FreeSWITCH API commands with daemon privileges, including operating-system command sinks. Versions through 1.11.2 are affected; 1.11.3 closes the route by default. If you operate FreeSWITCH on networks that also reach developer machines or agent sandboxes, upgrade or disable inbound chat on exposed profiles and assume daemon-level compromise if MESSAGE-facing systems were internet-reachable.

FreeSWITCH is a software telephony stack, not an LLM product. The AI angle here is indirect but real for practitioners: lab VLANs, MSP gear, and startup phone systems often sit beside build agents, internal Git, and inference endpoints. A daemon RCE on that segment is a pivot into the same hosts that store agent tokens. This post follows the vendor advisory and CISA KEV entry; we did not run a proof of concept.

TL;DR

What the vendor documents

SignalWire's advisory summarizes the bug in sofia_presence_handle_sip_i_message(): the To user of an inbound SIP MESSAGE is split on +, the left half becomes a chat proto name, and the message routes to whichever registered chat interface matches. mod_dptools registers an api chat interface that forwards to switch_api_execute(). Nothing in releases before 1.11.3 restricts that selector, so message-delivery protos are not separated from command-execution protos.

Impact listed:

• Command execution as the FreeSWITCH process
• Configuration and credential disclosure
• Full call control
• Inline Lua with full standard library when mod_lua is loaded, as in stock configs

The advisory states exploitation has been observed in the wild but does not name victims.

Affected configurations: any SIP profile accepting inbound MESSAGE, which is default unless enable-chat=false. Stock conf/vanilla leaves chat on for internal and external profiles. Tightening the inbound ACL does not block MESSAGE the way operators expect.

Attack prerequisites: deliver one accepted SIP MESSAGE. Where MESSAGE authentication applies, any account on the profile suffices. Installations retaining stock conf/vanilla/directory/default/default.xml may face a default user with no password and no a1-hash, unless allow-empty-password is false.

Fix in 1.11.3: new per-profile parameter enable-chat-api-proto, off unless explicitly enabled. A MESSAGE selecting api where it is disabled gets 403 and a log line with source and requested command.

CISA's KEV text mirrors the impact: configuration and credential disclosure, arbitrary call control, and command execution, with forensic triage required.

Attack chain, step by step

1. Send SIP MESSAGE to a profile with inbound chat enabled (default on vanilla internal/external profiles).
2. Craft the To user so the left side of the first + is api and the right side encodes a command (vendor examples use patterns like api+system%20id).
3. sofia_presence_handle_sip_i_message() parses the selector and dispatches to the api chat interface.
4. api_chat_send() in mod_dptools URL-decodes the payload and calls switch_api_execute().
5. Command runs as the daemon — system and other APIs, module loads, call origination, or Lua when mod_lua is present.

The chain is short because chat and control planes share one parser. That design choice is why CVSS lands at 9.8 with no user interaction in the stock unauthenticated configuration.

Timeline

Operators who upgraded in August were protected before public details; deployments still on 1.11.2 or older remain exposed.

What to do now

Preferred:

• Upgrade to FreeSWITCH 1.11.3 or later from SignalWire packages or rebuild from the v1.11.3 tag, then restart.
• Rebuild every node running mod_sofia and mod_dptools if you maintain custom packages.

If you cannot upgrade yet:

<!-- In each profile under /etc/freeswitch/sip_profiles/ -->
<param name="enable-chat" value="false"/>

Reload the profile or restart FreeSWITCH. This disables all inbound MESSAGE chat on that profile, not only the api route.

Additional hardening from the advisory:

• Remove directory users without password or a1-hash; set allow-empty-password false.
• Set disable_system_api_commands=true to remove the system API — helpful but not a full fix because other APIs remain.

Forensics after exposure:

• Inspect FreeSWITCH logs for MESSAGE handling and 403s after partial mitigations.
• Review /etc/freeswitch and autoload configs for unexpected module loads.
• Check for new OS users, cron entries, and outbound calls originated from the daemon.
• If the host shared credentials with development systems, follow rotation patterns in first 24 hours after a vendor breach.

What this means if you run AI coding agents

Coding agents do not speak SIP MESSAGE. The overlap is network placement:

• Shared lab VLANs where a developer's agent sandbox, FreeSWITCH lab VM, and internal Git sit on one flat segment.
• Hybrid startups running customer phone trees on the same VPS provider as staging APIs agents call.
• MSP or contact-center dev where engineers test IVR changes beside CI runners that hold deploy keys.

After daemon RCE, attackers routinely hunt for SSH keys, cloud metadata, and internal HTTP services. That is the same credential surface ARTEX-style agent attacks target, only starting from telephony instead of OAuth misconfig. Patch or isolate voice gear the way you would any other internet-facing service on a developer network.

There is no Beam feature that monitors FreeSWITCH. Beam's scope stays local agent observability on workstations.

Stock vanilla settings worth checking

SignalWire's advisory is explicit that non-default hardening is not required for exploitation. On a fresh install that still ships conf/vanilla:

• Internal and external SIP profiles leave inbound MESSAGE chat enabled.
• mod_dptools registers the dangerous api chat interface by default.
• mod_lua remains loaded in typical bundles, opening the secondary Lua sink the advisory names.
• Directory XML may still define a default user without password or a1-hash, which removes MESSAGE authentication as a gate when that file is untouched.

Operators often copy vanilla into production for lab phones, then promote the same tree to a small customer pilot. The CVE punishes that copy-paste habit: chat is a feature, but chat proto selection is not capability-separated from API execution until 1.11.3.

Workaround trade-offs the advisory lists

None of the partial controls replace 1.11.3, but they shrink windows while change boards approve maintenance.

Detection ideas without a proof of concept

We did not send test MESSAGE traffic. Log review still helps:

• SIP MESSAGE requests where the To user contains +api or begins with api+
• Sudden 403 responses after enabling enable-chat-api-proto hardening on a canary node (post-1.11.3)
• FreeSWITCH API audit lines showing system, load, or originate invoked from chat handlers
• New channels or calls originated without matching business-hour patterns
• OS-level indicators: unexpected cron, systemd units, or outbound SCP/curl from the freeswitch user

CISA's KEV addition implies federal incident response teams should run BOD 26-04 forensic triage on internet-exposed voice gear discovered during asset inventories. Private teams can use the same checklist: assume MESSAGE was reachable if UDP/TCP 5060 or your SBC equivalent was on the public internet.

Federal and enterprise deadlines

CISA lists due date November 12, 2026 for CVE-2026-116779 alongside the other additions on November 9. Voice infrastructure often sits outside the application patch cadence that CI and container teams follow weekly. If your asset inventory maps "developer workstations" but not "demo PBX on VLAN 40," this KEV entry is a reminder to patch telephony with the same urgency as Git and Kubernetes, especially when VLANs are flat.

Patch verification commands

After upgrading, confirm the running binary and loaded modules match expectations:

freeswitch -version
fs_cli -x 'version'
fs_cli -x 'module_exists mod_dptools'

On 1.11.3+, inspect each SIP profile XML for the new knob (commented in vanilla samples):

<!-- <param name="enable-chat-api-proto" value="true"/> -->

Leave it absent or explicitly false on profiles that face untrusted SIP peers. Reload with fs_cli -x 'reload mod_sofia' only after validating syntax; a broken profile can drop registrations and stall on-call engineers.

Package-based installs should show ≥ 1.11.3 in your distribution changelog. Custom builds must include both mod_sofia and mod_dptools commits from the advisory's fix release, not only one module, because MESSAGE handling spans both.

Credit and coordinated disclosure

SignalWire credits Örn Arnarson and Gunnlaugur in GHSA-mg63-h38w-8p9p. The fix landed in August 2026 while the advisory remained embargoed until October 28, which explains deployments that patched early yet only learned the attack relevance when exploitation notes became public. CVE publication followed on November 5, and CISA KEV arrived November 9 once catalog maintainers tied the flaw to active use expectations.

That staggered timeline matters for risk meetings: "We updated in August" is only a complete answer if the running config still disabled the api proto route everywhere. Re-validate profiles imported before the upgrade, because XML copied from pre-1.11.3 backups can reintroduce permissive chat settings even on patched binaries.

Related reading

• Barracuda CVE-2026-116606 and CVE-2026-111560: chained ESG root access

• NIST, NSA and CISA agent control guidance

• November 2026 attacks timeline

• GitLab KEV exploited RCE pattern

• OpenSSH sshole on Alpine containers

• GPUStack KEV auth bypass on inference hosts

Frequently asked questions

What is FreeSWITCH CVE-2026-116779?

It is a critical code injection path in FreeSWITCH through 1.11.2. Inbound SIP MESSAGE handling splits the To user on plus and treats the left side as a chat protocol name. Selecting api reaches mod_dptools, which can invoke FreeSWITCH API commands including operating-system sinks.

Which versions are fixed?

SignalWire advisory GHSA-mg63-h38w-8p9p lists affected versions as 1.11.2 and earlier and patched versions as 1.11.3 and later, which add enable-chat-api-proto defaulting off.

Is exploitation confirmed?

The SignalWire advisory states exploitation of this path has been observed in the wild. CISA added CVE-2026-116779 to KEV on November 9, 2026, with due date November 12 and forensic triage under BOD 26-04.

What is the fastest mitigation without upgrading?

Set enable-chat=false on every SIP profile that does not need inbound MESSAGE chat, which stops handling before the protocol selector parses. auth-messages alone does not close the path; disable_system_api_commands narrows but does not remove it.

Do stock configs expose this?

Yes, on default posture. Chat handling is on unless a profile sets enable-chat=false, and vanilla internal and external profiles leave it on. Stock directory user default can authenticate without password material unless hardening removed it.

What does this have to do with coding agents?

No direct agent API. Developer laptops and CI often share VLANs with VoIP lab gear, and a compromised telephony host can pivot to SSH keys and internal APIs agents use. Patch voice gear on the same networks you use for agent sandboxes.

Vendor advisory wording and CISA dates reflect public sources as of November 9, 2026.