An unauthenticated Server-Side Request Forgery vulnerability in JoeCastrom mcp-chat-studio allows remote attackers to force the application to make arbitrary outbound HTTP requests to internal resources.

The application fails to validate user-supplied input reaching the fetch and axios.post functions in server/routes/llm.js and server/services/LLMClient.js. An unauthenticated attacker can supply malicious URLs to the base_url or llmConfig parameters, enabling the server to act as a proxy for requests to internal services, loopback addresses, or sensitive cloud metadata endpoints.

Successful exploitation allows an attacker to bypass network perimeters and interact with internal-only services that are not exposed to the public internet. This can lead to the unauthorized disclosure of sensitive internal data, configuration retrieval, or potential interaction with administrative APIs that do not require additional authentication. Given the CVSS score of 7.3, this flaw poses a significant risk to the confidentiality and integrity of internal network segments.

Immediate Action: As there is no official patch currently available, immediately restrict network access to the mcp-chat-studio instance, ensuring it cannot reach internal metadata services (e.g., 169.254.169.254) or sensitive private IP ranges.

Proactive Monitoring: Monitor server egress logs for anomalous HTTP requests originating from the application server, particularly those targeting internal IP addresses or unusual ports.

Compensating Controls: Deploy a Web Application Firewall (WAF) to inspect incoming requests and block those containing suspicious URL patterns or unexpected base_url values in the /api/llm/models or /api/workflows/test/execute endpoints.

Public Exploit Available: Yes, a technical write-up containing proof-of-concept reproduction steps is available via the project's GitHub issue tracker.

The risk posed by this SSRF vulnerability is severe due to the potential for internal network reconnaissance and unauthorized access to protected services. Administrators should prioritize isolating the affected application from sensitive network segments and implement strict request validation or URL allowlisting if the service must remain operational. Until an official update is provided by the vendor, treat the application as untrusted and monitor for any signs of exploitation.