Summary `sofia_presence_handle_sip_i_message()` splits the To user of an inbound SIP MESSAGE on `+` and treats the left half as a chat proto name, dispatching the message to whichever registered chat interface matches. `mod_dptools` registers an `api` chat interface that hands its address to `switch_api_execute()`. A peer that can deliver a MESSAGE to a profile therefore selects which FreeSWITCH API command the server runs. Nothing restricts the selector, and message-delivery protos are not distinguished from command-execution protos. Impact Command execution with the privileges of the FreeSWITCH process: arbitrary OS commands, disclosure of configuration and credentials, and full call control. Where `mod_lua` is loaded, as stock configuration does, inline Lua with the full standard library is reachable as a second sink. Exploitation of this path has been observed in the wild. Affected configurations Any SIP profile that accepts inbound MESSAGE, which is the default posture: chat handling is on unless a profile sets `enable-chat=false`, and stock `conf/vanilla` leaves it on for both the internal and external profiles. No non-default setting is required. The inbound ACL does not cover MESSAGE, so tightening it does not take a profile out of scope. Attack prerequisites Getting a single SIP MESSAGE accepted by a profile. Where MESSAGE authentication is enforced, any one account on that profile is enough: an extension, a handset, or a trunk peer, holding no permission beyond the ability to register. Installations that still carry `conf/vanilla/directory/default/default.xml` need no account of their own: that file defines `<user id="default">` with no `password` and no `a1-hash`, and a directory user with neither authenticates successfully unless `allow-empty-password` is set to false for it. Workarounds - `enable-chat=false` on every profile that does not need inbound SIP chat. This stops the message before the proto selector is parsed, and disables all inbound MESSAGE chat delivery on that profile. - `auth-messages` is not sufficient on its own. MESSAGE authentication is enabled by default from version 1.10.7 onward. Combined with removing every directory user that has no `password` or `a1-hash` - stock `conf/vanilla` ships two, `default` and the Skinny example - it reduces this to authenticated command execution, but does not close the path. - `disable_system_api_commands=true` removes the `system` API but not the route, which still reaches every other registered API, including module loading and call origination. Worth setting, but it does not close this path. Fix A new per-profile `enable-chat-api-proto` parameter controls whether an inbound MESSAGE may select the `api` chat proto, and is off unless explicitly set, so the route is closed on every profile by default. A MESSAGE selecting the proto where it is not enabled is answered 403 and logged with the source and the requested command. The comparison is case-insensitive, matching the chat interface registry. Messages carrying no proto selector, or naming another chat proto, route unchanged. The parameter ships commented out in the vanilla profiles and the mod_sofia configuration sample. Credit Örn Arnarson and Gunnlaugur.