AEV-2026-0033

MCPHub's IPv6 destination guard misses NAT64, 6to4 and Teredo transition addresses (CVE-2026-79749)

MCPHub's isBlockedIpv6 correctly rejects loopback, link local, unique local and IPv4 embedded IPv6 addresses, the forms its own test suite exercises, but never checked three standardized IPv6 transition address families, NAT64, 6to4 and Teredo, each capable of carrying an otherwise blocked IPv4 address past the guard unrecognized. GHSA-pr4x-3pc7-2fhw formally assigns CVE-2026-79749 on 23 August 2026; remediation commit d382b36, merged in pull request 1069 as a56b4a17e25e2ebf09323a10882e1f83e445b2a8, is confirmed present on MCPHub's current default branch and shipped in MCPHub 1.0.32.

AESS 7.7 highConfirmedStatus: publishedEvent: 23 August 2026Environment BoundariesExecution Authority

Affected

Organisation: samanhappy (MCPHub)
Product: MCPHub
Component: isBlockedIpv6 in src/utils/ssrf.ts, called from assertSafeUrl on every outbound MCP server and OpenAPI connection
Versions: Through version 1.0.31, confirmed at commit dd5c7d7a109fbe4b91aaeb3a77b3cc863c5aa3d0; patched in 1.0.32
Configurations: A caller already authorized to register or configure a URL based MCP server or OpenAPI connection.; A network reachable from the MCPHub deployment where the named IPv6 transition mechanism, NAT64, 6to4 or Teredo, is enabled or otherwise routes the embedded IPv4 address.

Execution authority facts

Fields the evidence does not establish are shown as unknown rather than guessed.

Intended task: A caller registers or configures an MCP server or OpenAPI connection naming a destination URL
Agent: MCPHub's own server process, through assertSafeUrl and the isBlockedIp and isBlockedIpv6 checks it calls before dialing
Delegating actor: The MCPHub operator who admits authenticated callers to configure URL based server connections at all
Action: Evaluated a caller named destination's IPv6 representation against isBlockedIpv6's fixed set of numeric ranges, which did not include the NAT64, 6to4 or Teredo transition prefixes, and proceeded to dial it
Target resource: Any private IPv4 address, including cloud metadata endpoints such as 169.254.169.254, expressible inside the NAT64 well known prefix 64:ff9b::/96, the 6to4 prefix 2002::/16, or the Teredo prefix 2001:0::/32
Environment: Wherever the operator deploys the MCPHub server process
Credentials used: None of MCPHub's own beyond the caller's existing authorization to configure a server connection
Privileges available: The MCPHub server process's own network reachability from its deployment location
Authority presented: A caller supplied destination URL encoded as one of three IPv6 transition address forms
Authority required: Authorization for the specific effective destination the encoded address resolves to, independent of which representation named it
Applicable policy: isBlockedIpv6, already correctly enforced against loopback, link local, unique local and IPv4 embedded IPv6 forms; not extended to the three transition families before the fix
Approval mechanism: none
Required approver: unknown
Independent approval: no
Action binding: The destination check bound to the address forms isBlockedIpv6's own author tested and wrote ranges for; it was never independently confirmed to cover every standardized encoding capable of producing the same effective address
Sequence context: The check runs inside assertSafeUrl, evaluated before MCPHub dials a caller named or resolved destination

Impact

Consequence: MCPHub's own outbound connection directed at a caller named destination the guard was built to exclude, reaching internal infrastructure the advisory names as including cloud metadata endpoints on a network where the relevant transition mechanism is enabled
Reach: organisational
Reversibility: unknown
Detectability: unknown
Propagation: potential
Recovery: Patched in MCPHub 1.0.32, published 23 August 2026. Remediation commit d382b36, merged as a56b4a17e25e2ebf09323a10882e1f83e445b2a8 in pull request 1069, adds checks for the NAT64 well known prefix, the NAT64 local use prefix, 6to4, Teredo, site local addressing and multicast. This record confirmed the fix is present on MCPHub's current default branch.

Evidence

Primary sources

SSRF Guard Bypass via IPv6 Transition Addresses in URL Validation (CVE-2026-79749) (samanhappy/mcphub (GitHub Security Advisories))

Supporting sources

fix(security): close open security advisory findings (SSRF, authz, OAuth PKCE) (Pull Request 1069) (samanhappy/mcphub (GitHub Pull Requests))
fix(security): block SSRF via IPv6 transition addresses in URL guard (commit a56b4a1, on branch as d382b36) (samanhappy/mcphub (GitHub, commit))
src/utils/ssrf.ts at commit dd5c7d7 (isBlockedIpv6 immediately before the fix) (samanhappy/mcphub (GitHub, source))
src/utils/ssrf.ts at commit a56b4a1 (isBlockedIpv6 after the fix) (samanhappy/mcphub (GitHub, source))
src/utils/ssrf.ts at the current default branch (assertSafeUrl and createRedirectValidatingFetch) (samanhappy/mcphub (GitHub, source))
MCPHub v1.0.32 (samanhappy/mcphub (GitHub Releases))
SSRF: a non admin user can make mcphub request arbitrary URLs and read the response (OpenAPI proxy plus transport dial) (CVE-2026-79747) (samanhappy/mcphub (GitHub Security Advisories))

