CVE-2026-44589

The isBlockedUrl() denylist introduced in [email protected] to remediate GHSA-pqhr-mp3f-hrpp (Dmitry Prokhorov / Positive Technologies, March 2026) is incomplete. The patch advisory states "Decimal/hexadecimal IP encoding bypasses are also handled", that part is true (Node's WHATWG URL parser canonicalizes those forms before validation), but the v6.2.5 implementation misses two independent surfaces in the latest release 6.4.8:

1. IPv6 prefix list is incomplete. The IPv6 branch checks only bare === "::1" || startsWith("fc") || startsWith("fd") || startsWith("fe80"). It misses:

   • [::ffff:7f00:1], IPv6-mapped IPv4 loopback in pure-hex form (RE_MAPPED_V4 regex requires dotted-quad). Reaches 127.0.0.1 on a single-stack-IPv4 host with no other primitive needed.
   • [fec0::/10] (RFC 3879 site-local, deprecated but still routable on legacy networks)
   • [5f00::/16] (RFC 9602 SRv6 SIDs)
   • [3fff::/20] (RFC 9637 IPv6 documentation v2)
   • [64:ff9b:1::/48] (RFC 8215 NAT64 local-use, including embedded IPv4 loopback [64:ff9b:1::7f00:1])

2. No redirect re-validation. isBlockedUrl runs once on the initial <img src>. The subsequent $fetch(decodedSrc, ...) (ofetch, default redirect-follow) follows 30x responses with no second-pass validation. Any allowed origin that returns a 302 to an internal IP, S3 redirect rules, GCS, Azure, CloudFront, any user-content CDN where the attacker can place a single redirect, completes the SSRF.

The net result is that the v6.2.5 SSRF advisory is bypassable in two distinct ways. The same root family as #29 / #38 (ipx) but in a different code path with different gaps, nuxt-og-image does not delegate to ipx, it ships its own validator, and that validator has fresh issues that survived the prior fix.

Affected

The vulnerable code lives in dist/runtime/server/og-image/core/plugins/imageSrc.js and is enforced for every <img src> (and style="background-image: url(...)") inside an OG image component, on production builds (!import.meta.dev).

Vulnerable code (imageSrc.js, verbatim)

function isPrivateIPv4(a, b) {
  if (a === 127) return true;
  if (a === 10) return true;
  if (a === 172 && b >= 16 && b <= 31) return true;
  if (a === 192 && b === 168) return true;
  if (a === 169 && b === 254) return true;
  if (a === 0) return true;
  return false;
}
function isBlockedUrl(url) {
  let parsed;
  try { parsed = new URL(url); } catch { return true; }
  if (parsed.protocol !== "http:" && parsed.protocol !== "https:") return true;
  const hostname = parsed.hostname.toLowerCase();
  const bare = hostname.replace(RE_IPV6_BRACKETS, "");
  if (bare === "localhost" || bare.endsWith(".localhost")) return true;
  const mappedV4 = bare.match(RE_MAPPED_V4);   // /^::ffff:(\d+\.\d+\.\d+\.\d+)$/
  const ip = mappedV4 ? mappedV4[1] : bare;
  const parts = ip.split(".");
  if (parts.length === 4 && parts.every((p) => RE_DIGIT_ONLY.test(p))) {
    /* dotted-decimal IPv4 path */
  }
  if (RE_INT_IP.test(ip)) {
    /* single-integer IPv4 path */
  }
  if (bare === "::1" || bare.startsWith("fc") || bare.startsWith("fd") || bare.startsWith("fe80"))
    return true;                                  // ← gap: only 4 IPv6 prefixes
  return false;                                   // ← everything else is "public"
}

// Then:
async function doResolveSrcToBuffer(src, kind, ctx) {
  ...
  if (!import.meta.dev && isBlockedUrl(decodedSrc)) {
    return { blocked: true };
  }
  const buffer = await $fetch(decodedSrc, {     // ← follows 30x by default
    responseType: "arrayBuffer",
    timeout: fetchTimeout,
  });
  ...
}

Two distinct issues:

• The IPv6 prefix list is hand-rolled (fc, fd, fe80, ::1) and inherits no taxonomy from ipaddr.js or any RFC table.
• $fetch is ofetch, which wraps Node fetch() with default redirect: "follow". The validator does not run on the redirect target.

Reproducer (verbatim, no host privilege)

End-to-end test of isBlockedUrl on a corpus of internal-IP forms, paired with empirical fetch() confirming which forms actually reach loopback. Verbatim output:

  isBlockedUrl?  fetch reaches loopback?  url
  -------------  -----------------------  ---
  ✓ blocked      YES                      http://127.0.0.1:8765/             (control: dotted-decimal loopback)
  ✓ blocked      YES                      http://localhost:8765/             (control)
  ✓ blocked      no(ECONNREFUSED)         http://[::1]:8765/                 (control: IPv6 loopback)
  ✓ blocked      no(EHOSTUNREACH)         http://169.254.169.254:8765/       (control: AWS IMDS)
  ✓ blocked      YES                      http://2130706433:8765/            (control: decimal-int IPv4)
  ✓ blocked      YES                      http://0x7f000001:8765/            (control: hex-int IPv4)
  ✓ blocked      YES                      http://0177.0.0.1:8765/            (control: octal, URL parser canonicalizes)
  ✓ blocked      YES                      http://127.1:8765/                 (control: shorthand, URL parser canonicalizes)

  ✗ NOT blocked  YES                      http://[::ffff:7f00:1]:8765/       (BYPASS: IPv6-mapped, hex form)
  ✗ NOT blocked  no(unreachable)          http://[fec0::1]:8765/             (BYPASS: RFC 3879 site-local)
  ✗ NOT blocked  no(unreachable)          http://[5f00::1]:8765/             (BYPASS: RFC 9602 SRv6)
  ✗ NOT blocked  no(unreachable)          http://[3fff::1]:8765/             (BYPASS: RFC 9637 docs)
  ✗ NOT blocked  no(unreachable)          http://[64:ff9b:1::1]:8765/        (BYPASS: RFC 8215 NAT64)
  ✗ NOT blocked  no(unreachable)          http://[64:ff9b:1::7f00:1]:8765/   (BYPASS: NAT64 + embedded loopback)

The first six bypass rows say "✗ NOT blocked", that is isBlockedUrl returning false (i.e., "this URL is fine to fetch") for each of those addresses. The "fetch reaches loopback" column shows that [::ffff:7f00:1] actually round-trips to 127.0.0.1 on a single-stack-IPv4 dev box; the four cluster ranges are unreachable on the dev box but succeed on dual-stack / k8s / NAT64 / SRv6 networks where any of these prefixes is internally bound.

The "control" rows confirm the bypass set is minimal, the validator catches the obvious cases. The bypasses are the cases the prefix list forgot.

Class 2: redirect amplifier

$fetch(url, { responseType: "arrayBuffer", timeout }) follows 30x by default. Confirmed empirically, ofetch('http://lab.menna.website/test/redirect-to-loopback') (where lab.menna.website returns 302 Location: http://127.0.0.1/) ends with <no response> fetch failed after the connect attempt to 127.0.0.1:80, proving the redirect was followed. On a target where the redirect destination has a service bound, the bytes round-trip back through the OG renderer.

Same primitive as #29 / #38 (ipx redirect bypass), in a different validator. The fix recommendations for #29 also apply here, with the same trade-offs.

A Nuxt application that uses nuxt-og-image (the official-recommended OG generator) and includes any user-influenced URL in an OG component is vulnerable to SSRF that returns the bytes of the internal response as part of the rendered OG image:

• Class 1 directly: <img src="http://[::ffff:7f00:1]:PORT/path"> reaches 127.0.0.1 on the OG worker. If the dev's deployment has anything bound to loopback (admin dashboards, internal HTTP-RPC, Redis HTTP UI, anything running alongside the function on the same machine in self-hosted setups), it leaks.
• Class 1 cluster: the IPv6 cluster ranges trigger only on dual-stack / k8s / NAT64 networks, but those are exactly the production targets where SSRF matters most.
• Class 2 redirect: any allowed CDN with a redirect rule extends the reach to all RFC 1918 / loopback / link-local space.

nuxt-og-image is the OG-image module recommended in Nuxt's official documentation; it is shipped with Nuxt UI templates and is one of the top-2 Nuxt modules by GitHub stars. The user-facing primitive in real apps is "title/avatar comes from a request param", exactly the same <NuxtLink to="/og?avatar=..."> pattern Nuxt docs encourage.

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-44589 has a CVSS score of 3.7 (Low). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (6.4.9); upgrading removes the vulnerable code path.

Kodem intelligence

Three non-exclusive options:

1. Replace the hand-rolled IPv6 prefix list with ipaddr.js's range() predicate (or equivalent), then either:

   • explicitly deny the four cluster ranges that ipaddr.js currently misses (fec0::/10, 5f00::/16, 3fff::/20, 64:ff9b:1::/48), or
   • wait for the ipaddr.js upstream patch (see Vercel #27, same gap, separately disclosed) and bump.
   • In any case, also catch [::ffff:7f00:1] either by widening RE_MAPPED_V4 or by classifying any ::ffff: address as the embedded IPv4.

2. Pass redirect: "manual" in $fetch defaults and reject 3xx. (Compare astro:assets, which already does this, await fetch(url, { redirect: "manual" }) and explicit 3xx-rejection.)

3. Pin the validated IP to the connection. Resolve the hostname once during validation, then pass a custom undici.Agent with connect.lookup returning the resolved IP only. This closes both the IPv6 bypass class (the resolved IP is checked again) and the redirect class (post-30x lookup is forced to the original IP). Reference: request-filtering-agent on npm.

(2) alone closes Class 2. (1) alone closes Class 1. (3) closes both with one change.

1. What is CVE-2026-44589? CVE-2026-44589 is a low-severity server-side request forgery (SSRF) vulnerability in nuxt-og-image (npm), affecting versions >= 6.2.5, < 6.4.9. It is fixed in 6.4.9. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is CVE-2026-44589? CVE-2026-44589 has a CVSS score of 3.7 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of nuxt-og-image are affected by CVE-2026-44589? nuxt-og-image (npm) versions >= 6.2.5, < 6.4.9 is affected.
4. Is there a fix for CVE-2026-44589? Yes. CVE-2026-44589 is fixed in 6.4.9. Upgrade to this version or later.
5. Is CVE-2026-44589 exploitable, and should I be worried? Whether CVE-2026-44589 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-44589 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-44589? Upgrade nuxt-og-image to 6.4.9 or later.