Summary
Before version 1.11.3, FreeSWITCH could interpret part of an inbound SIP MESSAGE address as a chat protocol selector and route messages to its API command handler. A peer whose message is accepted could run API commands with the daemon's privileges, potentially including operating-system commands; exploitation has been observed in the wild.
Before version 1.11.3, FreeSWITCH could interpret part of an inbound SIP MESSAGE address as a chat protocol selector and route messages to its API command handler. A peer whose message is accepted could run API commands with the daemon's privileges, potentially including operating-system commands; exploitation has been observed in the wild.
Affected context
The issue occurs in FreeSWITCH's SIP presence handling for inbound MESSAGE requests. Inbound chat is enabled on the stock internal and external profiles, so deployments that accept such messages may be exposed. An authenticated profile account is sufficient in the described scenario; in affected configurations, stock directory users without password material may also remove that access barrier.
The issue occurs in FreeSWITCH's SIP presence handling for inbound MESSAGE requests. Inbound chat is enabled on the stock internal and external profiles, so deployments that accept such messages may be exposed. An authenticated profile account is sufficient in the described scenario; in affected configurations, stock directory users without password material may also remove that access barrier.
Exploit preconditions
- Attack surface: Network-accessible SIP profiles that accept inbound MESSAGE requests
- Required access: An account accepted by the relevant profile; affected configurations may permit access through stock directory users without password material
- Trigger point: Processing an inbound SIP MESSAGE whose To user selects the API chat protocol
- Why exploitation is possible: The message-handling path routes the selected protocol to
switch_api_execute()without adequately restricting access to the exposed API functionality
- Attack surface: Network-accessible SIP profiles that accept inbound MESSAGE requests
- Required access: An account accepted by the relevant profile; affected configurations may permit access through stock directory users without password material
- Trigger point: Processing an inbound SIP MESSAGE whose To user selects the API chat protocol
- Why exploitation is possible: The message-handling path routes the selected protocol to
switch_api_execute()without adequately restricting access to the exposed API functionality
Why this happens
FreeSWITCH's SIP MESSAGE handler splits the To user at a plus sign and treats the left side as a chat protocol selector. Selecting the API protocol reaches switch_api_execute(), exposing a powerful function through a network-facing message path. This maps primarily to CWE-749: Exposed Dangerous Method or Function; resulting command execution may also relate to CWE-77 and CWE-78.
FreeSWITCH's SIP MESSAGE handler splits the To user at a plus sign and treats the left side as a chat protocol selector. Selecting the API protocol reaches switch_api_execute(), exposing a powerful function through a network-facing message path. This maps primarily to CWE-749: Exposed Dangerous Method or Function; resulting command execution may also relate to CWE-77 and CWE-78.
Potential impact
- An attacker may execute FreeSWITCH API commands with the daemon's privileges.
- Commands may reach operating-system command sinks and could enable host-level code execution.
- An attacker could disclose configuration or credentials.
- Call control may be abused, and the service or connected systems could be compromised.
- An attacker may execute FreeSWITCH API commands with the daemon's privileges.
- Commands may reach operating-system command sinks and could enable host-level code execution.
- An attacker could disclose configuration or credentials.
- Call control may be abused, and the service or connected systems could be compromised.
General mitigation guidance
Defensive measures generally focus on limiting access to powerful functionality and reducing trust in inbound messages.
- Keep inbound chat and API-backed message handling disabled unless required.
- Apply explicit authentication and authorization checks before exposing command-capable handlers.
- Restrict which API operations are callable through message-processing paths, using allowlists rather than broad command access.
- Run the service with least-privilege permissions and limit its access to sensitive files and operating-system capabilities.
- Review SIP profile and directory-user configuration to ensure that accounts without password material cannot gain unintended access.
Defensive measures generally focus on limiting access to powerful functionality and reducing trust in inbound messages.
- Keep inbound chat and API-backed message handling disabled unless required.
- Apply explicit authentication and authorization checks before exposing command-capable handlers.
- Restrict which API operations are callable through message-processing paths, using allowlists rather than broad command access.
- Run the service with least-privilege permissions and limit its access to sensitive files and operating-system capabilities.
- Review SIP profile and directory-user configuration to ensure that accounts without password material cannot gain unintended access.
How teams detect issues like this
- Review message-handling code for paths that map network-controlled protocol selectors to API or command execution functions.
- Use static analysis to identify exposed dangerous functions and flows from SIP input to command or operating-system execution sinks.
- Audit SIP profile and directory configuration for enabled inbound chat, weak authentication, and accounts without password material.
- Monitor SIP MESSAGE traffic and service logs for unexpected API activity, configuration access, or unusual call-control operations.
- Use code-review checks and security policies to flag newly exposed command-capable handlers.
- Review message-handling code for paths that map network-controlled protocol selectors to API or command execution functions.
- Use static analysis to identify exposed dangerous functions and flows from SIP input to command or operating-system execution sinks.
- Audit SIP profile and directory configuration for enabled inbound chat, weak authentication, and accounts without password material.
- Monitor SIP MESSAGE traffic and service logs for unexpected API activity, configuration access, or unusual call-control operations.
- Use code-review checks and security policies to flag newly exposed command-capable handlers.
