AI built a feature that fetches a URL the user gives — a link preview, an image importer, a webhook tester. It works, you shipped. What you actually shipped will fetch any URL, including your own internal network.
What you shipped
The handler takes a URL from the request and calls fetch on it directly, with no check on where it points.
How anyone exploits it
On most clouds, an internal address returns the server’s own credentials:
?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
Your server happily fetches it and returns the temporary cloud keys to the attacker. From there they reach your whole account. They can also scan your private network.
Why you won’t catch it
You test with normal links — a blog post, an image — and they all load fine. The attack only works with internal addresses you’d never paste in yourself.
Why AI does it
“Fetch this URL” most directly becomes fetch(url). Restricting which URLs are allowed is an extra layer the happy path runs fine without.
The fix
Allowlist the hosts you actually need, and block internal/metadata ranges:
if (!isAllowed(url)) throw new Error('blocked')
Resolve the host and reject private IP ranges before fetching.
Check your app
- User-supplied URLs are checked against an allowlist before fetching.
- Private/internal IP ranges and cloud metadata IPs are blocked.
- The fetch runs with least-privilege network access where possible.
The bigger problem
A senior dev catches this by reflex. But if nobody senior reads the code, the broken version ships — it works in every test, because every test takes the happy path. The author and the reviewer are the same model with the same blind spot.
That’s the gap Velify is built to close: it reads your project and flags exactly this, in plain language, no terminal.