Skip to content

Guard the DSP outbound calls against internal addresses #6151

Open

Description

@wolf4ood

Feature Request

A counterparty chooses the address that the connector sends its DSP messages to:

  • Provider side. The callbackAddress of a ContractRequestMessage, ContractOfferMessage or
    TransferRequestMessage becomes the counterPartyAddress of the new negotiation or transfer process. Every later
    message is POSTed there by the state machine, with the connector's protocol token in the Authorization header.
    The address is only checked for presence, and not at all on the TransferRequestMessage.
  • Consumer side. The counterPartyAddress of 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

  1. added
    feature_requestNew feature request, awaiting triage
    triageall new issues awaiting classification
    on Oct 22, 2026
  2. github-actions commented on Nov 6, 2026

    @github-actions
    Contributor

    This issue is stale because it has been open for 14 days with no activity.

  3. github-actions commented on Nov 14, 2026

    @github-actions
    Contributor

    This issue was closed because it has been inactive for 7 days since being marked as stale.

  4. github-actions commented on Nov 14, 2026

    @github-actions
    Contributor

    This issue was closed because it has been inactive for 7 days since being marked as stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature_requestNew feature request, awaiting triagetriageall new issues awaiting classification

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions