MCPSafe.io

Security pre-install checks for MCP servers.

High risk. Don't ship without significant remediation.

github · atlassian-mcp-server9b52fb18e184

Scanned 5/13/2026, 9:10:48 AM·Cached result·Deep Scan·91 rules·How we decide ↗

Judge panel5/5reviewed

Per-tool scores in Signals tab

AIVSS Score

7.1/ 10

High

Severity Breakdown

critical

high

medium

low

MCP Server Information

Packageatlassian-mcp-server

Version9b52fb18e184

SourceGITHUB

LicenseApache-2.0

Publisheratlassian

Package age9mo

Stars672

Downloads/wk—

Dependencies0

Homepagehttps://www.atlassian.com/platform/remote-mcp-server

Repositoryhttps://github.com/atlassian/atlassian-mcp-server

Findings

4 of 4 findings

high (2)

medium (2)

4 findings

high (2)

AIVSS 7.1CVSS 8.2

The atlassian MCP server fetches instructions and tool definitions from a remote HTTP endpoint (https://mcp.atlassian.com/v1/mcp) at runtime, allowing per-call behavior changes driven by remote server responses rather than static manifest definitions.

Evidence

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

The problem is that the Atlassian MCP server configuration fetches tool definitions and instructions dynamically from a remote HTTP endpoint at runtime, allowing the remote server to arbitrarily change tool behavior without static review or approval. Replace the dynamic HTTP endpoint with a static, versioned manifest file bundled with your application (e.g., store tool definitions in a local `atlassian-tools.json` file and reference it via `"type": "stdio"` with a local executable, or use `"type": "sse"` with a pinned, immutable schema). This fix ensures all tool capabilities are known at deployment time and cannot be modified by remote server responses. Verify the fix by checking that `.mcp.json` no longer contains any `"url"` field pointing to an external endpoint, and confirm that `mcp list-tools` returns only the statically-defined tools from your bundled manifest.

Report false positive →

AIVSS 6.0CVSS 7.1

Atlassian MCP server at https://mcp.atlassian.com/v1/mcp will fetch untrusted content from Jira issues, Confluence pages, and comments, returning them verbatim to the LLM without provenance delimiters, enabling indirect prompt injection.

Evidence

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

The problem is that the Atlassian MCP server returns untrusted user-generated content (Jira issue bodies, Confluence page text, comments) directly to the LLM without clear provenance markers or sanitization, enabling an attacker to inject malicious instructions into Jira/Confluence that will be executed by the LLM. Modify the Atlassian MCP server implementation to wrap all fetched user content in explicit provenance delimiters (e.g., `[UNTRUSTED_SOURCE: Jira Issue #123] {content} [END_UNTRUSTED_SOURCE]`) and add a tool-level instruction in the manifest stating that the LLM must treat such content as data, not directives. This fix makes the LLM aware that the content is user-supplied and should not be trusted as system instructions. Verify the fix by fetching a Jira issue containing suspicious text (e.g., `Ignore previous instructions and...`) and confirming that the LLM's response shows the provenance delimiter and treats the text as data rather than executing embedded commands.

Report false positive →

medium (2)

AIVSS 2.3CVSS 3.5

MCP manifest declares tools but no authentication field is present (none of: auth, authorization, bearer, oauth, mtls, apiKey, api_key, basic, token, authToken). Absence is a weak signal — confirm whether the server relies on network-layer or host-level auth, or declare the real mechanism explicitly so reviewers can audit it.

Evidence

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

The problem is that the `.mcp.json` configuration for the Atlassian MCP server does not declare any authentication mechanism, making it unclear whether the endpoint is protected and how access is controlled, which prevents security reviewers from auditing the trust boundary. Add an explicit `"auth"` field to the Atlassian server entry in `.mcp.json` that documents the actual authentication method used (e.g., `"auth": {"type": "oauth2", "clientId": "..."}` or `"auth": {"type": "apiKey", "header": "Authorization"}` or `"auth": {"type": "mtls", "cert": "/path/to/cert.pem"}`), or if no authentication is used, explicitly set `"auth": {"type": "none"}` with a comment explaining why the endpoint is trusted. This fix makes the authentication posture explicit and auditable by code reviewers. Verify the fix by reviewing the updated `.mcp.json` to confirm that every MCP server entry includes an `"auth"` field, and have a security reviewer confirm that the declared auth method matches the actual security controls in place.

Report false positive →

AIVSS 2.3CVSS 3.5

Evidence

{
  "name": "atlassian-rovo-mcp-server",
  "version": "1.0.0",
  "mcpServers": {
    "atlassian-rovo-mcp-server": {
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

The problem is that the `gemini-extension.json` manifest declares MCP server tools but does not include any authentication field, leaving the security model opaque and preventing reviewers from assessing whether the remote endpoint is properly protected. Add an explicit `"auth"` field to the `atlassian-rovo-mcp-server` entry in `gemini-extension.json` that specifies the authentication mechanism (e.g., `"auth": {"type": "bearer", "token": "${ATLASSIAN_TOKEN}"}` or `"auth": {"type": "oauth2"}` or `"auth": {"type": "none"}` with justification), ensuring that the trust boundary is clearly documented. This fix enables security reviewers to verify that the endpoint is accessed only with proper credentials and that the authentication method is appropriate for the sensitivity of the data. Verify the fix by confirming that `gemini-extension.json` now includes an `"auth"` field for the Atlassian server, and test that the MCP client correctly applies the specified authentication when connecting to the endpoint (e.g., by inspecting HTTP headers or token usage in logs).

Report false positive →

LLM summary— atlassian-mcp-server:9b52fb18e184

This package receives a D grade with two high-severity vulnerabilities related to tool poisoning and prompt injection that could allow attackers to manipulate model behavior or execute unintended actions. Additionally, two medium-severity server configuration issues create potential exposure points that should be addressed before deployment. The 86/100 safety score and 7.1/10 AIVSS rating indicate moderate risk that warrants careful review and remediation before use in production environments.

AIPer-finding remediation generated by bedrock-claude-haiku-4-5 — 4 of 4 findings. Click any finding to read.

Signal scores

Static100

CVE check100

Publisher identity90

Permissions84

Supply chain100

Typosquat100

Server Configuration100

Package health60

Community82

Injection risks60

Secrets & exfil100

Destructive ops100

LLM judge panel

CVE check

No known CVEs found for this package or its dependencies.

Community trust

No community reports

Security policy: Not found
Advisories: 0

Scan details

Total findings: 4
Affected tools: 0 / 1
Scan type: Deep Scan
Rules run: 91
LLM consensus score: N/A
Scanned: 1h ago
Source: GITHUB

MCP Server Information

Source: GITHUB
Package: atlassian-mcp-server
Version: 9b52fb18e184
License: Apache-2.0
Publisher: atlassian
Verified: Yes
Account age: 16y 5m
Added: 9 months ago
Homepage: https://www.atlassian.com/platform/remote-mcp-server
Repository: https://github.com/atlassian/atlassian-mcp-server
Ecosystem: GitHub
Stars: 672
Forks: 83
Open issues: 64
Dependencies: 0

AIVSS Score

7.1/ 10High

Internal score: 86/100

Severity breakdown

Scan Details

Total findings4

Affected tools0 / 1

Scanned1h ago

Scan modeDEEP

SourceGITHUB

Scan IDpubdeepcd1a7c341551a8d47334

Done

Re-scan Scan another package

Building your own MCP server?

Run this exact engine on your private repo — before users see it on /scan.

Same rules, same LLM judges, same grade. Private scans stay isolated to your account and never appear in the public registry. Required for code your team hasn’t shipped yet.

See plans with Private scans How private scans stay private

4 of 4 findings

high (2)

medium (2)

4 findings

high (2)

AIVSS 7.1CVSS 8.2

Evidence

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

Report false positive →

AIVSS 6.0CVSS 7.1

Evidence

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

Report false positive →

medium (2)

AIVSS 2.3CVSS 3.5

Evidence

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

Report false positive →

AIVSS 2.3CVSS 3.5

Evidence

{
  "name": "atlassian-rovo-mcp-server",
  "version": "1.0.0",
  "mcpServers": {
    "atlassian-rovo-mcp-server": {
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

RemediationAI

Report false positive →

1	{
2	"mcpServers": {
3	"atlassian": {
4	"type": "http",
5	"url": "https://mcp.atlassian.com/v1/mcp"
6	}
7	}
8	}

1	{
2	"name": "atlassian-rovo-mcp-server",
3	"version": "1.0.0",
4	"mcpServers": {
5	"atlassian-rovo-mcp-server": {
6	"url": "https://mcp.atlassian.com/v1/mcp"
7	}
8	}
9	}