Affected @astrojs/netlify versions: 5.2.0 through 8.2.3 (Source: GitHub Advisory Database (September 30, 2026))
A correct allowlist was still not enough
Picture a developer who sets up an image allowlist. She lists the one domain her site may load pictures from. She reviews it and ships it. The list is correct, and it does not protect her.
This is a hypothetical case. It shows what the advisory describes: a flaw, not a reported attack. The advisory names no victims.
The advisory is a GitHub Advisory Database entry published on September 30, 2026. The flaw is in @astrojs/netlify, the adapter that lets Astro sites run on Netlify. The lesson is that a security setting can be right on paper and wrong in effect. What matters is how the check is built, not only what the list says.
What the advisory says happened
The adapter turns the site owner's allowed image domains into regular expressions. These are text patterns used to match web addresses. According to the advisory, the adapter did not anchor those patterns to the start of the address.
Netlify checks them with a function called RegExp.test(). That function returns true if the pattern appears anywhere in the text. So the approved domain only had to show up somewhere in the address, such as in its path or query string.
The advisory gives an example. An application allowed images.example.com. A crafted address could carry that name in its query string. The allowlist matched it. Netlify then read the address properly and fetched the real host, which was 127.0.0.1.
Think of a bouncer who admits anyone with the club's name written somewhere on their ticket. The name is there, so the check passes. Nobody asks who is actually holding the ticket.
Why this class of bug matters: SSRF
The advisory classes this as server-side request forgery, or SSRF. In plain terms, an outsider tricks a server into making web requests on their behalf. The server often sits inside a trusted network, so it can reach places the outsider cannot.
Here, the entry point is the public /.netlify/images endpoint. The advisory says an unauthenticated attacker can use it. No login is needed. The attacker bypasses the configured image.domains or image.remotePatterns settings and gets Netlify Image CDN to request addresses of their choosing.
The advisory is careful about the possible effect. Whether an attacker could probe or reach internal services depends on Netlify's network-level egress protections. Egress protections are the rules about where Netlify's systems may send traffic.
What the advisory does not claim
The limits are part of the story. The Image CDN tries to transform whatever it fetches into an image. The advisory says this limits how easily an attacker can pull responses back out.
The advisory also says no confidentiality or integrity impact has been demonstrated. That is a statement about demonstrated impact, not a guarantee. The advisory does not say what Netlify's network protections block in practice.
The fix and the stopgap
The fix is in @astrojs/netlify 8.2.4. The generated patterns now have to match the source URL from its first character to its last. The address must match the allowed pattern in full, not just contain it.
The advisory also offers a step to take before upgrading. A team can switch off Netlify Image CDN in the adapter configuration, using the setting imageCDN: false. Another option is to delete the remote image allowlist entries. The advisory links CVE-2026-102983 in the NVD and the 8.2.4 release notes.
Questions to put to your team
First, do any of our sites use the @astrojs/netlify adapter? Check the installed version, not just the version in the project file. Versions 5.2.0 up to and including 8.2.3 are affected.
Second, do we use Netlify Image CDN with remote image domains? If not, ask whether the setting can be switched off.
Third, what internal services could a request from our hosting platform reach? Ask Netlify what egress controls apply to your account. The advisory makes the impact depend on them.
Fourth, who owns the fix? The flaw is in a dependency, so it will not appear in your own code review. Someone has to track advisories for the packages that generate your configuration.
The wider point is simple. Trust lists are only as strong as the code that enforces them. When a tool writes your security rules for you, test the rules it writes.
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.
