@utcp/http CVE-2026-45366
MEDIUM
GHSA-r8j5-8747-88cm
Severity by source
AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
The @utcp/http package is vulnerable to a blind Server-Side Request Forgery (SSRF) caused by a trust-boundary inconsistency between manual discovery and tool invocation. registerManual() validates the discovery URL against an HTTPS / loopback allowlist, but callTool() reuses the resolved toolCallTemplate.url directly without revalidating, and the OpenApiConverter blindly trusts whatever servers[0].url an attacker-hosted spec declares. An attacker who hosts a malicious OpenAPI spec on a legitimate HTTPS endpoint can declare e.g. servers: [{ url: "http://127.0.0.1:9090" }] or servers: [{ url: "http://169.254.169.254" }]; the converter then produces tools whose URL points at internal services on the agent host.
A separate prefix-bypass also affected the discovery-time check: the previous startsWith('http://localhost') guard let URLs like http://localhost.evil.com through.
Sister advisory
This is the npm/TypeScript counterpart of GHSA-39j6-4867-gg4w / CVE-2026-44661 on the Python utcp-http package. Same vulnerability, same fix shape, same reporter.
Versions and patch state
@utcp/http <= 1.1.1- vulnerable. Both the loopback-redirect (http://127.0.0.1) and the non-loopback internal-IP variants (e.g.http://169.254.169.254,http://10.0.0.5) succeed. Note: thestreamable_httpandssecallToolStreamingpaths in 1.1.1 are TODO placeholders and don't actually fetch URLs, so the runtime SSRF surface in these protocols is currently confined to discovery - a future implementation must also callensureSecureUrlbefore issuing the request.@utcp/http 1.1.2- full fix. Runtime revalidation incallToolcloses the non-loopback variants; theOpenApiConverterrejects, at conversion time, any spec fetched from a non-loopback source that declares a loopbackservers[0].url, closing the loopback-redirect variant.
Impact
A remote attacker who can convince the agent (via the LLM context, prompt injection, or a tool-discovery surface) to register their HTTPS OpenAPI URL can:
- Map internal networks behind the agent.
- Read AWS/GCP IAM credentials from cloud metadata endpoints (
http://169.254.169.254,http://metadata.google.internal). - Reach unauthenticated internal services exposed on loopback (Elasticsearch, Redis HTTP, internal admin panels, the agent's own HTTP server).
- Have responses returned to the LLM, which combined with prompt injection enables exfiltration back to the attacker.
Patch
Commit on dev: 21f63e6.
New helper packages/http/src/_security.ts exposes isSecureUrl, isLoopbackUrl, ensureSecureUrl. Hostname-based validation closes the prefix bypass (http://localhost.evil.com → rejected). All three protocols' registerManual now call ensureSecureUrl(url, 'manual discovery'); callTool re-checks the resolved URL with ensureSecureUrl(url, 'tool invocation') immediately before the axios request. OpenApiConverter rejects remote spec → loopback server.
Workarounds
For users who cannot upgrade immediately:
- Refuse to call
registerManualwith any URL controlled by an untrusted party, even over HTTPS. - Restrict outbound network access from the host running the agent so internal addresses (RFC1918, 169.254.0.0/16, loopback) are unreachable.
Credit
Discovered and reported by @YLChen-007 against the Python sibling implementation (universal-tool-calling-protocol/python-utcp#83). The TypeScript port shared the same code shape and the same vulnerability.
AnalysisAI
Server-Side Request Forgery in @utcp/http <= 1.1.1 allows remote attackers to redirect tool invocations to internal services via malicious OpenAPI specs. An attacker hosting a malicious OpenAPI specification on a legitimate HTTPS endpoint can declare internal server URLs (e.g., http://127.0.0.1:9090 or http://169.254.169.254) in the servers array; the OpenApiConverter blindly trusts these URLs without revalidation during tool invocation, enabling access to cloud metadata endpoints, internal databases, and loopback services. Additionally, a prefix-bypass in hostname validation (startsWith check) allows URLs like http://localhost.evil.com to bypass discovery-time restrictions. Patch version 1.1.2 is available.
Technical ContextAI
The vulnerability stems from a trust-boundary inconsistency in the Universal Tool Calling Protocol HTTP implementation. The registerManual() function validates discovery URLs against an HTTPS/loopback allowlist, but the downstream callTool() function and OpenApiConverter reuse resolved URLs without revalidation. The OpenApiConverter processes OpenAPI specifications and extracts the servers[0].url field without confirming that the URL's origin matches the spec's fetch origin. This allows an attacker to host a malicious spec on a trusted HTTPS endpoint while declaring internal IP addresses or loopback addresses as the tool endpoint. The prefix-bypass affects hostname validation logic that used startsWith('http://localhost') instead of proper hostname parsing, allowing domain names like localhost.evil.com to pass validation. The root cause is improper input validation (CWE-918: Server-Side Request Forgery) combined with insufficient URL canonicalization and cross-layer validation.
RemediationAI
Upgrade @utcp/http to version 1.1.2 immediately, which includes runtime revalidation of URLs in callTool() via the new ensureSecureUrl() helper and rejects remote-fetched OpenAPI specs that declare loopback server URLs at conversion time. For users unable to upgrade immediately, implement network-level mitigations: restrict outbound network access from hosts running the agent so that RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local addresses (169.254.0.0/16), and loopback (127.0.0.0/8) are unreachable via egress filtering. Additionally, enforce strict policies prohibiting calls to registerManual() with any URL controlled by untrusted parties, even over HTTPS; this requires either operator discipline or automated prompt filtering to prevent LLM-driven registration of attacker URLs. The network isolation workaround has the trade-off of blocking legitimate internal tool integrations, so it should be combined with allowlist-based egress rules if internal services must be reached. See https://github.com/universal-tool-calling-protocol/typescript-utcp/security/advisories/GHSA-r8j5-8747-88cm for official guidance.
LiteSpeed User-End cPanel Plugin before 2.4.5 allows privilege escalation (possibly to root), as exploited in the wild i
UAF in Redis 8.2.1 via crafted Lua scripts by authenticated users. EPSS 12.4%. Patch available.
It was discovered, that redis, a persistent key-value database, due to a packaging issue, is prone to a (Debian-specific
Memory Corruption was discovered in the cmsgpack library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10,
Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user
Redis before 2.8.21 and 3.x before 3.0.2 allows remote attackers to execute arbitrary Lua bytecode via the eval command.
A buffer overflow in Redis 3.2.x prior to 3.2.4 causes arbitrary code execution when a crafted command is sent. Rated cr
Code injection in OneUptime monitoring via custom JS monitor using vm module. PoC and patch available.
In applications using jfinal 4.9.08 and below, there is a deserialization vulnerability when using redis,may be vulnerab
An issue was found in Apache Airflow versions 1.10.10 and below. Rated critical severity (CVSS 9.8), this vulnerability
An Integer Overflow issue was discovered in the struct library in the Lua subsystem in Redis before 3.2.12, 4.x before 4
goanother Another Redis Desktop Manager =<1.6.1 is vulnerable to Cross Site Scripting (XSS) via src/components/Setting.v
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today