MediumGHSA-r3h5-4585-7x3wCVE-2026-126364

Astro: Image endpoint in @astrojs/node can read files from a case-variant sibling of the output directory on case-sensitive filesystems

Published 13 Nov 2026 · Updated 13 Nov 2026

Is your project on an affected @astrojs/node?

Private repo? Upload its lockfile instead, or connect GitHub to check every repo.

Look after several JavaScript apps? Indie watches up to 15 repos, private ones too, for $5 a month. See Indie

Affected packages

Affected
<=11.1.11
Fixed in
No fix released
Affected
>=5.14.3 <7.4.7
Fixed in
7.4.7
Update to the fixed version for your release line, for example:npm install astro@7.4.7

Details

Summary

The /_image endpoint used by the @astrojs/node adapter checks that a requested local image is inside the build output directory before reading it from disk. That check compared paths case-insensitively. On case-sensitive filesystems (such as Linux), a directory whose path differs from the output directory only by letter case is a different directory, but it passed the check.

For example, with the client output directory at /srv/app/dist/client/, a request such as:

/_image?href=/../../DIST/client/secret.png&w=32&f=png

resolved to /srv/app/DIST/client/secret.png and was served, even though that file is outside the output directory.

Impact

An unauthenticated attacker can read image files from outside the output directory, but only when all of the following are true:

  • The site uses on-demand rendering with the @astrojs/node adapter.
  • The server runs on a case-sensitive filesystem.
  • A directory exists whose path matches the output directory except for letter case (for example DIST/client next to dist/client). Such a layout is unusual, and the attacker cannot create it.

Only files the image service accepts can be read. Raster images are returned after resizing; SVG files are returned unchanged. Other file types fail during processing. Plain path traversal outside the output directory (for example /../../secret.png) was already rejected and is not affected.

Affected versions

astro >= 5.14.3, <= 7.4.6, when used with @astrojs/node (all versions up to 11.1.11). The vulnerable image endpoint is provided by astro and used by the @astrojs/node adapter.

Patches

Fixed in astro 7.4.7. The path check now compares paths exactly, and only ignores letter case for Windows drive-letter paths. The fix ships in astro, so upgrading @astrojs/node alone is not enough.

Workarounds

Upgrade to astro 7.4.7 or later. Before upgrading, make sure no directory next to the build output directory has a path that differs from it only by letter case.

Credits

Reported by @zachariah-mithani.

Is GHSA-r3h5-4585-7x3w in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected @astrojs/node, and gives you the command that fixes it.

More advisories for @astrojs/node

  • HighCVE-2026-102984Astro: Malformed port in the Host header can crash the Node adapter · 30 Sept 2026
  • LowCVE-2026-59730@astrojs/node: Backslash-prefixed paths not recognized as internal by trailing-slash redirect · 20 Jul 2026
  • MediumCVE-2026-41322Astro: Cache Poisoning due to incorrect error handling when if-match header is malformed · 23 Apr 2026
  • MediumCVE-2026-29772Astro: Memory exhaustion DoS due to missing request body size limit in Server Islands · 24 Mar 2026
  • MediumCVE-2026-27729Astro has memory exhaustion DoS due to missing request body size limit in Server Actions · 25 Feb 2026
  • MediumCVE-2026-27829Astro is vulnerable to SSRF due to missing allowlist enforcement in remote image inferSize · 25 Feb 2026
All 10 advisories for @astrojs/node

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.