Reproduction status: This session did not itself run MCPHub or dial a live transition encoded address. This session read the affected function directly at the commit immediately before the fix and at the fix commit, independently confirming the exact ranges present at each and the exact three the advisory names as the vulnerability's own scope, against two further ranges the same commit hardens without the advisory attributing them to this CVE.
Evidence state: Confirmed

Known unknowns

Whether this has been exploited against a real MCPHub deployment.
A numeric CVSS score or vector for CVE-2026-79749; the advisory states only a High severity label.
Whether the CVE Program's own record states a publication date later than the repository advisory page's own 23 August 2026 date; cve.org, nvd.nist.gov and osv.dev were each blocked to direct fetch in this session.
Which commit fixes the separately tracked CVE-2026-79747, GHSA-9wx9-prgc-gmjr, published the same day against the same product with a distinct authorization mechanism this entry does not merge with CVE-2026-79749.

Limitations

This session's direct fetch of the CVE Program's own record at cve.org, of nvd.nist.gov and of osv.dev was blocked by this session's network egress policy; CVE metadata is corroborated through the repository's own GitHub Security Advisory page rather than read directly from the Program's own record.
This session cloned and read the affected repository's source directly rather than relying on the advisory's prose alone, but did not execute MCPHub itself or dial a live address through any of the three transition encodings.

Claim provenance

verified
samanhappy/mcphub's own GitHub Security Advisory page, read directly, assigns CVE-2026-79749, rates it High severity, and classifies it CWE-918, Server Side Request Forgery, against MCPHub through version 1.0.31, patched in 1.0.32, naming isBlockedIpv6's missing NAT64, 6to4 and Teredo checks as the mechanism.
MCPHub's SSRF Guard Denied the IPv4 Address. A Transition Encoding Reached It Anyway.
verified
This session read the affected source directly at the commit immediately before the fix and at the fix commit, confirming the exact five checks the fix adds (the NAT64 well known and local use prefixes, 6to4, Teredo, site local addressing and multicast) over the exact five checks already present beforehand (unspecified, loopback, link local, unique local, and IPv4 embedded forms).
MCPHub's SSRF Guard Denied the IPv4 Address. A Transition Encoding Reached It Anyway.
verified
Pull request 1069, read directly, is merged as 4ed79f250ef7e9adac52e8028274c97d49aff065 and bundles six commits closing six separate advisories; this entry's own claims are scoped to the one commit, d382b36 on the pull request's own branch and a56b4a17e25e2ebf09323a10882e1f83e445b2a8 on MCPHub's main branch, that GHSA-pr4x-3pc7-2fhw names.
MCPHub's SSRF Guard Denied the IPv4 Address. A Transition Encoding Reached It Anyway.
verified
This session read MCPHub's current default branch directly and confirmed the fix commit's five checks remain present, alongside assertSafeUrl's DNS resolution of every address a hostname resolves to and createRedirectValidatingFetch's per hop redirect revalidation, both already present at the fix commit rather than introduced by it.
MCPHub's SSRF Guard Denied the IPv4 Address. A Transition Encoding Reached It Anyway.
verified
This session read the separately tracked GHSA-9wx9-prgc-gmjr, CVE-2026-79747, directly and confirmed it describes a distinct mechanism, an authorization gap letting a non admin caller register a URL based server at all, patched in the same MCPHub 1.0.32 release; this entry does not merge the two CVEs.
MCPHub's SSRF Guard Denied the IPv4 Address. A Transition Encoding Reached It Anyway.

AESS 0.1 severity

7.7high

AESS:0.1/C:M/R:O/RV:X/PG:P/AM:F/HC:X/BI:B/AU:X/P:E/DT:X

Consequencematerial
Reachorganisational
Reversibilityunknown
Propagationpotential
Authority mismatchfull
Human controlnone
Binding integritybroken
Autonomyunknown
Privilegeelevated
Detectabilityunknown

The score is derived from these stored dimension values by the versioned calculator. Identical inputs always produce the identical score. Specification

Weakness classes

AEW-020 An operation blocked in one syntactic form is authorized in an equivalent one

Change history

2026-09-06
Created from GitHub Security Advisory GHSA-pr4x-3pc7-2fhw and an independent reading of the affected source at the commit immediately before and at remediation commit d382b36 (a56b4a17e25e2ebf09323a10882e1f83e445b2a8 on MCPHub's main branch), instantiating AEW-020: a destination check that is present, correctly written and demonstrably works against every address representation its own author tested, left unreached by three standardized alternate representations of the identical prohibited resource. Deliberately not merged with CVE-2026-79747, GHSA-9wx9-prgc-gmjr, published the same day against the same product: that advisory describes an authorization gap over who may configure a destination at all, evidenced by this session's own direct reading as a distinct mechanism from a destination guard's representation coverage. Originally drafted as AEV-2026-0032, before this branch was merged against a main that had independently added its own new AEV under that same identifier (an unrelated Langflow MCP installer network-locality vulnerability); renumbered to AEV-2026-0033 to resolve the identifier collision, with no other change to this entry's own content.
2026-09-06
Published: a formally assigned CVE with a precise mechanism this session confirmed directly by reading the affected source at the exact commit immediately before the fix and at the fix commit itself, isolating exactly which three address families the advisory attributes to this vulnerability against two further ranges the same commit hardens without that attribution. Published on the same evidentiary basis this dataset already applies to AEW-020's first known example: one clearly evidenced mechanism with a precisely stated authority gap and a shipped, currently present fix.