trace_5f8d388a86e746859423f0e4ef26a21b

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` is intended to guard against Server-Side Request Forgery (SSRF) by validating redirect destinations. However, its redirect-following logic fails to strip the original request body and body-describing headers (e.g., `Content-Type`, `Content-Length`, `Content-Encoding`) when a 307/308 cross-origin redirect is encountered. Because 307 and 308 status codes instruct the client to preserve the original HTTP method and body, the guard will replay the full original request—including potentially sensitive request bodies and metadata headers—to a different origin than the one originally intended and authorized. This constitutes a cross-origin body leakage vulnerability, enabling an SSRF attacker who controls a redirect endpoint to exfiltrate or re-target sensitive payloads.",
  "reports": [
    {
      "title": "Cross-origin request body and header replay on 307/308 redirects in fetchWithSsrFGuard",
      "severity": "HIGH",
      "summary": "When fetchWithSsrFGuard follows a 307 or 308 redirect that crosses origins, it preserves the original HTTP method, request body, and body-describing headers (Content-Type, Content-Length, etc.) and replays them to the new origin. This violates the security boundary that SSRF guards are meant to enforce, allowing an attacker-controlled server to redirect requests (including their sensitive payloads) to any reachable origin.",
      "rootCauseAnalysis": "The fetchWithSsrFGuard function implements manual redirect-following logic to enforce SSRF validation on each hop. When it encounters a 307/308 redirect, it correctly preserves the HTTP method per HTTP semantics, but it also unconditionally forwards the original request body and all original headers—including body-describing headers like Content-Type and Content-Length—to the new origin. The guard validates the destination URL but does not consider that replaying the body and its metadata headers across origins constitutes an information leak. The original request was authorized for one origin; replaying its body to a different origin violates that authorization boundary.",
      "impact": "An attacker who can trigger the server to make a fetch request to a URL they control (e.g., via URL injection, webhook configuration, or any SSRF-prone input) can respond with a 307/308 redirect to an arbitrary internal or external origin. The original request body—which may contain authentication tokens, PII, API keys, or other sensitive data—will be replayed in full to the attacker-chosen destination. Body-describing headers (Content-Type, Content-Length) are also forwarded, potentially enabling the destination to correctly interpret the leaked body. This turns a limited SSRF (URL-only) into a full cross-origin data exfiltration vector.",
      "attackPath": "1. Attacker identifies a feature that causes the server to make an outbound HTTP request using fetchWithSsrFGuard (e.g., URL preview,