Server-side request forgery in an AI workflow platform

A user-controlled model endpoint inherited the server's network reach

In briefA model-discovery feature in a widely adopted open-source AI workflow platform issued server-side requests to a user-controlled endpoint and followed redirects, so a request could reach internal network destinations the platform was not intended to expose.

Contents
  1. System context
  2. What we found
  3. Security consequence
  4. Why the boundary failed
  5. Disclosure status
  6. Limitations: what we are not publishing yet
Model discovery became a network-privileged request
User controls destinationExternal user: supplies model endpoint
Server supplies network reachAI platform server: model discovery
User-selected endpoint
Internal network boundary
Boundary crossedInternal service / protected resource
Caller receives returned content
A user-controlled model endpoint caused the platform to make a server-side request, follow a redirect, and return content from a destination reachable from the platform’s network position.

#System context

The affected software is a widely adopted open-source platform for building and deploying AI agents and workflows. Software in this category lets a team assemble models, tools, and data sources into an application and run it as a service. This finding affected an AI workflow platform with 154k GitHub stars and 10k forks (measured September 2026).

Platforms like this let a user point the system at an external model provider. A common convenience is to accept any endpoint that speaks the OpenAI-compatible API, so a user can bring their own model host.

#What we found

We identified a server-side request forgery condition in the functionality that discovers which models an OpenAI-compatible endpoint offers.

The endpoint address is user-controlled. When the platform performs model discovery, it issues the request from the server to that address. The request was not constrained to the intended class of destinations, and redirect handling expanded the reachable surface further: a response that redirected the request elsewhere was followed to the new location.

The response was also reflected back to the caller as the list of discovered models. That makes the condition more than blind: content retrieved from the destination could be read, not merely triggered.

#Security consequence

A server-side request runs with the network position of the platform, not the network position of the user who supplied the address.

In affected deployment configurations, that position can reach destinations an external user cannot reach directly: internal services on the same network, administrative interfaces, and cloud instance metadata. Because the retrieved content is reflected back, the consequence includes reading responses from those protected resources, not only causing a request to them. Following redirects means a destination that looks acceptable at first can hand the request onward to one that is not.

The practical impact depends on where the platform runs and what sits next to it on the network. The condition is what turns a user-supplied string into a network-privileged action.

#Why the boundary failed

The feature reads as harmless. Discovering the models an endpoint offers sounds like a read-only convenience.

The boundary failed because the server-side request destination was delegated to untrusted input, with no matching restriction on where that request could go. Once the user chooses the destination, the request inherits the server's network reach, and redirect handling extends that reach past the point where the destination was first checked.

The security lesson is specific to this pattern, not a general claim about model integrations. A feature that appears to perform harmless model discovery becomes a network-privileged action when the destination of the underlying request is controlled by untrusted input.

#Disclosure status

StatusResponsibly reported. Coordinated disclosure pending.

This is independent security research against public open-source software; the affected project is not a Themis customer.

We have not verified a fix and do not describe one here. We will update this entry when disclosure is complete.

#Limitations: what we are not publishing yet

We are not publishing the affected function, the parameter that carries the endpoint, reproduction steps, or the identity of the project, while disclosure remains pending.

We reproduced the server-side request to a user-controlled destination and confirmed that redirects were followed and that retrieved content was reflected to the caller. We did not enumerate every deployment configuration in which the condition is reachable; the network consequence depends on where a given instance runs and what it can reach.