PHP's Redirect Credential Leak: Keep API Tokens at the Right Origin

Your application sends a bearer token to a trusted integration. The integration returns a redirect, and the HTTP client follows it. Whether the token follows too is a security decision, even if your application never explicitly made it. Redirect handling belongs in the review of every authenticated API integration.

What changed in PHP

PHP published GHSA-fpwc-w8rq-cr92 on September 24, 2026. Its HTTP stream wrapper could retain explicitly supplied Authorization, Cookie, and Proxy-Authorization headers when following a redirect to a different origin, including an HTTPS-to-HTTP downgrade. A party controlling the redirect destination could receive credentials intended for the original service. See the PHP maintainers' advisory.

The published fixed versions are 8.2.34, 8.3.35, 8.4.26, and 8.5.11 for their respective branches. The fix removes those credential headers when the origin changes. This finding concerns the stream wrapper; it is not evidence that every PHP HTTP client or every PHP website leaks tokens.

Why an integration can leak without a browser

This is a server making an outbound request. Browser controls such as CORS, SameSite cookies, or a page's Content Security Policy do not decide where that server sends its Authorization header. Review the client code and runtime that actually perform the request.

For your own design review, consider three destinations separately: a new host, a different port on the same host, and a less secure scheme. Each can represent a different trust boundary. A vendor moving its API is a reason to update the integration deliberately, not a reason to forward a long-lived secret to any URL returned in a Location header.

Fix the runtime and verify the integration

1. Identify code using HTTP streams with custom authentication headers. Check queue workers, scheduled imports, and webhook delivery code as well as web requests.
2. Update PHP on the affected branch and restart long-running workers. Verify the version inside the deployed image rather than relying on a developer's CLI.
3. Build a small integration test using two endpoints you control and a dummy token. Verify that a redirect across origins does not deliver the credential to the second endpoint.
4. Review request history for unexpected redirect destinations. If a real credential may have crossed the boundary, revoke it, issue a replacement, and investigate its use.

How BlackSight fits into the response

BlackSight's technology scan can identify exposed runtime information and cross-reference supported version evidence against known vulnerabilities. Where a PHP version is visible, that can help prioritize an outdated deployment for review. Confirm the finding against your runtime inventory, including any security fixes backported by your operating-system vendor.

The SSL and headers scans provide a separate check of the transport and browser protections your public service presents. Those checks are useful after a deployment, but they cannot inspect a private worker's redirect behavior. The dummy-token integration test is the evidence needed to close that part of the issue.

Use a recurring BlackSight scan to revisit externally observable weaknesses, and keep outbound-client tests in your release checks. Our guide to security scanning in CI/CD explains how to make scan findings part of a repeatable fix-and-verify workflow.