SSRF Vulnerability in AI Model Provider Configuration Allowed Internal Network Scanning

A server-side request forgery (SSRF) vulnerability was identified and remediated in AI model endpoints, enabling a tenant administrator to probe internal network services through user-supplied provider URLs. The flaw resided in the configuration interfaces for OpenAI, Azure OpenAI, and Ollama integrations, where the `baseUrl` or `endpoint` parameters accepted arbitrary network addresses without validation.

The attack vector exploited the "Check connectivity" functionality associated with the `/api/ai/model/chat` and `/api/ai/model` endpoints. By specifying an internal address such as `http://172.17.0.1:22` as a provider base URL, a malicious tenant admin could trigger the server to forward requests to that address. The server would return the response, including service banners—demonstrated with `SSH-2.0-OpenSSH_9.6p1`—thereby revealing the existence and configuration of shielded internal services that should not have been network-accessible from tenant environments.

The remediation applied the existing `SsrfProtectionValidator.validateUri()` validation at two distinct execution points: within `Langchain4jChatModelConfigurerImpl` and in the webhook/OAuth2 validation layer already present in the codebase. This defense-in-depth approach ensures that even if one validation checkpoint were bypassed, a secondary check would block the request. Notably, other AI providers—Google AI, Mistral, Anthropic, AWS Bedrock, and GitHub Models—were unaffected because their endpoint URLs are hardcoded within their respective SDKs, eliminating any user-controlled URL injection surface.

The case illustrates the attack surface introduced by flexible AI provider configuration, particularly in multi-tenant deployments where user-supplied parameters interact with internal service infrastructure. The fix aligns with established security patterns already protecting OAuth2 and webhook integrations within the same platform.