CVE-2026-44021: Next.js Image Optimization SSRF

CVE-2026-44021: Next.js Image Optimization SSRF
If you run a Next.js application in production, there is a good chance your frontend server is currently moonlighting as a proxy for attackers to map your internal VPC.
Last week, researchers disclosed CVE-2026-44021, an Server-Side Request Forgery (SSRF) vulnerability targeting the built-in Next.js Image Optimization API. While the underlying flaw stems from loose default configurations, the exploit path is entirely trivial. Attackers are actively scanning for exposed /_next/image endpoints and feeding them cloud metadata URLs, effectively forcing the Next.js server to exfiltrate internal IAM credentials and network topologies.
How the Next.js Image Optimizer Works
To understand the vulnerability, you have to understand the feature. The <Image /> component in Next.js automatically optimizes images on-the-fly. When a user requests an image, the browser hits the /_next/image endpoint with a URL parameter pointing to the source image. The Next.js Node.js server fetches that remote image, compresses it, resizes it, and serves it back to the client.
By design, this is a proxy. The server makes an outbound HTTP request to whatever URL is specified in the url query parameter.
The Wildcard Domain Trap
Next.js requires developers to explicitly allowlist external domains in next.config.js before the optimizer will fetch them. This is intended to prevent SSRF. However, when developers migrate massive, disorganized media libraries or rely on unpredictable third-party CDNs, they often resort to using wildcard patterns to bypass strict validation.
Here is the exact vulnerable configuration pattern we are seeing across breached environments:
// VULNERABLE: next.config.js allowing overly broad remote patterns module.exports = { images: { remotePatterns: [ { protocol: 'https', hostname: '**', // Danger: Wildcard allows any hostname }, { protocol: 'http', hostname: '**', // Danger: Allows unencrypted internal HTTP requests } ], }, }
When this configuration is deployed, the SSRF protection is completely disabled. The server will happily fetch data from any host—including internal IP addresses and non-standard ports.
The Attack Chain: Reaching the Cloud Metadata Service
Imagine you're the on-call engineer analyzing traffic logs. You see a spike in requests to the image optimizer, but the URLs aren't pointing to JPEG files. They are pointing to internal IPs.
An attacker simply crafts a GET request to the public Next.js application, asking it to optimize a "picture" located at the AWS Instance Metadata Service (IMDSv1) IP address:
# Attacker requesting AWS metadata via the vulnerable Image Optimizer # The server fetches the metadata and returns it (often as an image processing error that leaks the body) curl -s -i "https://target-app.com/_next/image?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/&w=256&q=75"
Because the next.config.js uses a wildcard for http traffic, the Node.js server initiates a request to 169.254.169.254. Even though the metadata service does not return a valid image, verbose error handling or caching mechanisms often leak the response body back to the attacker. If the environment is using IMDSv1 (which does not require specific session headers), the attacker walks away with temporary AWS IAM credentials.
An attack flow illustrating how a malicious request traverses the optimizer to hit the internal metadata service.
For a broader look at how adversaries weaponize these proxy mechanics in AWS and GCP, review our Cloud SSRF Hunting Methodology.
Detecting the Abuse
Defenders catch this by monitoring outbound traffic from the frontend server tier. In a healthy environment, a Next.js frontend should only initiate outbound connections to known backend APIs, databases, or specific media CDNs.
If you use a WAF or reverse proxy, you can write a strict rule to drop incoming requests to /_next/image where the url parameter contains private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, and 169.254.169.254).
# Simplified detection logic to flag internal IPs in the URL parameter rules: - id: detect-ssrf-nextjs-image description: "Detects internal IP requests passed to Next.js image optimizer" match: request_uri: "/_next/image" query_args: "url=.*(169\\.254\\.169\\.254|10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[0-1])\\.).*" action: block
Remember, as an authorized tester or bug bounty hunter, always verify the scope rules of your engagement before probing internal infrastructure. Exploiting SSRF to extract credentials is a critical finding, but pivoting further without explicit permission crosses the line from research to unauthorized access.
How to Fix It (What You Should Actually Use)
Mitigating CVE-2026-44021 requires abandoning wildcard domains in your image configuration. You must explicitly define exactly which media hosts your application is permitted to pull from.
// SAFE: Explicitly define allowed remote domains in next.config.js module.exports = { images: { remotePatterns: [ { protocol: 'https', hostname: 'media.yourcompany.com', port: '', pathname: '/assets/**', }, { protocol: 'https', hostname: 'cdn.trusted-partner.net', port: '', pathname: '/images/**', } ], }, }
If your architecture genuinely requires dynamic, unpredictable image hosts (like a web scraper or RSS reader), do not use the built-in Next.js image proxy. Instead, fetch the images securely in a dedicated backend microservice using a hardened HTTP client that explicitly drops connections to private subnets. For a complete blueprint on mapping and securing these data flows, see our Modern Web Recon Workflow.
Wildcards are a developer convenience that invariably becomes an attacker's foothold. Lock down your remote patterns before your frontend hands the keys to your cloud environment to the first scanner that asks.
References / Further reading
- CVE-2026-44021 NVD Entry (Placeholder) - National Vulnerability Database
- Next.js Image Component Documentation - Vercel
- Server-Side Request Forgery (SSRF) - OWASP Foundation
- AWS IMDSv2 vs IMDSv1 Security Dynamics - Amazon Web Services


