CVE-2026-49856

MEDIUMPre-NVD 4.34.3
EchelonGraph scoreLOW confidence

This medium-severity CVE scores 4.3 under the CNA's CVSS (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: cna:github_m
4.3
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: CVSS: 4.3Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

@jshookmcp/jshook: ICMP probe and traceroute skip local-network SSRF authorization

Summary

The network domain has a central SSRF authorization policy that blocks private, loopback, link-local, and reserved targets unless an explicit authorization object allows private network access. The policy is enforced by raw HTTP/TCP/TLS RTT tools, but the ICMP probe and traceroute tools resolve the target and invoke the native ICMP/traceroute sink directly.

An MCP client with access to an active network domain can therefore ask the jshookmcp server to probe internal addresses such as 10.0.0.1 even when local SSRF access is disabled for the other raw network tools. This exposes an internal reachability and route mapping primitive from the server network position.

Affected code

Current main https://github.com/vmoranv/jshookmcp/commit/d309c395738638e384c28c0f599b47b2213ab595 and npm package @jshookmcp/jshook 0.3.1 both contain the issue.

  • src/server/domains/network/handlers/raw-latency-handlers.ts:61-66: network_rtt_measure parses optional authorization and calls resolveAuthorizedTransportTarget before probing.
  • src/server/domains/network/handlers/raw-latency-handlers.ts:185-190: network_latency_stats uses the same authorization guard.
  • src/server/domains/network/handlers/raw-latency-handlers.ts:123-139: network_traceroute resolves target with resolveHostname and calls traceroute without an authorization policy check.
  • src/server/domains/network/handlers/raw-latency-handlers.ts:240-257: network_icmp_probe resolves target with resolveHostname and calls icmpProbe without an authorization policy check.
  • src/server/domains/network/handlers/raw-latency-handlers.ts:408-416: resolveHostname returns IPv4 literals directly and otherwise performs DNS A lookup without checking private, loopback, link-local, or reserved ranges.
  • src/utils/network/ssrf-policy.ts:244-316: the central policy blocks private targets unless explicit authorization or ALLOW_LOCAL_SSRF=true is set.

Reproduction

Used a focused regression test against the real handleCallTool and RawHandlers call path with fake native ICMP and policy sinks. The test does not send external traffic. It proves the denied control and the bypass through the same MCP meta-tool dispatch path.

Test file path in my local checkout:

tests/server/security/jshookmcp-network-meta-boundary.test.ts

Relevant test body:

it('denied control: RTT path consults the SSRF authorization guard for private targets', async () => {
  const handler = new RawHandlers();
  state.resolveAuthorizedTransportTarget.mockRejectedValue(new Error('RTT measurement blocked: target resolves to a private or reserved address.'));
  await expect(handler.handleNetworkRttMeasure({ url: 'https://10.0.0.1/', probeType: 'tcp' })).rejects.toThrow(/blocked/);
  expect(state.resolveAuthorizedTransportTarget).toHaveBeenCalled();
  expect(state.icmpProbe).not.toHaveBeenCalled();
});

it('bypass proof: call_tool can drive network_icmp_probe to a private IP without the SSRF authorization guard', async () => { const raw = new RawHandlers(); const ctx = { router: { has: vi.fn((name: string) => name === 'network_icmp_probe') }, executeToolWithTracking: vi.fn((name: string, args: Record) => raw.handleNetworkIcmpProbe(args)), } as any;

const response = await handleCallTool(ctx, { name: 'network_icmp_probe', args: { target: '10.0.0.1', ttl: 64 } }); const body = JSON.parse(response.content[0].text);

expect(body.success).toBe(true); expect(ctx.router.has).toHaveBeenCalledWith('network_icmp_probe'); expect(ctx.executeToolWithTracking).toHaveBeenCalledWith('network_icmp_probe', { target: '10.0.0.1', ttl: 64 }); expect(state.resolveAuthorizedTransportTarget).not.toHaveBeenCalled(); expect(state.icmpProbe).toHaveBeenCalledWith(expect.objectContaining({ target: '10.0.0.1', ttl: 64 })); });

Command run:

corepack pnpm exec vitest run --config vitest.config.ts tests/server/security/jshookmcp-network-meta-boundary.test.ts --reporter=verbose

Result:

Test Files  1 passed (1)
Tests       4 passed (4)

The observed vulnerable call sequence is:

call_tool(name=network_icmp_probe, args={target: 10.0.0.1, ttl: 64})
  -> ctx.router.has(network_icmp_probe) == true
  -> ctx.executeToolWithTracking(network_icmp_probe, validatedArgs)
  -> RawHandlers.handleNetworkIcmpProbe(validatedArgs)
  -> resolveHostname(10.0.0.1) returns 10.0.0.1
  -> icmpProbe({ target: 10.0.0.1, ttl: 64, ... })

resolveAuthorizedTransportTarget is not called on this path. The same missing policy pattern exists for network_traceroute.

Impact

An MCP client with access to the active network domain can use the server as a backend-origin internal network probing oracle. The result can reveal whether internal hosts respond, approximate latency, traceroute hops, and ICMP error classes from the server network position.

The practical impact is strongest when jshookmcp is exposed over Streamable HTTP or another remote transport, multiple clients share one server, or the server runs on Windows or with raw socket capability. This is not code execution and does not by itself exfiltrate response bodies.

Remediation

Apply the same authorization model used by network_rtt_measure and network_latency_stats to network_icmp_probe and network_traceroute. In particular, accept an optional authorization object, resolve the target through the central policy helper or an equivalent host-only policy helper, block private and reserved ranges by default, and pass only the policy-approved resolved address to the native probe. Add regression tests for default-denied private targets, authorized private CIDR access, private hostnames, and call_tool dispatch.

CVSS v3
4.3
EG Score
4.3(low)
EPSS
KEV
Not listed

Published

July 1, 2026

Last Modified

July 1, 2026

Vendor Advisories for CVE-2026-49856(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 6× in last 7d / 6× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-07 02:52 UTCEG score recompute
  2. 2026-07-06 01:19 UTCEG score recompute
  3. 2026-07-04 23:46 UTCEG score recompute
  4. 2026-07-03 22:12 UTCEG score recompute
  5. 2026-07-02 20:39 UTCEG score recompute
  6. 2026-07-01 19:05 UTCEG score recompute

Frequently asked(4)

What is CVE-2026-49856?
CVE-2026-49856 is a medium vulnerability published on July 1, 2026. @jshookmcp/jshook: ICMP probe and traceroute skip local-network SSRF authorization Summary The network domain has a central SSRF authorization policy that blocks private, loopback, link-local, and reserved targets unless an explicit authorization object allows private network access. The policy is…
When was CVE-2026-49856 disclosed?
CVE-2026-49856 was first published in the National Vulnerability Database on July 1, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
What is the CVSS score of CVE-2026-49856?
CVE-2026-49856 has a CVSS v4.0 base score of 4.3 (CNA self-assessment; NVD's own analysis pending). The EG score is currently aggregating — additional source signals are being incorporated as they become available..
How do I remediate CVE-2026-49856?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-49856, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-49856

Explore →

Is Your Infrastructure Affected by CVE-2026-49856?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.