GHSA-x565-32qp-m3vf

What it actually does

The vulnerability causes the `phin` HTTP client library to improperly handle redirects. When a request containing sensitive headers (e.g., `Authorization`, `Cookie`) is made to a server that responds with a redirect, the library forwards these same headers to the new destination specified in the redirect. This leaks potentially sensitive information to an arbitrary server.

Why it matters to the business

Applications using the vulnerable library risk leaking sensitive credentials, such as API keys, authentication tokens, or session cookies, to unintended third parties. This can lead to unauthorized access to internal systems, data breaches, account takeovers, and circumvention of security controls. The subsequent loss of customer trust and potential regulatory penalties can cause significant financial and reputational damage.

How an attack unfolds

An attacker would trick a server-side application using a vulnerable version of `phin` into making an HTTP request to a URL they control. This could be done through features that process user-supplied URLs, like webhooks or file importers. The attacker's server would respond with an HTTP redirect (e.g., 301 or 302) to another attacker-controlled endpoint. The vulnerable `phin` client follows this redirect but fails to strip sensitive headers from the original request, such as an `Authorization` token. The token is then sent to the attacker's second server, where it is logged and captured. The attacker can then use this stolen credential to impersonate the application and access its data and services.

How to fix it

The vulnerability is patched in version 3.7.1 of the `phin` npm package. Upgrade the `phin` dependency to version 3.7.1 or later. Use your package manager to update, for example, by running `npm install phin@^3.7.1` or `yarn upgrade phin --latest` and ensure the lock file is updated and committed.

How to confirm the fix worked

To confirm the fix, inspect your project's dependency tree to ensure the resolved version of `phin` is 3.7.1 or higher. You can use commands like `npm ls phin` or `yarn why phin` to verify the installed version. To test for exposure, create a test case where an application using `phin` makes a request with a dummy `Authorization` header to a controlled endpoint that issues a redirect. After patching, verify that the `Authorization` header is not present in the request sent to the final redirected destination.

Typical attack path

1. An attacker identifies an application using a vulnerable version of the `phin` library that makes outbound requests based on user-provided input.
2. The attacker submits a URL they control to the application.
3. The application's backend uses `phin` to make a request to the attacker's URL, including sensitive headers required for its own operations.
4. The attacker's server receives the request and responds with an HTTP redirect to a different attacker-controlled server.
5. The vulnerable `phin` library follows the redirect, incorrectly re-sending the original sensitive headers to the new destination.
6. The attacker's second server captures the leaked headers, including authentication tokens or API keys.
7. The attacker uses the stolen credentials to gain unauthorized access to the application or its associated resources.

How to detect it

To detect potential exploitation, review outbound network traffic logs from servers running applications that use the `phin` library. Look for HTTP requests made by the application to external or unexpected domains that receive a 3xx redirect response. A subsequent request from the same application to the new, redirected location containing sensitive headers (e.g., `Authorization`, `Cookie`, `x-api-key`) is a strong indicator of exploitation. Correlate application logs with network flow data to trace these sequences.

What your security team should do

• Immediately update the `phin` package to version 3.7.1 or newer in all affected applications.
• Use dependency scanning tools to identify all instances of the vulnerable `phin` library across your software portfolio.
• As a precaution, rotate any credentials, API keys, or session tokens that may have been used in outbound requests made by services using the vulnerable library.
• Implement strict egress filtering and apply the principle of least privilege to the application's network access to limit its ability to connect to arbitrary external endpoints.