[Bug] Node HTTP transport forwards `Authorization` to a different port on the same hostname

Summary

The Node HTTP transport used by isomorphic-git 1.42.1 forwards an Authorization header when a Git URL redirects from one port to another on the same hostname. A port change creates a different HTTP authority. The same client removes the header when the hostname changes.

The affected behavior is implemented by the transitive simple-get 4.0.1 dependency, but it is reachable through isomorphic-git's documented Node transport and Git operations. This report is intended for the isomorphic-git repository; please coordinate with simple-get if the fix belongs there.

Affected source

The analyzed package revisions are:

isomorphic-git 1.42.1  14764ae0df5120e8c81c5cfe28b8d7f42cd7617a
simple-get     4.0.1   2cf41cd0a950c8694b17526fed6b975867f356dc

The consumer path is visible in the exact isomorphic-git source:

• src/http/node/index.js imports simple-get for the Node transport.
• src/http/node/index.js, request path passes the Git URL, headers, and redirect-capable request to that client.
• package.json declares simple-get; the attached lockfile resolves the analyzed graph to version 4.0.1.

The transitive redirect code is explicit:

• simple-get/index.js stores opts.hostname as originalHost, parses only redirectHost.hostname, and removes authorization only when those hostnames differ. The effective port is not compared.

The first request is made with credentials from a URL such as http://user:secret@host:port-A/repo.git. A 302 to the same host at port-B therefore retains the credential header.

Reproduction

The attachment includes a small Docker build that installs the pinned npm package and an adapter that invokes the real Node transport. From the directory containing this report:

docker build -t isomorphic-git-redirect-test attachments
ISOMORPHIC_GIT_IMAGE=isomorphic-git-redirect-test \
  attachments/reproduce.sh attachments/replay

The Python probe starts two loopback HTTP servers. The first returns a 302 and the second returns a valid Git protocol-v1 advertisement while recording the request headers. The credential is synthetic; the output reports only whether it was present and matched, never the encoded value.

See attachments/evidence.md and attachments/run.log.

Expected behavior

Sensitive headers should be scoped to the complete request authority. A redirect that changes scheme, canonical hostname, or effective port should drop Authorization and Cookie unless the caller explicitly authorizes the new authority.

Observed behavior

The same-host/different-port case forwards the header, while the host-change control drops it:

OBSERVED same_host_port_change source_auth=present(synthetic-basic) destination_auth=present(synthetic-basic) destination_auth_matches_source=True returncode=0
CONTROL host_change source_auth=present(synthetic-basic) destination_auth=absent destination_auth_matches_source=False returncode=0

Both operations complete with a valid Git advertisement. The security oracle is the header observed by the destination server, not the successful Git result.

Security impact and prerequisites

When a caller follows a redirect from a credential-bearing Git URL, a service on the redirected port can receive credentials intended for the original service. This can matter when a hostname fronts multiple services, a proxy can influence redirects, or another process controls an alternate port.

The test demonstrates credential crossing between two authorities using a synthetic credential. It does not claim that every redirect is attacker controlled; the application must follow redirects and the redirected service must be able to observe the request.

Related history and novelty

The current isomorphic-git advisory list contains other path, symlink, and resource-exhaustion issues, but I did not find this redirect credential case: isomorphic-git security advisories.

Issue #671 is a different redirect problem involving a POST method change. It does not cover sensitive-header forwarding and does not produce a successful Git operation with a credential crossing a port boundary.

This is therefore a new consumer-visible report for the pinned composition, with transitive ownership called out explicitly. The fix may appropriately be made in simple-get, isomorphic-git, or both.

Suggested remediation

Compare the complete effective authority before forwarding sensitive headers: scheme, canonical hostname, and normalized effective port. Drop Authorization and Cookie whenever any component changes, unless an explicit caller policy supplies credentials for the destination. Add tests for same-host port changes, default-port normalization, scheme changes, host changes, and multiple redirect hops.

Attachments

attachments.zip