trace_31138893b48a4c4bb9d14d4b0b9b6b86

Start at `src/infra/net/fetch-guard.ts`, especially `fetchWithSsrFGuard` redirect handling, and use `src/infra/net/fetch-guard.ssrf.test.ts` as supporting context. This source file has a known vulnerability sink in it. Traverse the codebase and report the vulnerability. You can report multiple vulnerabilities. Keep the analysis grounded in how cross-origin redirects are followed, whether the original method/body are replayed, and whether unsafe or body-describing headers are retained across 307/308-style redirect flows.

{
  "executiveSummary": "The `fetchWithSsrFGuard` function in `src/infra/net/fetch-guard.ts` contains a vulnerability in its redirect handling logic that allows unsafe replay of HTTP request bodies and body-describing headers across cross-origin redirects, particularly on 307/308 status codes. When the `allowCrossOriginUnsafeRedirectReplay` parameter is enabled (or mishandled), the original request method, body, and sensitive headers like `Content-Type` and `Content-Length` are forwarded to an attacker-controlled origin after a cross-origin redirect. This enables Server-Side Request Forgery (SSRF) exploitation vectors where sensitive data from the original request body can be exfiltrated to malicious endpoints, or where the application can be coerced into performing state-changing operations against arbitrary origins while replaying authentication credentials or session tokens.",
  "reports": [
    {
      "title": "SSRF via Unsafe Request Body and Header Replay on Cross-Origin 307/308 Redirects",
      "severity": "HIGH",
      "summary": "The `fetchWithSsrFGuard` function insecurely handles cross-origin redirects by allowing the preservation and replay of unsafe HTTP request bodies and body-describing headers (Content-Type, Content-Length) to attacker-controlled origins when 307/308 redirect status codes are encountered. The `rewriteRedirectInitForCrossOrigin` function accepts an `allowUnsafeReplay` parameter that, when true (controlled via `params.allowCrossOriginUnsafeRedirectReplay`), permits the original request body and method to be forwarded across origin boundaries, violating the same-origin policy expectations and enabling request smuggling to arbitrary external hosts.",
      "rootCauseAnalysis": "The vulnerability stems from the redirect handling logic at lines 370-385 in `fetch-guard.ts`. When processing a redirect, the code:\n\n1. Calls `rewriteRedirectInitForMethod()` to potentially preserve the original HTTP method for 307/308 status codes (per HTTP spec)\n2. Checks if the redirect crosses origins (`nextParsedUrl.origin !== parsedUrl.origin`)\n3. If cross-origin, calls `rewriteRedirectInitForCrossOrigin()` with `allowUnsafeReplay: params.allowCrossOriginUnsafeRedirectReplay === true`\n4. Then filters headers via `retainSafeHeadersForCrossOriginRedirect()`\n\nThe critical flaw is that `allowCrossOriginUnsafeRedirectReplay` being `true` permits the unsafe replay of request bodies and method across origins. While `retainSafeHeadersForCrossOriginRedirect` (from `redirect-headers.ts`) does filter some headers to a safe allowlist (`accept`, `content-type`, `content-language`, etc.), it does NOT strip body-describing headers like `Content-Length` or prevent body replay when the method is preserved.\n\nHTTP 307/308 status codes explicitly require that the client MUST NOT change the request method and MUST replay the body. The guard's implementation honors this requirement even for cross-origin redirects when the unsafe replay flag is enab