Summary
Tandoor Recipes contains a server-side request forgery vulnerability in AI provider handling, where a configured provider URL can bypass outbound-request protections. An authenticated user who can configure an AI provider and invoke an AI action may cause the server to connect to internal services, other hosts, or cloud metadata endpoints and infer network reachability from the connection result.
Tandoor Recipes contains a server-side request forgery vulnerability in AI provider handling, where a configured provider URL can bypass outbound-request protections. An authenticated user who can configure an AI provider and invoke an AI action may cause the server to connect to internal services, other hosts, or cloud metadata endpoints and infer network reachability from the connection result.
Affected context
The issue affects Tandoor Recipes deployments that allow an administrator-controlled AI provider URL to be passed to LiteLLM through the affected AI actions. The vulnerable request paths are associated with AI import and AI step-sorting operations, where the supplied URL is used without the server's normal outbound-request validation. Risk depends on the server's network access, available credentials, and the permissions of the authenticated users who can configure Spaces or AI providers.
The issue affects Tandoor Recipes deployments that allow an administrator-controlled AI provider URL to be passed to LiteLLM through the affected AI actions. The vulnerable request paths are associated with AI import and AI step-sorting operations, where the supplied URL is used without the server's normal outbound-request validation. Risk depends on the server's network access, available credentials, and the permissions of the authenticated users who can configure Spaces or AI providers.
Exploit preconditions
- Attack surface: Tandoor Recipes AI provider configuration and AI action endpoints
- Required access: An authenticated account with permission to create or configure a Space and set an AI provider URL
- Trigger point: Invocation of an affected AI action, such as AI import or step sorting
- Network condition: The Tandoor server must be able to initiate outbound connections to the targeted address
- Why exploitation is possible: The configured provider URL is sent to the underlying AI client without applying the server's outbound SSRF checks, while connection success, refusal, or timeout can reveal network reachability
- Attack surface: Tandoor Recipes AI provider configuration and AI action endpoints
- Required access: An authenticated account with permission to create or configure a Space and set an AI provider URL
- Trigger point: Invocation of an affected AI action, such as AI import or step sorting
- Network condition: The Tandoor server must be able to initiate outbound connections to the targeted address
- Why exploitation is possible: The configured provider URL is sent to the underlying AI client without applying the server's outbound SSRF checks, while connection success, refusal, or timeout can reveal network reachability
Why this happens
The vulnerability results from a server-side HTTP client trusting an administrator-controlled provider URL without consistently enforcing outbound destination policies. The affected AI actions call the configured endpoint directly instead of routing the request through the application's safe-request controls. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced input determines a request made from the server's network position.
The vulnerability results from a server-side HTTP client trusting an administrator-controlled provider URL without consistently enforcing outbound destination policies. The affected AI actions call the configured endpoint directly instead of routing the request through the application's safe-request controls. This behavior maps to CWE-918: Server-Side Request Forgery, because attacker-influenced input determines a request made from the server's network position.
Potential impact
- Internal hosts and service ports may be mapped through connection behavior
- Internal administrative or application services could receive unintended requests
- Cloud instance metadata endpoints may be reachable from the server environment
- Network topology and service availability information could be disclosed
- Follow-on compromise may be possible if an accessible internal service accepts sensitive or privileged requests
- Internal hosts and service ports may be mapped through connection behavior
- Internal administrative or application services could receive unintended requests
- Cloud instance metadata endpoints may be reachable from the server environment
- Network topology and service availability information could be disclosed
- Follow-on compromise may be possible if an accessible internal service accepts sensitive or privileged requests
General mitigation guidance
Mitigation generally focuses on making outbound destinations explicit, validated, and independent of untrusted URL input.
Common defensive patterns include:
- Apply one centralized SSRF-safe request policy to every AI action and provider integration
- Permit only approved schemes, hosts, ports, and resolved address ranges
- Re-check DNS resolution and reject loopback, private, link-local, multicast, and metadata address spaces
- Prefer server-side provider identifiers or allowlisted connection profiles over arbitrary URLs
- Restrict outbound network access with egress firewalls, proxies, and workload-specific policies
- Avoid exposing detailed connection outcomes when they are not required by the user interface
- Run the application with minimal network privileges and cloud metadata protections
Mitigation generally focuses on making outbound destinations explicit, validated, and independent of untrusted URL input.
Common defensive patterns include:
- Apply one centralized SSRF-safe request policy to every AI action and provider integration
- Permit only approved schemes, hosts, ports, and resolved address ranges
- Re-check DNS resolution and reject loopback, private, link-local, multicast, and metadata address spaces
- Prefer server-side provider identifiers or allowlisted connection profiles over arbitrary URLs
- Restrict outbound network access with egress firewalls, proxies, and workload-specific policies
- Avoid exposing detailed connection outcomes when they are not required by the user interface
- Run the application with minimal network privileges and cloud metadata protections
How teams detect issues like this
Detection can combine code analysis, runtime monitoring, and policy enforcement:
- Use static analysis to identify user-controlled URLs passed to HTTP clients or AI provider libraries without a shared validation wrapper
- Review all AI actions and integration paths for inconsistent use of safe-request or egress-control functions
- Flag URL configuration fields that accept arbitrary hosts, schemes, ports, or redirects
- Monitor outbound connections from the application for requests to private, loopback, link-local, and cloud metadata ranges
- Alert on unusual provider changes followed by repeated connection attempts across internal address ranges
- Enforce CI and code-review policies requiring centralized SSRF validation for server-side network requests
Detection can combine code analysis, runtime monitoring, and policy enforcement:
- Use static analysis to identify user-controlled URLs passed to HTTP clients or AI provider libraries without a shared validation wrapper
- Review all AI actions and integration paths for inconsistent use of safe-request or egress-control functions
- Flag URL configuration fields that accept arbitrary hosts, schemes, ports, or redirects
- Monitor outbound connections from the application for requests to private, loopback, link-local, and cloud metadata ranges
- Alert on unusual provider changes followed by repeated connection attempts across internal address ranges
- Enforce CI and code-review policies requiring centralized SSRF validation for server-side network requests
