CVE-2026-42260

CVE-2026-42260 is a high-severity improper input validation vulnerability in open-websearch (npm), affecting versions <= 2.1.6. It is fixed in 2.1.7.

Summary

open-websearch has SSRF in fetchWebContent MCP tool: bracketed IPv6 literals and non-resolving hostname check bypass isPrivateOrLocalHostname

Impact

  • Cross-tenant SSRF with full response body. Any client that can speak MCP to the HTTP transport can fetch arbitrary private-network URLs and receive the response body. AWS EC2 metadata, internal dashboards, loopback services, RFC1918 neighbours, all in scope.
  • Pre-auth when enableHttpServer is set. No authentication layer exists on /mcp or /sse; CORS is *.
  • DNS-rebinding / LAN-victim angle. Because /mcp is CORS * and accepts POST, a victim who visits an attacker-controlled webpage while running open-webSearch locally will have their browser used to send tool-call requests, and the tool's response can be exfiltrated back via a simple XHR.
  • Exploitable over stdio too. Even with HTTP disabled, a compromised or prompt-injected MCP client can call fetchWebContent against loopback on the host running the server, a realistic LLM-agent-abuse vector.

No meaningful mitigation in the call chain: only http:// and https:// schemes are accepted, but that is not a restriction for SSRF.

The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.

CVE-2026-42260 has a CVSS score of 8.2 (High). 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 (2.1.7); upgrading removes the vulnerable code path.

Affected versions

open-websearch (<= 2.1.6)

Security releases

open-websearch → 2.1.7 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

See it in your environment

Remediation advice

Two changes, either of which individually closes most of the gap; both together close it fully.

  1. Normalize the hostname before IP checks, and perform a DNS resolution. Use the ip-address package or a similar canonicalizer, and reject any getaddrinfo result whose IP falls in a private CIDR. Keep a bracket-stripping step for IPv6 literals before calling isIP().

    import { lookup } from 'node:dns/promises';
    import { Address4, Address6 } from 'ip-address';
    
    function stripBrackets(h: string): string {
      return h.startsWith('[') && h.endsWith(']') ? h.slice(1, -1) : h;
    }
    
    const BLOCKED_V6_CIDRS = [
      '::1/128', '::/128',
      'fc00::/7', 'fe80::/10',
      '2001:db8::/32', '2002::/16', '64:ff9b::/96',
      '100::/64', 'ff00::/8',
      '::ffff:0:0/96',   // IPv4-mapped, delegate to v4 check
    ];
    
    function ipv6IsPrivate(addr6: Address6): boolean {
      const v4 = addr6.to4();
      if (v4 && v4.isValid()) return isPrivateIpv4(v4.address);
      return BLOCKED_V6_CIDRS.some(cidr => addr6.isInSubnet(new Address6(cidr)));
    }
    
    export async function assertPublicHttpUrl(url: URL | string, label = 'URL') {
      const parsed = typeof url === 'string' ? new URL(url) : url;
      if (parsed.protocol !== 'http:' && parsed.protocol !== 'https:') throw …;
      const host = stripBrackets(parsed.hostname);
    
      // Literal IP case.
      const v = isIP(host);
      if (v === 4 && isPrivateIpv4(host)) throw …;
      if (v === 6 && ipv6IsPrivate(new Address6(host))) throw …;
    
      if (v === 0) {
        // Hostname, resolve and check every record.
        const records = await lookup(host, { all: true, verbatim: true });
        for (const r of records) {
          if (r.family === 4 && isPrivateIpv4(r.address)) throw …;
          if (r.family === 6 && ipv6IsPrivate(new Address6(r.address))) throw …;
        }
      }
    }
    
  2. Dual-pin the connection. Even a perfect pre-connect check has TOCTOU gaps (DNS rebinding between check and axios.get). Use a custom undici Agent whose connect hook validates the actual connected socket IP via socket.remoteAddress. That closes the rebinding window.

  3. Gate the HTTP transport. Require a bearer token (env var) on /mcp and /sse, and restrict binding to 127.0.0.1 by default. CORS * plus no-auth on 0.0.0.0 is the same exposure profile as an unauthenticated open proxy.

Test vectors to add to the suite:

for (const url of [
  'http://[::1]/', 'http://[::]/',
  'http://[::ffff:127.0.0.1]/', 'http://[::ffff:7f00:1]/',
  'http://[0:0:0:0:0:ffff:127.0.0.1]/',
  'http://[0:0:0:0:0:0:0:1]/', 'http://[::0:1]/', 'http://[0:0::1]/',
  'http://[::ffff:a00:1]/', 'http://[::ffff:c0a8:1]/', 'http://[::ffff:a9fe:1]/',
]) expect(isPublicHttpUrl(url)).toBe(false);

Frequently Asked Questions

  1. What is CVE-2026-42260? CVE-2026-42260 is a high-severity improper input validation vulnerability in open-websearch (npm), affecting versions <= 2.1.6. It is fixed in 2.1.7. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
  2. How severe is CVE-2026-42260? CVE-2026-42260 has a CVSS score of 8.2 (High). 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 open-websearch are affected by CVE-2026-42260? open-websearch (npm) versions <= 2.1.6 is affected.
  4. Is there a fix for CVE-2026-42260? Yes. CVE-2026-42260 is fixed in 2.1.7. Upgrade to this version or later.
  5. Is CVE-2026-42260 exploitable, and should I be worried? Whether CVE-2026-42260 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-42260 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-42260? Upgrade open-websearch to 2.1.7 or later.

Other vulnerabilities in open-websearch

Stop the waste.
Protect your environment with Kodem.