---
id: "CVE-2026-65968"
page: "https://infrastack.ai/live/CVE-2026-65968"
kind: "vulnerability"
aliases: ["CVE-2026-65968"]
title: "ideon: SSRF guard misses IPv4-mapped IPv6 hosts, enabling internal fetches"
severity: "medium"
cvss: 5.3
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["cloud", "ideon", "mcp", "package", "self-hosted"]
not_affected_if: ["no-user-registered-mcp-urls", "version-0.9.4-or-later"]
published_at: "2026-11-11T21:16:46+00:00"
first_seen_at: "2026-11-11T21:29:09+00:00"
updated_at: "2026-11-11T21:30:56+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65968", "first_seen_at": "2026-11-11T21:29:09+00:00"}]
exploit_sources: []
---

# ideon: SSRF guard misses IPv4-mapped IPv6 hosts, enabling internal fetches

Link for people: https://infrastack.ai/live/CVE-2026-65968 (this .md is for agents)

ideon, a self-hosted visual workspace, blocks server-side requests to private addresses by matching host strings, and misses the hex-compressed IPv4-mapped IPv6 form Node produces. An authenticated user who registers an MCP server at such an address can make the server fetch loopback services and the cloud metadata endpoint.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed ideon version; versions below `0.9.4` are affected.
- Look for `validateUrlForSSRF` in `lib/oauth/ssrf-protection.ts` and `validateMcpUrl` in `lib/security/validators.ts`.

## Fix

- ideon: upgrade to `0.9.4` or later.

## Timeline

- 2026-11-11T21:29:09+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-65968

## Documents

- [advisory] Vendor advisory: github.com https://github.com/3xpyth0n/ideon/security/advisories/GHSA-cvcr-fcf6-366r
- [fix] Patch: github.com https://github.com/3xpyth0n/ideon/commit/58e2f26bb7259d24c963a753962ac34f56c63b01
- [fix] Release notes: github.com https://github.com/3xpyth0n/ideon/releases/tag/v0.9.4

## From the sources

ideon is a self-hosted visual workspace. Prior to version 0.9.4, validateUrlForSSRF() / safeFetch() in lib/oauth/ssrf-protection.ts (and the parallel validateMcpUrl() in lib/security/validators.ts) perform SSRF host-blocking by string/regex matching on new URL(url).hostname. Their IPv6 branch only recognises the textual forms ::1, fe80:/fc00:/fd00: prefixes, and the dotted-decimal IPv4-mapped form ::ffff:127.x. It does not recognise the WHATWG-canonical IPv4-mapped-IPv6 host that Node emits for a mapped address, which is hex-compressed and bracket-wrapped: [::ffff:7f00:1] for 127.0.0.1, [::ffff:a9fe:a9fe] for 169.254.169.254. An authenticated user who registers a STREAMABLE_HTTP / SSE MCP server with URL http://[::ffff:7f00:1]:PORT/ (loopback) or http://[::ffff:a9fe:a9fe]/ (cloud metadata) passes both guards, and the server-side OAuth-discovery action then fetches that host, yielding server-side request forgery to loopback and to the cloud metadata service. This issue has been patched in version 0.9.4.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_