jira-mcp-server EUVD-2026-54953

Local access to the host or container running jira-mcp-server is required (AV:L). The attacker must hold low-privilege access sufficient to invoke the MCP tool - specifically the add_attachment_from_public_url handler (PR:L). The vulnerable code path is reached only when the add_attachment_from_public_url function is called and an attacker can supply or influence the imageUrl argument. Exploitation is limited by the requirement for local presence; remote unauthenticated attack is not possible. No special non-default configuration is required - the vulnerability exists in the default code path of version 0.2.0. Scope of SSRF impact is bounded by the network connectivity of the server process itself.

The CVSS 4.0 base score of 4.8 (Medium) with AV:L/AC:L/AT:N/PR:L/UI:N reflects a local-only attack surface with low complexity and low privilege requirements, constraining real-world reach significantly. The E:P supplemental metric confirms a proof-of-concept exploit exists, which elevates the practical risk above what the base score alone suggests. EPSS data was not provided, and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation in the wild at time of analysis. The vulnerable system is a niche open-source MCP server with a small production footprint, further limiting aggregate exposure. The most realistic risk is internal network probing (SSRF against cloud metadata endpoints such as 169.254.169.254 or internal API services) by an attacker who already has local access to the environment running the MCP server. The vendor has not responded to the disclosure, meaning no patch timeline is available - this is a genuine risk gap for any adopters running this specific version.

A local attacker with access to the environment running jira-mcp-server - for example, a co-tenant process or a compromised AI assistant session - invokes the add_attachment_from_public_url MCP tool with a crafted imageUrl value such as http://169.254.169.254/latest/meta-data/. The server calls axios.get against this attacker-controlled URL, potentially exposing cloud instance metadata or probing internal services. A proof-of-concept demonstrating this behavior is confirmed by the CVSS 4.0 E:P metric.