SignalWire says a SIP MESSAGE whose To user starts with api+ is routed to FreeSWITCH's api chat interface, which runs the rest as a FreeSWITCH API command. That gives OS command execution as the FreeSWITCH user, plus access to configuration, credentials and call control; where mod_lua is loaded (as in stock config), inline Lua is a second route. "Exploitation of this path has been observed in the wild." Rated critical.

• Exposed by default: chat handling is on unless a profile sets enable-chat=false, and stock conf/vanilla leaves it on for internal and external profiles. The inbound ACL does not cover MESSAGE. Where MESSAGE authentication is on, any single account (extension, handset, trunk peer) is enough; installs that still have the vanilla default directory user with no password need no account at all.
• Fixed: FreeSWITCH 1.11.3 adds a per-profile enable-chat-api-proto setting that is off by default and logs blocked attempts. The same release fixes other bugs published Oct 26-28, including SIP REFER channel-variable injection leading to command execution (CVE-2026-116786, high).

What to do: upgrade FreeSWITCH (and products that bundle it, such as FusionPBX builds) to 1.11.3. If you cannot yet, set enable-chat=false on every profile that does not need inbound SIP chat; auth-messages or disable_system_api_commands alone do not close the path. Remove password-less directory users, and check logs for inbound MESSAGE requests addressed to api+.