trace_d04e375701914604addc61b202a83e9b

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": "`fetchWithSsrFGuard` contains a grounded cross-origin redirect replay vulnerability in its 307/308 handling when `allowCrossOriginUnsafeRedirectReplay` is enabled. The redirect loop preserves the original unsafe method and body across origin boundaries and, because cross-origin header filtering intentionally keeps `Content-Type` (and `redirect-headers.ts` also marks `content-language` as safe), body-describing headers are retained on the replayed request. The bundled regression tests explicitly assert this behavior for cross-origin 307/308 redirects. I did not validate additional distinct vulnerabilities beyond this sink behavior.",
  "reports": [
    {
      "title": "Cross-origin 307/308 redirects can replay unsafe request bodies and body-describing headers when unsafe replay is enabled",
      "severity": "HIGH",
      "summary": "`fetchWithSsrFGuard` follows redirects manually. For cross-origin redirects, it only strips the body when `allowCrossOriginUnsafeRedirectReplay` is false. If that flag is true, the original non-GET/HEAD method and body are preserved, and `retainSafeHeadersForCrossOriginRedirect` keeps headers including `Content-Type`. As a result, a cross-origin 307/308 response can cause a guarded request carrying sensitive POST/PUT data to be replayed to a different origin with body-describing headers intact.",
      "rootCauseAnalysis": "In `fetchWithSsrFGuard`, redirect responses are handled in a loop with `redirect: \"manual\"`. After `rewriteRedirectInitForMethod`, the code checks whether `nextParsedUrl.origin !== parsedUrl.origin`. On cross-origin redirects it invokes `rewriteRedirectInitForCrossOrigin({ allowUnsafeReplay: params.allowCrossOriginUnsafeRedirectReplay === true })`. That helper returns the original `init` unchanged whenever `allowUnsafeReplay` is true, so the original method/body survive. The code then applies `retainSafeHeadersForCrossOriginRedirect(currentInit)`, which filters headers via `redirect-headers.ts`. That allowlist includes `content-type` and `content-language`, so the replayed cross-origin request can still advertise the body semantics. The regression tests explicitly assert that for cross-origin 307 and 308 redirects with `allowCrossOriginUnsafeRedirectReplay: true`, `secondInit.method` stays `POST`, `secondInit.body` remains the original JSON payload, `authorization` is stripped, and `content-type` remains `application/json`.",
      "impact": "An attacker controlling or influencing a redirect target can cause sensitive request payloads intended for one origin to be resent to another origin during 307/308-style redirect flows. Even though credential-like headers are stripped, the body itself may contain secrets, tokens, uploaded data, or internal API payloads. Retaining `Content-Type` (and other body-describing headers allowed by the helper) makes the replay more likely to be accepted and correctly parsed by the attacker-controlled destination.",
      "attackPath": "1. Ap