- The GitHub Advisory Database says Astro's image endpoint, used with @astrojs/node, accepted a folder that differed from the output directory only by letter case.
- Exposure needs on-demand rendering, a case-sensitive filesystem and a look-alike folder that an attacker cannot create. Only image files the image service accepts can be read.
- Upgrade astro to 7.4.7 or later. Upgrading @astrojs/node alone is not enough. Check first for sibling folders that differ only by case.
A security check is a claim about what counts as 'the same'
Many security checks rest on a quiet assumption. Is this file inside that folder? Is this user the same user? The answer is only as good as the meaning of 'same'. A GitHub Advisory Database entry from November 13 shows what happens when the check and the machine disagree.
What the advisory describes
Astro is a web framework. Its /_image endpoint serves resized images to pages. The @astrojs/node adapter lets Astro sites run on a Node.js server and uses this endpoint.
Before it reads a local image, the endpoint confirms the file sits inside the build output directory. The advisory says this check ignored letter case when comparing paths.
That matters on Linux and other case-sensitive filesystems. On those systems, DIST and dist are two separate folders. A folder named DIST still passed the check.
The advisory gives an example. The client output directory was /srv/app/dist/client/. A request for a file at /srv/app/DIST/client/secret.png was served. That file lies outside the output directory.
Why most servers are not exposed, and which ones might be
The advisory says an attacker with no login can read image files outside the output directory. This works only if three conditions all hold.
First, the site renders pages on demand and uses the @astrojs/node adapter. Second, the server's filesystem is case-sensitive. Third, a second folder exists whose name matches the output directory apart from letter case. One example is DIST/client sitting beside dist/client.
The advisory calls that layout unusual. It also says the attacker cannot create it. So the attacker does not control the key condition. Your own server layout does.
File type limits the reach too. The advisory says the image service must accept the file. Raster images come back resized. SVG files come back unchanged. Other types fail during processing.
Plain path traversal, such as /../../secret.png, was already blocked. This flaw does not change that. The excerpt we reviewed gives no severity score.
The advisory lists astro 5.14.3 through 7.4.6 as affected when paired with @astrojs/node. It names adapter versions up to 11.1.11. It also lists CVE-2026-126364 as a reference.
The fix lives in astro, not in the adapter
Astro 7.4.7 fixes it. The path check now compares paths exactly. It ignores case only for Windows drive-letter paths.
The advisory stresses that astro provides the vulnerable endpoint, not the adapter. Upgrading @astrojs/node alone is therefore not enough. A team that updates only the adapter has not fixed the problem.
The lesson: a guard has to match the ground it stands on
This is the publication's interpretation, not a claim from the advisory. A check that forgives case works on a disk that also forgives case. On a strict disk, the same check lets through what it should stop. Picture a doorman who ignores spelling on the guest list, in a building that keeps two separate lists.
The check forgave case. The disk did not. A review that only read the logic would miss this kind of gap. The assumption about the disk has to be tested on the machine where the code runs.
What to ask your team
Start with exposure. Do we run Astro with @astrojs/node and on-demand rendering? Which astro version is installed, not just which adapter version?
Then ask about the disk. Is production on Linux or another case-sensitive filesystem? Does any folder beside the build output differ from it only by letter case? The advisory says to confirm none does before upgrading.
Finally, ask what could be read. Which image files sit in any case-variant sibling of the output directory? SVG files there would be returned unchanged. Whatever the answer, put astro 7.4.7 or later on the upgrade plan.
A fix that works needs the check and the filesystem to agree on what 'same' means.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
