Advisory · CVE-2026-123786
Agenta workflow SSRF leaks secret token to internal targets
Agenta before 0.122.5 lets a workspace member with workflow edit rights redirect workflow invocations to an arbitrary revision URL, following redirects while forwarding a minted secret-resolve Authorization token, reaching internal and cloud metadata endpoints and leaking the token.
- Vendor
- Agenta
- Product
- Agenta
- Identifier / CWE
- CVE-2026-123786
CWE-918 - Action timing
- Immediate
Explain it like I’m five
Agenta checks only that a workflow address looks like a web address, then follows any forwarding address while carrying a master key. A workspace member can point it at the clouds private metadata service and have the key delivered to an attacker-controlled server.
- 01Revision URL set
A workspace member with workflow edit rights sets an arbitrary revision URL on a workflow or evaluator.
- 02Validation is shallow
The URL is checked only for scheme and host, accepting internal, loopback, and cloud metadata addresses.
- 03Invocation follows redirects
When the workflow is invoked, the server posts to the URL with redirects followed.
- 04Secret token forwarded
A minted Secret Authorization token is forwarded in the request headers, including across redirects to an attacker server.
- 05Internal targets reached
The request reaches internal services or cloud metadata endpoints, and the token can be captured from the vault API or the redirect target.
What happened
Agenta before 0.122.5 contains a server-side request forgery vulnerability in workflow and evaluator invocation. A user-supplied revision URL is validated only by scheme and host, then posted to server-side with redirects followed while a minted Agenta Secret token is forwarded in the Authorization header. That yields SSRF to internal and cloud metadata targets and leakage of the Secret token through redirects. The webhook path was already hardened with real URL validation that resolves DNS and blocks private, loopback, and metadata addresses; the workflow path was not. The flaw is reachable on the open-source build through the evaluation start endpoint. The record rates it high at CVSS 8.5 under version 3.1 and 8.4 under version 4.0.
The issue is fixed in Agenta 0.122.5. The API now gives the run credential with the secret-resolve grant only to the operators own service URL; other workflow URLs receive a credential without that grant, go through an egress check that refuses private, loopback, link-local, and metadata addresses and pins the connection to the checked address, and no workflow service call follows redirects. Self-hosted operators who run custom workflows on a private network or on plain HTTP must now set the insecure-egress flag or list the host in the gateway host allowlist.
What to do
- Inventory Agenta deployments, including self-hosted instances, and record each version.
- Upgrade to Agenta 0.122.5 or later.
- Until upgraded, audit workflow and evaluator revision URLs and restrict workflow edit rights to trusted members.
- Review server and proxy logs for workflow invocations to internal, loopback, or cloud metadata addresses and for redirects to external hosts.
- Rotate provider secrets and Agenta credentials if token exposure or metadata access cannot be excluded.
- Verify the deployed version after updating.
Management note
SSRF alone is bad; SSRF that carries a credential with a secret-resolve grant is a cloud-credential path. Patch, then check whether any invocation left the network you intended it to stay inside.