harnessrouter/harnessrouter: An upload destination's address was called by the server without checking it against private and metadata networks
What fixes it
- 0.31.13harnessrouter/harnessrouter, otherGitHub
A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.
Description
Summary
POST /v1/cloud-upload/targets and POST /v1/cloud-upload/targets/test take a base_url from the request body and call {base_url}/v1/me from the server to learn which workspace a key belongs to; an upload to a stored destination then calls {base_url}/v1/uhp. Neither call checked the address. Anyone holding an API key could make the server request any host and port, including private, loopback and link-local (cloud metadata) addresses, and read back the status the target answered with and the workspace fields it returned. MCP server, database and git addresses already passed the server's internal-address check; this path never called it.
Who is affected
Deployments from 0.9.0 up to and including 0.31.12 where one gateway serves several organizations through a shared runner pool. A self-hosted install of the image, whose runner runs beside its gateway, is not affected: there a key holder's tasks already run commands on the box's own network, and that network stays allowed for upload destinations, as it does for MCP servers and databases.
Patches
Fixed in 0.31.13. On a shared deployment a destination's address must be https, and a name that resolves to a private, local or metadata network, or that does not resolve, is refused before any call, with every address the name resolves to checked. A destination stored before the fix is checked again before each upload. Redirects were not followed and still are not.
In 0.31.13 the check resolved the name before the call and the connection resolved it again, so a name that changed its answer between the two was not covered. 0.32.1 closes that for every address the server checks this way: the connection goes only to an address classified in the same step.
Workarounds
Until you can upgrade, block the gateway's outbound traffic to private, loopback and link-local networks at the network layer.
Credits
Reported privately by @mikannse.
Text from GitHub Advisory Database
Affected versions 1
- harnessrouter/harnessrouter, other>= 0.9.0, < 0.31.13GitHub