CVE-2025-6087: Critical SSRF in OpenNext for Cloudflare

CVE-2025-6087 is a critical (CVSS 9.1) server-side request forgery in the @opennextjs/cloudflare adapter. The image endpoint could be used to load arbitrary remote content under a site's own domain. Cloudflare applied a server-side mitigation, and the root cause fix is in @opennextjs/cloudflare 1.3.0.

What's affected

• Products: the @opennextjs/cloudflare package (OpenNext for Cloudflare) and create-cloudflare, which scaffolds projects that use it.
• Weakness: CWE-918, server-side request forgery.
• Affected: sites deployed with the Cloudflare adapter for Open Next before the patched adapter.
• Fixed: @opennextjs/cloudflare 1.3.0. The record also says create-cloudflare was updated to use the fixed adapter; check its release notes for the exact version.
• Platform mitigation: the record says Cloudflare updated its platform to restrict what the image endpoint will load to images, which mitigates the issue for existing and future deployments.
• CVSS 3.1: 9.1, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.

The record describes an unimplemented feature in the adapter as the cause. Unauthenticated users could ask the image route to fetch a remote URL, and the content came back from the victim site's origin.

How to check if you're exposed

Check which adapter version your project resolves:

npm ls @opennextjs/cloudflare
npm ls create-cloudflare
grep -n "opennextjs" package.json

Anything below 1.3.0 is the version range to review. Check the lockfile as well as package.json, because a loose range can resolve to an older release.

Then look at your build output and Worker configuration for the /_next/image route. If your site serves images through it, requests to that route are the surface in question. The advisory notes that Cloudflare's server-side mitigation already narrows the endpoint to images, so your priority is to update the package so you no longer rely on that platform fix alone.

What to do now

1. Update @opennextjs/cloudflare to 1.3.0 or later, regenerate your lockfile and redeploy.
2. If you scaffolded with create-cloudflare, check that your project pins the fixed adapter, not a cached older one.
3. Review image configuration in Next.js, and allow only remote hosts you actually need.
4. Check logs for unusual /_next/image requests pointing at hosts you do not recognize.
5. Make sure internal services are not reachable from your Workers by default routes, which limits what any request forgery could touch.
6. Run the free in-browser dependency scan on the project to confirm the adapter version in your dependency tree.

Why it matters

Server-side request forgery means the server is tricked into making a request on an outsider's behalf. Here the image route accepted a remote URL and served the result from the site's own domain. That breaks the same-origin idea: content from somewhere else appears to come from you, which helps phishing and can expose internal resources reachable from the server.

The record lists the impact as unrestricted remote URL loading, arbitrary remote content loading, and possible internal service exposure or phishing through domain abuse. The cause was an unimplemented feature in the adapter, a reminder that a framework feature ported to a new runtime needs its safety checks ported too.

The record does not say it was exploited in the wild and it is not in the CISA KEV catalog. Cloudflare's platform change reduces risk for deployed sites, but the project fix is still the proper remedy.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard Gold entry for CVE-2025-6087
• github.com/opennextjs/opennextjs-cloudflare (listed in the CVE record, not fetched)

Last reviewed: 18 October 2026.