Description

FreeScout is a self-hosted help desk and shared mailbox. Prior to 1.8.230, multiple outbound paths in Helper::downloadRemoteFile(), Helper::checkPort(), Helper::sanitizeRemoteUrl(), MailboxesController.php, and ModulesController.php do not consistently enforce a sink-level restricted-host policy. An authenticated administrator, or another authenticated user permitted to change mailbox connection settings or trigger module update or installation paths, can supply attacker-controlled URLs or hosts. The independent download and port-test sinks can reach encoded or otherwise uncovered loopback and internal addresses. The redirect-validation bypass additionally requires a configured whitelist that permits the original and final hosts while a restricted internal host appears only as an intermediate redirect hop. No unauthenticated SSRF path is established. The server can consequently contact loopback and internal services, provide a blind internal port oracle, and retrieve internal HTTP responses into application-controlled download sinks. This issue is fixed in version 1.8.230.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-11-06T17:20:02.567Z",
  "pubdate": "2026-11-06T17:20:02.567Z",
  "executiveSummary": "FreeScout versions prior to 1.8.230 are susceptible to Server-Side Request Forgery (SSRF) vulnerabilities due to insufficient enforcement of restricted-host policies across multiple application modules.\nThe vulnerability resides in multiple outbound request sinks, including Helper::downloadRemoteFile(), Helper::checkPort(), Helper::sanitizeRemoteUrl(), MailboxesController.php, and ModulesController.php.\nAn authenticated user with administrative privileges or permission to modify mailbox settings, or trigger module installations, can exploit these sinks to bypass URL validation and target internal network resources.\nSuccessful exploitation allows attackers to perform blind port scanning (an internal port oracle), access loopback services, and retrieve sensitive internal HTTP responses within the application context.\nThis vulnerability is not exploitable by unauthenticated users; it requires an active session with specific high-level privileges.\nThe primary risk involves the compromise of internal network segmentation, potentially exposing internal services that were never intended to be accessible from the public-facing application instance.\nThe issue is remediated in version 1.8.230 through consistent enforcement of security policies at the sink level.",
  "technicalDetails": "The vulnerability stems from the absence of a unified, consistent sink-level restricted-host policy across the FreeScout codebase. While individual modules may contain input validation, the logic failed to prevent the processing of attacker-supplied URLs that resolve to internal or loopback addresses (e.g., 127.0.0.1, 169.254.169.254, or private RFC 1918 subnets).\nThe core of the issue is distributed across several functions and controllers: Helper::downloadRemoteFile(), Helper::checkPort(), Helper::sanitizeRemoteUrl(), MailboxesController.php, and ModulesController.php. Each of these components independently initiates outbound network requests based on user-supplied input without verifying the final resolved destination address.\nAttack flow for this SSRF involves the following steps: First, an authenticated administrator or privileged user provides a target URL via the application interface (such as a mailbox connection setting or module installation path). Second, the application performs a lookup or connection attempt without adequate validation of the host's resolution. If a redirection bypass is utilized, the attacker may configure a whitelisted host that redirects the request to an unauthorized internal resource, effectively masking the malicious destination from rudimentary URL filters.\nBy manipulating the URL, an attacker can influence the server to interact with arbitrary services on the internal network. Because the application handles the response from these requests (such as in download sinks), the attacker can potentially exfiltrate sensitive data or interpret the application's feedback as a blind oracle to map the internal network topology and identify open ports on internal hosts.\nThe vulnerability's complexity arises from the 'redirect-validation bypass' path. If the application is configured with a whitelist, the logic checks the initial URL and the final destination; however, if the attacker introduces a malicious hop between the whitelisted original host and the destination, the validation logic fails to detect the forbidden internal host, as it is only present as an intermediate step. This results in the server successfully proxying requests to internal services that should remain isolated. The impact is significant because it grants an authenticated attacker the ability to pivot from the application layer into the internal network, bypassing firewalls and security groups that protect backend services."
}