Repository navigation
Description
Feature Request
A counterparty chooses the address that the connector sends its DSP messages to:
- Provider side. The
callbackAddressof aContractRequestMessage,ContractOfferMessageor
TransferRequestMessagebecomes thecounterPartyAddressof the new negotiation or transfer process. Every later
message is POSTed there by the state machine, with the connector's protocol token in theAuthorizationheader.
The address is only checked for presence, and not at all on theTransferRequestMessage. - Consumer side. The
counterPartyAddressof a catalog request, a negotiation or a transfer comes from the
management API. In a multi-tenant runtime, any tenant chooses it.
Any scheme, host or IP is accepted, and the shared HTTP client follows redirects. A counterparty that passes
authentication and policy evaluation can make the connector call internal addresses:
- the cloud metadata endpoint (
169.254.169.254); - the management, control and signaling ports of the connector itself;
- other services on the internal network.
On the provider side the SSRF is mostly blind. The counterparty still learns something from how the state machine
reacts: a timeout, a 4xx and a 5xx are handled differently. On the consumer side, the tenant reads back the catalog
response, and the response body of a failed call in the error detail.
Proposal
Add an opt-in guard to the HTTP client that the DSP dispatcher uses. When it is enabled, the guard rejects the
addresses a host resolves to if they are loopback, link-local, private, unique-local, any-local or multicast. The check
is done when the connection is made, so it also covers DNS rebinding. Redirects are disabled on that client. An
allow-list of CIDRs and hosts re-admits the internal ranges that partners are legitimately reached on. A call to a
blocked address fails as a fatal error, so it is not retried.
The guard is off by default, because many deployments and all the e2e tests reach their partners on private or
loopback addresses. The connector logs a warning at boot when the guard is off.
Which Areas Would Be Affected?
e.g., DPF, CI, build, transfer, etc.
Why Is the Feature Desired?
Are there any requirements?
Who will sponsor this feature?
Please @-mention the committer that will sponsor your feature.
Solution Proposal
If possible, provide a (brief!) solution proposal.
Activity
github-actions commentedon Nov 6, 2026
This issue is stale because it has been open for 14 days with no activity.
github-actions commentedon Nov 14, 2026
This issue was closed because it has been inactive for 7 days since being marked as stale.
github-actions commentedon Nov 14, 2026
This issue was closed because it has been inactive for 7 days since being marked as stale.