Summary

kestra.tasks.http.allowed-list entries match the configured host and all of its
subdomains. With https://api.trusted.com allowed, a flow can also reach
https://foo.api.trusted.com. This is undocumented, so an operator who configures an
exact host gets a broader egress policy than they asked for.

Impact

Affects only deployments that have explicitly configured
kestra.tasks.http.allowed-list. The list is empty by default, and an unconfigured
instance has no restriction to bypass and is not affected.

The control governs the HTTP task family (Request, Download, SseRequest), the HTTP
polling trigger, and the Pebble {{ http(uri=...) }} function. An actor able to author
or influence a flow can reach any subdomain of an allowed host. Exploitability depends
on the operator's DNS layout: it matters where a subdomain under the allowed host is
attacker-registrable (notably multi-tenant hosts such as blob.core.windows.net) or
serves something the policy was meant to exclude.

The allow-list is read from server configuration via the application context and cannot
be overridden from flow YAML or plugin defaults.

Affected and patched versions

Affected: 2.0.1 only. The allow-list feature did not exist before 2.0.0, and 2.0.0
matched differently; see GHSA-gxqx-8c54-274x, which this behaviour replaced.

Patched: 2.0.2. An entry now matches its exact host only; write *.api.trusted.com to
include subdomains.

Workaround

Until upgrading, list each host that should be reachable explicitly, and audit allowed
entries for subdomains you do not intend to permit; particularly any host on a
multi-tenant domain.

Credit

Reported by @dhruv0703.