Atlassian
Monthly
Broken access control in Cervantes's JiraController allows any authenticated user to create, edit, or delete Jira tickets belonging to other projects, breaking project-level isolation in the tool's Jira integration. All releases from alpha 0.3 through v1.3-beta are affected (tracked by CPE cpe:2.3:a:cervantessec:cervantes), and successful abuse yields high integrity impact with limited confidentiality impact across the shared Jira workspace. Exploitation requires a valid low-privileged account (CVSS PR:L) and Jira integration must be in use; no public exploit code has been identified at time of analysis, and the issue is not in CISA KEV, though the vendor has published a fix and the aggregate decision label places remediation in the current week.
Path traversal in Backstage's optional @backstage/plugin-scaffolder-backend-module-confluence-to-markdown package (versions before 0.3.25) allows an authenticated user who can execute a template using the confluence:transform:markdown action and control the repository file location to write generated content outside the task workspace, potentially overwriting files writable by the Backstage backend process. The vulnerability is rated CVSS 7.1 with high integrity and low availability impact but no confidentiality impact; exploitation requires the module to be installed and enabled, and the attacker must supply directory-traversal sequences in the repoUrl input. The issue is fixed in version 0.3.25 (Backstage release v1.54.6), and no public exploit has been identified at time of analysis.
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote caller to read any file accessible to the MCP process and have it uploaded to an attacker-controlled endpoint. The issue affects only deployments running the HTTP transports (streamable-http or sse) with READ_ONLY_MODE=false, where a request that carries X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token but no Authorization header is accepted as a 'pat' identity, so the attacker-chosen Atlassian URL is used to build the attachment client and the confluence_upload_attachment (or Jira attachment) tool accepts an arbitrary server-side file_path. CVSS 3.1 rates it 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact, a public Docker-based proof of concept was confirmed by the reporter so publicly available exploit code exists, and EPSS is low at 0.30% (23rd percentile) with no confirmed actively exploited (CISA KEV) status; version 0.22.0 fixes the flaw.
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network caller abuse the streamable HTTP transport, which accepts requests carrying no user identity and silently falls back to the operator's global Atlassian credentials, to force the upload_attachment tool to read any file readable by the MCP process and push its contents into an attacker-chosen Jira issue or Confluence page, where the attacker can retrieve them. Exploitation requires the server to be running the streamable HTTP transport, reachable by the attacker, and configured with shared operator credentials - stdio-only deployments and deployments that enforce per-user identity/tokens are not exposed - and impact is confidentiality-only (file exfiltration), with no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the underlying issue is a path-traversal flaw (CWE-22) fixed in version 0.22.0, and the practical risk is bounded more by who actually deploys this MCP server over the network than by exploit maturity.
MCP Atlassian servers before 0.22.0 write their plaintext OAuth fallback token file using permissions inherited from the process umask, so on a shared host with a permissive or default umask another local account can read the file and reuse the stored refresh and access tokens for Atlassian (Confluence/Jira) access. The flaw is a local, multi-user exposure rather than a remote one: the attacker must already hold a separate account on the same machine and the deployment must actually use the plaintext fallback storage path, which is why the independent assessment scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N instead of the vendor's AV:N rating. Because the leaked refresh token keeps working even after access-token rotation, credential rotation alone does not close the exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in the vendor-released version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an accepted MCP caller to read arbitrary files from the host on which the server runs: the confluence_upload_attachment tool opens a caller-supplied file_path after only converting it with os.path.abspath, with no check that the resolved path stays inside the workspace, and then uploads the contents as a Confluence attachment the caller can download back. The vulnerability is an access-gated, confused-deputy arbitrary-file-read (CWE-22, assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, no integrity or availability impact); exploitation requires an authenticated MCP caller (PR:L), a server older than 0.22.0 configured with Confluence credentials that can write attachments, and a space the attacker can read back - single-user local stdio deployments where the caller already owns the host gain nothing. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in version 0.22.0.
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to 0.22.0, where the Jira update_issue tool converts a caller-supplied attachments argument into local filesystem paths and passes them to the attachment upload implementation without any workspace confinement. A caller able to invoke the update_issue tool can therefore use the server as a confused deputy, reading arbitrary files (e.g. credentials, config, SSH keys) readable by the server process and attaching their contents to a Jira issue the caller controls, with confidentiality impact only - no write or code execution through this flaw. Exploitation is access-gated: the vendor rates it AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6), while our independent assessment scores it PR:L/S:U, since a permitted MCP caller and a shared-credential deployment are realistic prerequisites; no public exploit code has been identified at time of analysis.
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read arbitrary files readable by the server's OS user and exfiltrate them by pushing them to Confluence as attachments. The upload code path converts a caller-supplied file_path to an absolute path without the workspace confinement that had already been added to the download path (CVE-2026-27825), so relative or absolute traversal sequences escape the intended workspace. The independent assessment scores the flaw CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only, no integrity or availability impact), requiring an authenticated caller with access to the MCP tool; the vendor's advisory scored it 8.6 with PR:N and S:C. No public exploit identified at time of analysis, and instances at 0.22.0 or later are not affected.
Unauthenticated network callers can drive Jira and Confluence tool handlers using an operator's globally configured credentials in sooperset/mcp-atlassian prior to 0.22.0, when the server is run over the HTTP streamable-http transport without an independent authentication boundary. The root cause is a missing-authentication flaw (CWE-306) scored CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), giving remote, unauthenticated, low-complexity read and write access with the permissions of the configured service account and no availability impact. Exploitation is configuration-dependent - stdio deployments and instances fronted by an authenticating proxy or enforcing per-user OAuth identities are not exposed - and no public exploit or CISA KEV listing was identified at time of analysis. The issue is fixed in version 0.22.0.
MCP Atlassian server versions prior to 0.22.0 allow an authenticated MCP caller to read arbitrary files from the server host by supplying an absolute or traversal path to the file_path argument of the jira_upload_attachment or confluence_upload_attachment tools, whose bytes are then uploaded into Atlassian and can be read back by the same caller. Exploitation is conditional: it requires the server to be deployed in HTTP or multi-user mode (not single-user stdio), a permitted caller able to invoke the upload tools (CVSS PR:L), and shared operator credentials so the exfiltrated content lands where the attacker can retrieve it; impact is confidentiality-focused (C:H) with limited integrity effect (I:L) and no availability impact. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), though EPSS context was not provided; the vendor-released fix is version 0.22.0.
Arbitrary local file read in MCP Atlassian (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP caller who can reach the Jira or Confluence upload_attachment tool over the HTTP-exposed 'streamable-http' transport to supply a traversal or absolute file_path that is not confined to the workspace, causing the server process to read sensitive local files and exfiltrate them as Atlassian attachments. The vendor rates this 8.3 (CVSS 4.0) with PR:L, high confidentiality impact and no integrity or availability impact, consistent with our independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. Exploitation is limited by prerequisites: working Atlassian upload credentials and tool access must already be held, the HTTP transport must be exposed rather than stdio-only, and reachable data is bounded to files readable by the server process user; no public exploit code was identified at time of analysis and the issue is not listed in CISA KEV.
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised the configured Atlassian backend return a 3xx redirect pointing at an internal address (for example the 169.254.169.254 cloud metadata service), which the MCP server's HTTP session then follows - potentially returning cloud IAM credentials or other internal service data to the attacker. Only deployments configured through the basic-auth or oauth_pat branches are exposed, because those fetcher sessions fail to attach the _make_ssrf_safe_hook redirect validator that the header-PAT branch sets via attach_ssrf_hook=True; header-PAT deployments are not affected. Publicly available exploit code exists (no CISA KEV listing, so no confirmed active exploitation), the vendor fix ships in 0.22.0, and EPSS remains low at 0.32% (26th percentile) with the assessed vector requiring high attack complexity and a malicious upstream prerequisite.
Arbitrary server-local file read and exfiltration in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, low-privileged MCP caller abuse the upload_attachment tool for Confluence or Jira to read files on the server host via a caller-supplied file_path, then retrieve the pages' contents as a normal attachment. The vulnerability is CWE-22 (path traversal): the pre-0.22.0 code only normalized the path with os.path.abspath and performed no workspace confinement, so absolute paths and traversal sequences that escape the working directory are accepted. Impact is confidentiality-only (no write or code execution) and exploitation is conditionally gated - it matters primarily in shared-credential or multi-tenant deployments where a caller's legitimate upload capability exceeds its intended file-read scope; single-user, locally trusted deployments face negligible additional exposure. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor fix is available in version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a low-privileged authenticated MCP caller write attacker-chosen files into the server's working directory, because validate_safe_path defaults its base directory to os.getcwd() and the Confluence attachment call sites omit base_dir. Overwriting an importable Python module in that location can escalate to code execution once the application imports the modified module, and the vector intentionally bypasses the earlier remediation tracked as CVE-2026-27825. Exploitation requires permitted MCP tool access (CVSS vector shows PR:L, i.e. authenticated with low privileges) and a subsequent import or re-import of the overwritten module, so code execution is not immediate; no public exploit code has been identified at time of analysis and there is no CISA KEV entry. The vendor rates this 8.3, while an independent assessment confirms it is a genuine remote-exploitable code-execution path whose real-world priority is moderated by those preconditions.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 allows unauthenticated callers to reach internal or cloud metadata endpoints by exploiting a DNS-rebinding race, because the server validates a hostname's resolved IP and then lets Requests/urllib3 resolve that same hostname again at connection time. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N (7.5): no authentication is needed, but the attacker must control authoritative DNS for a low-TTL name that answers publicly during validation and privately during connection, and the server must actually be able to reach a valuable internal target for the attack to pay off. This is a bypass of the earlier CVE-2026-27826 hardening rather than a new class of bug, no public exploit code or confirmed active exploitation was identified at time of analysis, and environments already running 0.22.0 or with no reachable internal/metadata endpoints are not exploitable.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 applies its ENABLED_TOOLS and TOOLSETS least-privilege filters only when tools are enumerated via tools/list, and never re-checks them when a request is dispatched through tools/call. An authenticated, low-privileged MCP client that knows or guesses the exact name of an excluded tool can therefore invoke read, write, and delete operations against Confluence and Jira that the operator deliberately hid, yielding full confidentiality, integrity, and availability impact against Atlassian data (CVSS 3.1 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, CWE-862 Missing Authorization). The flaw is meaningful only where the toolset configuration is the trust boundary - the highest risk is in shared-credential or multi-tenant deployments - and no public exploit code was identified at time of analysis. A vendor-released patch is available in version 0.22.0.
Information disclosure in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an authenticated caller of the MCP server to read Jira issues, agile boards, and Confluence pages that the operator intended to exclude via JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER, because the Jira search path only checks whether a project clause is present rather than whether it is permitted, the Confluence search path applies an incomplete case-sensitive space check (and lets a caller-supplied spaces_filter replace rather than narrow the configured allowlist), and the Jira board APIs (get_board_issues, get_agile_boards) omit project-filter enforcement entirely. The flaw requires low privileges (an accepted MCP client) and no user interaction, but it only yields data beyond the intended scope when the server's shared operator credentials hold broader Atlassian access than the configured filter - the typical shared-credential, delegated, or multi-tenant MCP deployment. There is no confirmed active exploitation and no public exploit identified at time of analysis; the issue is fixed in 0.22.0, and an independent assessment rates it a moderate-priority filter-bypass/authorization control failure rather than a top-tier emergency.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticated caller to force the MCP server to send requests to an arbitrary destination of the attacker's choosing by supplying the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers, which are consumed by _process_authentication_headers without passing through validate_url_for_ssrf. A successful attack redirects the server's Atlassian fetchers at internal services or cloud metadata endpoints, leaking response data back to the caller (scope-changing, high confidentiality impact, no integrity or availability impact per the assessed vector); no public exploit code was identified at time of analysis and EPSS data was not supplied. The defect is an incomplete remediation of the earlier SSRF CVE-2026-27826, and the project shipped a fix in version 0.22.0.
Unauthenticated network clients that can reach an mcp-atlassian server running in HTTP (streamable-http) transport mode can invoke Atlassian tools using the operator's globally configured Jira or Confluence credentials, inheriting that account's read and write access to both products. The flaw is an authentication deficiency (CWE-287) in which the request path through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, and _get_fetcher accepts a request without a verified user identity and falls back to the shared, operator-scoped credential set; exploitation requires no authentication (PR:N), user interaction, or special privilege once the endpoint is reachable, which is why the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N (10.0). Exposure is limited to the shared-credential/multi-tenant deployment pattern - stdio-transport installs and per-user token deployments that never fall back to global credentials are not affected - and at the time of analysis no public exploit code had been identified and the issue was not confirmed actively exploited (CISA KEV).
Server-side request forgery in MCP Atlassian (sooperset) versions before 0.22.0 lets unauthenticated callers drive the server into issuing HTTP requests to internal or cloud-metadata addresses by exploiting a DNS-rebinding race in the header-based authentication flow. Only deployments on the header_pat branch, which trust caller-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers, are exposed; the URL is validated for SSRF once and then re-resolved by the HTTP client at connection time, so a low-TTL attacker-controlled hostname can return a public IP during validation and 127.0.0.1 or 169.254.169.254 during the actual request, with roughly 50 percent success per attempt. Publicly available exploit code exists (a DNS-rebinding proof of concept using rbndr.us), EPSS is low at 0.42 percent (36th percentile), there is no KEV listing indicating confirmed actively exploited (CISA KEV) status, and the vendor-released patch is version 0.22.0.
Arbitrary server-local file disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, permitted Confluence MCP caller read any file accessible to the server process by passing a traversal or absolute path to the upload_attachment tool and receiving the contents back as a published attachment. Exploitation requires only a valid MCP caller session (no user interaction, low privileges per PR:L), and the scope change in the CVSS vector reflects the server process acting as a confused deputy on behalf of the caller, yielding high confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no CISA KEV listing; the practical risk is highest in shared-credential or multi-tenant MCP deployments where the caller is less privileged than the server process, and is low in single-user deployments where the caller already owns the underlying filesystem. Vendor-released patch: 0.22.0.
Server-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0 allows remote, unauthenticated attackers to make the server issue HTTP requests to internal or otherwise protected network resources. The flaw lives in validate_url_for_ssrf, which parses a URL's authority differently from the Requests connection layer when the server runs the header-based Jira/Confluence URL authentication flow, so a crafted backslash-containing URL can pass validation as an external hostname while the HTTP client actually connects to an internal host. Exploitation is limited to deployments that accept client-supplied Atlassian base URLs, requires the attacker to win the parser-versus-connection-layer discrepancy reliably, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Stored cross-site scripting in GoCD's Compare Pipeline page affects versions 18.3.0 through 25.x and allows an attacker holding commit access to a tracked material to inject URI or HTML special characters into a commit comment that GoCD later renders as an unescaped tracking-tool link. Successful exploitation within a victim's browser session can expose a privileged user's session or permit changes performed with that victim's credentials and privileges, though the CVSS 4.0 vector (AC:H/AT:P/PR:L/UI:P) and the layered prerequisites make this a non-trivial, non-drive-by issue. The flaw is fixed in GoCD 26.1.0, and no public exploit has been identified at time of analysis.
Authenticated denial of service in Atlassian Confluence Data Center allows a low-privileged logged-in user to make the application unavailable to its intended users, with no confidentiality or integrity impact. The flaw was introduced across a broad swath of releases (8.9.0 through 10.2.0) and Atlassian rates it High with a CVSS 4.0 score of 7.1. Fixed builds are 9.2.24 and later on the 9.2 branch and 10.2.17 and later on the 10.2 branch; no public exploit code or confirmed active exploitation was identified at time of analysis.
Improper authorization in Atlassian Jira Service Management Data Center 11.3.0 through 11.3.10 lets an authenticated, low-privileged attacker reach functionality and data they should not be able to access, with the vendor scoring it 7.1 in CVSS 4.0 (AV:N/AC:L/PR:L/UI:N/VI:H). Atlassian states the flaw was discovered through its own penetration-testing program and that the impact could extend from exposure of sensitive resources to arbitrary code execution, though the published CVSS 4.0 vector only credits a high integrity impact and rates confidentiality and availability as none. No CISA KEV listing, EPSS score, or public exploit code was provided in the source data, so at time of analysis this should be treated as a confirmed but not yet observed-in-the-wild authorization bypass; patched versions (11.3.11 and later) are already available.
An improper authorization flaw in Atlassian Confluence Data Center lets an authenticated, low-privileged user reach resources and functionality they should not be able to access, resulting in high confidentiality impact against the affected instance. The defect was introduced across a broad set of release trains — 7.4.0, 7.13.0, 8.5.0, 8.9.0, 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 — meaning most currently maintained Data Center deployments built on those lines are exposed until upgraded. Atlassian rates the issue 7.1 (CVSS 4.0, AV:N/AC:L/PR:L/UI:N/VC:H) and has shipped fixes in 9.2.24 and 10.2.17; there is no evidence of public exploit code or confirmed active exploitation at time of analysis.
MCP Atlassian, the Model Context Protocol server that bridges AI clients to Confluence and Jira, resolves client-supplied attachment paths on the server itself, so a remote client with write-tool access can read arbitrary files from the server host in versions before 0.22.0. The confluence_upload_attachment, confluence_upload_attachments and jira_update_issue tools all funnel an unconfined file_path into os.path.abspath() plus open(), and the resulting bytes are uploaded to Atlassian as an attachment — giving the attacker a convenient exfiltration channel for server files, environment-held Atlassian credentials, or other tenants' data. The vendor advisory includes a working proof-of-concept (publicly available exploit code exists), but no active exploitation is confirmed (no CISA KEV listing); the CVSS 3.1 score is 7.7 with EPSS not provided in the input. Only local single-user stdio deployments are outside the trust boundary.
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constraints when neither jwtIssuer nor jwtAudience is configured, causing the embedded Vert.x HTTP server to accept any unexpired token signed by any key in the trusted keystore. Affected are Apache Camel versions 4.8.0 through 4.21.x across both the application server and management server paths. An attacker who possesses a valid JWT from any identity provider trusted by the configured keystore - such as a token legitimately issued for a different service in a shared IdP environment - can authenticate to the Camel HTTP endpoints without holding credentials intended for that service. No public exploit has been identified at time of analysis, and CISA KEV listing is absent.
Improper authorization in Atlassian Bamboo Data Center across six affected release lines (10.0.x through 12.1.x) enables authenticated low-privilege users to bypass access controls and reach restricted resources or functionality, with Atlassian tagging the flaw as carrying arbitrary code execution risk. The vulnerability was discovered through Atlassian's own penetration testing program and affects Data Center deployments only - not Bamboo Cloud. No public exploit code or CISA KEV listing exists at time of analysis, but the high confidentiality and integrity impact ratings (VC:H/VI:H in CVSS 4.0) and the RCE tag make this a credible escalation risk in any environment where untrusted or lightly-privileged users hold Bamboo accounts.
Broken authentication in Atlassian Crowd Data Center 7.2.1 permits a remote, unauthenticated attacker to perform actions on behalf of any other user, effectively bypassing the platform's identity and session controls. The flaw was introduced specifically in version 7.2.1, discovered through Atlassian's Penetration Testing program, and carries a CVSS 4.0 score of 8.8 with scope-changing impact that cascades to all downstream SSO-federated applications. No active exploitation (CISA KEV) and no public exploit code have been identified at time of analysis, though the cross-system propagation potential demands urgent patching.
Stored cross-site scripting combined with privilege escalation in Confluence Data Center and Server lets an unauthenticated attacker persist malicious HTML/JavaScript that runs in a victim's browser, enabling actions performed as a higher-privileged user and abuse of insecure default configurations. Atlassian rates it Critical (vendor CVSS 4.0 score 9.3; the advisory body text separately cites 8.6), and it affects a long list of 7.x through 10.2.x branches. There is no public exploit identified at time of analysis and it is not on CISA KEV; it was found through Atlassian's bug bounty program.
Arbitrary file read via path traversal in mcp-atlassian prior to 0.22.0 allows any authenticated MCP client to supply an absolute or traversal path to the confluence_upload_attachment tool, causing the server to open and exfiltrate the targeted file as a Confluence attachment. On Linux deployments, /proc/self/environ exposes live API credentials including CONFLUENCE_API_TOKEN, AWS keys, and database passwords, enabling full Atlassian account takeover and lateral movement. A confirmed prompt injection attack chain means threat actors who can write content an AI agent will read - such as a malicious Jira ticket - can trigger the same credential exfiltration with zero MCP credentials; publicly available exploit code and a demonstration video exist.
SSRF protection bypass in Flowise (npm/flowise ≤ v3.1.2) allows complete circumvention of all IPv4 CIDR deny rules via IPv4-mapped IPv6 addresses, rendering the SSRF fix introduced in v3.0.13 for CVE-2026-31829 entirely ineffective. An attacker who controls DNS for a hostname referenced in a Flowise chatflow HTTP component can set a AAAA record to `::ffff:169.254.169.254` or any RFC1918 target; Flowise resolves the address, the `isDeniedIP()` kind mismatch silently skips all IPv4 CIDR checks, and the request reaches cloud IMDS endpoints or internal services. A publicly available proof-of-concept script (poc_ssrf_bypass.js) confirms the bypass against ipaddr.js@2.2.0; no CISA KEV listing has been identified at time of analysis.
Credential exfiltration in swagger-typescript-api (npm, versions <= 13.12.1) allows a malicious OpenAPI spec to steal a developer's bearer token during code generation: when `--authorizationToken` is set, the generator attaches that token to the Authorization header of every request it makes while resolving external `$ref` URLs, with no same-origin check, so a `$ref` pointing at an attacker-controlled host receives the token verbatim. The stolen credential is typically high-value (GitHub PAT, OAuth bearer, CI service-account token) and its capture is equivalent to full account/scope takeover. A working proof-of-concept was supplied by the reporter (publicly available exploit code exists); it is not listed in CISA KEV and there is no evidence of active exploitation.
Remote code execution in Atlassian Sourcetree for Mac and Windows 3.4.11-3.4.12 enables an authenticated attacker to execute arbitrary code on a victim's machine via code injection (CWE-94), achieving full confidentiality, integrity, and availability compromise. The attack requires low-privilege authentication and user interaction - consistent with a scenario where a victim opens or processes attacker-controlled repository content within the application. No public exploit identified at time of analysis; EPSS at 0.30% (22nd percentile) reflects low current exploitation probability, and the vulnerability was responsibly disclosed through Atlassian's Bug Bounty program rather than discovered in active exploitation.
Denial of service in Atlassian Confluence Data Center allows an authenticated attacker to render the application unavailable to legitimate users by triggering resource exhaustion that disrupts the host's services. Affected releases span the 9.0.x through 10.2.x branches, with a CVSS 4.0 score of 7.1 (High) driven entirely by availability impact. No public exploit has been identified at time of analysis; the flaw was discovered internally via Atlassian's penetration testing program rather than through in-the-wild activity.
Information disclosure in Atlassian Confluence Data Center allows an unauthenticated remote attacker to read sensitive information from affected instances, carrying a CVSS 4.0 score of 8.2 (High). The flaw was introduced across a wide span of releases (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, 10.2.0) and was found internally by Atlassian. No public exploit identified at time of analysis and it is not listed in CISA KEV, but the network-reachable, unauthenticated nature makes patching a priority for internet-facing deployments.
Path traversal in XWiki running on Jetty 12+ lets remote users read arbitrary files the Jetty process can access by sending doubly URL-encoded '../' sequences to the skin resource endpoint (e.g. /xwiki/bin/skin/..%252f/..). Depending on how deep the webapp sits below root, this exposes both in-webapp secrets such as WEB-INF/xwiki.cfg and Hibernate configuration, and out-of-webapp OS files like /etc/passwd. No public exploit or active exploitation is tracked, but the vendor advisory (GHSA-qj4x-9g63-25g6) itself publishes working request URLs, so weaponization is trivial.
Remote code execution in XWiki Pro Macros (com.xwiki.pro:xwiki-pro-macros) versions >=1.13 and <1.14.5 allows any authenticated user with page-edit rights to execute arbitrary Groovy code via the excerpt-include macro, which fails to escape the included page's title and renders excerpt content with the macro's elevated rights. A working proof-of-concept is published in the GHSA advisory demonstrating injection through both a crafted page title and excerpt body. No public exploit identified at time of analysis as actively used, but the publicly available exploit code exists in the advisory itself.
Two-factor authentication bypass in syracom AG Secure Login (2FA) plugin 3.4.0.x for Atlassian Jira, Confluence, and Bitbucket allows an attacker holding valid first-factor credentials to skip the 2FA challenge entirely by injecting strings like 'AtlassianMobileApp' or 'JIRA' into the HTTP User-Agent header. The plugin treats such requests as mobile-app traffic and waives 2FA enforcement on protected web resources, effectively neutralizing the security control the plugin exists to provide. No public exploit identified at time of analysis, but the technique is trivial to reproduce from the public advisory text.
Information disclosure in XWiki Platform's LiveTableResults macro allows unauthenticated remote attackers to reconstruct user password hashes and salts one bit at a time by sending approximately 768 crafted requests with manipulated class-per-property parameters. This is a bypass of the prior fix for GHSA-5cf8-vrr8-8hjm, which failed to account for an alternate parameter path. No public exploit is identified at time of analysis, but the technique is fully described in the vendor advisory.
Authentication bypass in Microsoft's SAML SSO plugins for Atlassian Jira (versions 1.0.0 through 1.3.2) and Confluence (versions 1.0.0 through 7.3.x) allows a remote, unauthenticated attacker to impersonate other users and elevate privileges over the network due to an incorrectly implemented authentication algorithm. Rated CVSS 9.1 with full confidentiality and integrity impact, the flaw is deemed automatable with total technical impact by CISA's SSVC framework, though EPSS remains low (0.12%) and no public exploit has been identified at time of analysis. A vendor patch is available.
Server-side request forgery combined with missing authentication in firefighter-incident Python package allows unauthenticated remote attackers to exfiltrate AWS IAM credentials from cloud metadata endpoints. The `/api/v2/firefighter/raid/jira_bot` endpoint accepts arbitrary URLs in the `attachments` parameter, fetches them server-side without validation, and uploads responses as Jira attachments — enabling SSRF against internal services including `http://169.254.169.254/` (AWS EC2 Instance Metadata Service). Vendor-released patch (version 0.0.54) enforces authentication and validates attachment URLs to block private/link-local/loopback addresses. No public exploit identified at time of analysis, but exploitation is trivial given detailed advisory with exact vulnerable code paths.
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoStream-based remote aggregation repository reads objects from an Infinispan cache using java.io.ObjectInputStream with no ObjectInputFilter applied. Any attacker able to write to the backing Infinispan cache can plant a malicious serialized gadget that executes in the application context during routine get/recover operations. Publicly available exploit code exists, though EPSS is low (0.08%) and there is no evidence of active exploitation.
Remote code execution in Atlassian Bamboo Data Center versions 9.6.0 through 12.1.0 allows authenticated attackers to execute arbitrary OS commands via command injection vulnerability. The attack requires low-privilege authentication (PR:L) but no user interaction, enabling complete system compromise across confidentiality, integrity, and availability with cross-scope impact (SC:H/SI:H/SA:H indicating container escape or lateral movement potential). Atlassian has released patches for three major version branches (9.6.25, 10.2.18, 12.1.6). No active exploitation confirmed in CISA KEV at time of analysis, though the authenticated nature and critical CVSS 9.4 score warrant immediate patching for internet-exposed instances with broad user access.
Improper authorization in GitLab CE/EE Jira Connect integration allows authenticated users with minimal workspace permissions to steal installation credentials and impersonate the GitLab application. Affects versions 14.3 through 18.8.6, 18.9.0-18.9.2, and 18.10.0. Vendor-released patches available in versions 18.8.7, 18.9.3, and 18.10.1. High CVSS score (8.1) reflects significant confidentiality and integrity impact with low attack complexity. No public exploit identified at time of analysis, though detailed disclosure exists via HackerOne report.
Remote code execution in Atlassian Bamboo Data Center versions 9.6.0 through 12.1.0 allows authenticated attackers with high privileges to execute arbitrary code on affected systems with a CVSS score of 8.6. The vulnerability impacts multiple major versions with no patch currently available, requiring immediate upgrade to patched releases such as 9.6.24, 10.2.16, or 12.1.3. Organizations unable to upgrade should prioritize access controls for high-privileged accounts until remediation is possible.
LibreChat versions 0.8.2 through 0.8.2-rc3 contain an authentication bypass vulnerability in the Model Context Protocol (MCP) OAuth callback endpoint that allows attackers to steal OAuth tokens by tricking victims into completing an OAuth flow, resulting in account takeover of the victim's MCP-linked services like Atlassian and Outlook. No active exploitation is known (not in KEV), no POC is publicly available, and EPSS data is not yet available for this newly disclosed vulnerability.
MCP Atlassian server has a path traversal vulnerability enabling unauthorized access to Confluence and Jira data outside the intended scope.
Unauthenticated attackers can abuse the MCP Atlassian server to perform arbitrary outbound HTTP requests by manipulating HTTP headers, enabling credential theft from cloud instance metadata endpoints or internal network reconnaissance without requiring authentication. The vulnerability exists in the HTTP middleware layer prior to version 0.17.0, affecting Atlassian Confluence and Jira deployments. No patch is currently available.
XXE injection in Atlassian Crowd Data Center and Server 7.1.0+ enables authenticated attackers to read local and remote files, significantly compromising confidentiality and availability. The vulnerability requires high privileges to exploit but accepts no user interaction, affecting multiple Crowd versions until patching to 7.1.3 or later. No patch is currently available for all affected versions.
This High severity RCE (Remote Code Execution) vulnerability was introduced in version 5.2 of Confluence Data Center and Server. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
All versions of Confluence Data Center and Server are affected by this unexploited vulnerability. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Atlassian has been made aware of an issue reported by a handful of customers where external attackers may have exploited a previously unknown vulnerability in publicly accessible Confluence Data. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
There is a command injection vulnerability using environment variables in Bitbucket Server and Data Center. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Multiple API endpoints in Atlassian Bitbucket Server and Data Center 7.0.0 before version 7.6.17, from version 7.7.0 before version 7.17.10, from version 7.18.0 before version 7.21.4, from version. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
The Atlassian Questions For Confluence app for Confluence Server and Data Center creates a Confluence user account in the confluence-users group with the username disabledsystemuser and a hardcoded. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Use of Hard-coded Credentials vulnerability could allow attackers to gain access using credentials embedded in source code.
In affected versions of Confluence Server and Data Center, an OGNL injection vulnerability exists that would allow an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Affected versions of Atlassian Jira Server and Data Center allow remote attackers to read particular files via a path traversal vulnerability in the /WEB-INF/web.xml endpoint. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Affected versions of Atlassian Confluence Server allow remote attackers to view restricted resources via a Pre-Authorization Arbitrary File Read vulnerability in the /s/ endpoint. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
There was a server-side template injection vulnerability in Jira Server and Data Center, in the ContactAdministrators and the SendBulkMail actions. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Atlassian Crowd and Crowd Data Center had the pdkinstall development plugin incorrectly enabled in release builds. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Confluence Server and Data Center had a path traversal vulnerability in the downloadallattachments resource. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
The HipChat for JIRA plugin before 6.30.0 for Atlassian JIRA allows remote authenticated users to execute arbitrary Java code via unspecified vectors, related to "Velocity Template Injection. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and EPSS exploitation probability 82.5%.
Directory traversal vulnerability in the Issue Collector plugin in Atlassian JIRA before 6.0.4 allows remote attackers to create arbitrary files via unspecified vectors. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable. Public exploit code available and EPSS exploitation probability 65.8%.
Path traversal in the Backstage Confluence-to-Markdown scaffolder module can let an authenticated Backstage user who runs a template with attacker-influenced Confluence content cause file writes outside the intended image directory, affecting integrity and potentially availability of the scaffolder workspace. The vulnerable package is @backstage/plugin-scaffolder-backend-module-confluence-to-markdown before 0.3.25; exploitation requires the optional module to be deployed and wired into a template, plus an attacker able to create or modify Confluence attachment metadata. There is no public exploit identified at time of analysis, and the issue is fixed in version 0.3.25 and Backstage release v1.54.6.
Server-side request forgery in DevaslanPHP project-management affects versions 1.2.1 through 1.2.4 and v2.0.0-beta1 and allows an authenticated, low-privileged user to make the application issue requests to attacker-chosen destinations. The flaw sits in the updateJiraProjects function of the /jira-import endpoint, where host, username and token parameters are accepted without an adequate authorization check (per the independent assessment, a missing canAccess check), so any user who can reach the Jira Import feature can force outbound connections from the server while only obtaining limited read/write effect. Publicly available exploit code exists (also reflected by the E:P metric in the vendor-supplied CVSS 4.0 vector), but there is no indication of confirmed active exploitation, and the vendor was contacted early and did not respond. This is a genuine but low-priority issue: the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, i.e. partial confidentiality and integrity impact only, gated behind authenticated access to the import feature.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an MCP caller who controls the public Jira base URL have a Jira user-lookup request redirected to an internal address, bypassing the SSRF redirect protections previously added for CVE-2026-27826. The vulnerable path is JiraUserMixin._lookup_user_by_permissions, which calls the module-level requests.get instead of the fetcher's protected session, so the response hook that enforces redirect validation is never applied. Impact is limited and blind (confidentiality-only, no integrity or availability effect) and, per the independent assessment, requires the attacker to control the Jira endpoint plus a server that issues a redirect to an internal target, making it most realistic in HTTP/multi-user or shared-credential deployments rather than single-user stdio setups with a fixed trusted Jira URL. No public exploit code was identified at time of analysis and there is no KEV listing; v0.22.0 resolves the issue.
Local credential disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 allows a co-resident local user or process to read stored Atlassian OAuth access and refresh tokens and reuse the associated Atlassian session. The server creates its ~/.mcp-atlassian directory and the oauth-<client_id>.json token file without explicit owner-only permission modes (CWE-732), so the resulting group- or world-readable bits - an artifact of a permissive process umask - expose the tokens to anyone with read access on the host; the CVSS vector (AV:L/PR:L) confirms this requires an existing local account and no network reachability. Only multi-user or multi-process hosts that rely on the OAuth token-file fallback are exposed; single-user hosts with a restrictive umask are not. No public exploit identified at time of analysis, and the vendor CVSS of 5.5 understates impact only marginally - the independent assessment adds a low integrity component (I:L) because a stolen refresh token can also be used to act within the victim's Atlassian tenant. The issue is fixed in version 0.22.0.
Reflected cross-site scripting in MCP Atlassian versions prior to 0.22.0 lets unauthenticated remote attackers inject markup or script through the OAuth error query parameter, which the CallbackHandler._send_response method in oauth_setup.py interpolates into an HTML page without escaping (CWE-79). Exploitation requires a deployment that uses the interactive OAuth setup flow and a targeted user who is actively completing that flow and opens the attacker's crafted authorization callback, which is why the assessed impact is confined to the victim's browser context (CVSS 5.4, C:L/I:L, UI:R) with no server-side code execution or Atlassian data-plane access. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in version 0.22.0.
Authenticated path traversal in MCP Atlassian (mcp-atlassian) prior to 0.22.0 lets a permitted MCP caller supply an absolute or traversal-laden file_path to the Confluence attachment-upload flow and cause the server to read and upload an arbitrary local file using the operator's credentials, exposing file contents to the linked Confluence instance. The flaw is a direct gap left by the CVE-2026-27825 fix, which hardened download destinations but never constrained upload source paths; only confidentiality is affected (no write or availability impact), and exploitation is bounded to files readable by the server process. No public exploit identified at time of analysis, and the issue is fully resolved by upgrading to 0.22.0.
Path traversal in MCP Atlassian (mcp-atlassian) before 0.22.0 allows an MCP caller that already holds attachment-upload authorization to supply an absolute path or ../ sequence to upload_attachment, causing the server to read an arbitrary server-local file and exfiltrate it through a Jira or Confluence attachment upload. The flaw is authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) and confidentiality-only: the resolved path is never confined to the server workspace, but there is no write, code-execution, or availability impact through this specific issue. No KEV listing and no public exploit code were identified at time of analysis, and the practical risk is bounded by the requirement that the caller is already trusted to invoke attachment tooling - highest in shared-credential or multi-tenant MCP deployments where the caller should not have host filesystem visibility. The vendor-released fix is version 0.22.0.
Authorization-boundary bypass in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 lets an authorized MCP caller search Jira projects and Confluence spaces that fall outside the administrator-configured allowlist, by supplying caller-controlled projects_filter/spaces_filter arguments that replace the operator's restriction or by embedding an explicit project/space clause that suppresses it. Rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), exploitation requires an already-authorized MCP caller plus a shared Atlassian credential whose access extends beyond the allowlist; the result is read-only information exposure with no integrity or availability impact. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); vendor-released patch: 0.22.0.
Plaintext storage of Atlassian OAuth credentials in MCP Atlassian before 0.22.0 lets any local user or process that can read the persisted token file recover live access and refresh tokens and reuse them against Confluence and Jira. The vulnerable code path is OAuthConfig._save_tokens, which writes ~/.mcp-atlassian/oauth-<client_id>.json using process-default permissions; on a host with a permissive umask, same-group or other local accounts can read it. Exploitation requires a pre-existing local foothold, a permissive umask, and that the OAuth plaintext-fallback file was actually created - it is not remotely exploitable and is not exposed on single-user hosts with a restrictive umask; no public exploit code was identified at time of analysis and this CVE is not in CISA KEV.
Path traversal in the MCP Atlassian MCP server (all versions prior to 0.22.0) allows an authenticated MCP caller that is authorized to invoke the Jira or Confluence attachment-upload tools to read arbitrary files as the server process. The upload tools accept a caller-supplied file_path and, before the fix, only normalised it with os.path.abspath without confining it to a workspace, so any path readable by the server account - tokens, keys, configuration - can be packaged and exfiltrated to an Atlassian issue or page; CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects high confidentiality loss but no integrity or availability impact, and no public exploit code has been identified at time of analysis. The issue matters most in shared-credential or multi-tenant deployments, where a low-privilege caller gains read access far beyond its intended Atlassian scope.
Server-side request forgery in the MCP Atlassian MCP server (versions 0.17.0 through 0.21.x) allows remote unauthenticated attackers to force the server to make outbound requests to internal addresses such as the cloud metadata endpoint 169.254.169.254. The flaw is an incomplete-fix TOCTOU: validate_url_for_ssrf resolves and approves the attacker-supplied X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url host once at middleware time, but the actual HTTP client re-resolves the raw hostname at connect time with no IP pinning, so a DNS-rebinding name can pass validation with a public IP and then resolve to a link-local or RFC1918 address. Exploitation is a documented, publicly described proof-of-concept rather than confirmed in-the-wild activity (no CISA KEV listing), and the vendor has released version 0.22.0 as the fix.
Server-side request forgery in KS-GEN-AI jira-mcp-server 0.2.0 allows a local low-privileged attacker to make the server issue arbitrary HTTP requests by manipulating the imageUrl argument passed to axios.get within the add_attachment_from_public_url function. The CVSS 4.0 vector (AV:L/PR:L/E:P) confirms local access is required, low privileges suffice, and proof-of-concept code exists. No vendor patch has been released; the project maintainer had not responded to the responsible disclosure issue at time of analysis.
Draft release attachment disclosure in Gitea exposes files uploaded to draft releases to unauthenticated network callers via UUID-based web endpoints, bypassing access controls that correctly gate the parallel API handlers. This is an incomplete fix for CVE-2026-27660: that advisory's PR #36659 added `canAccessReleaseDraft` checks to every API code path but left the web-side `ServeAttachment` handler ungated, allowing anyone who obtains an attachment UUID to download its contents with no authentication. A working proof-of-concept is documented in the advisory and confirmed against Gitea v1.27.0+dev; no public exploit identified at time of analysis beyond the advisory PoC, and the vulnerability does not appear in CISA KEV.
Authorization bypass in Apache Camel's camel-jira component (versions 4.0.0 through pre-4.21.0) allows unauthenticated HTTP clients - in routes that bridge an HTTP consumer to a jira: producer - to drive arbitrary JIRA issue operations using the endpoint's configured service-account credentials, including deleting or transitioning issues, creating issues in unauthorized projects, modifying fields, and manipulating watchers. The root cause is that JIRA control header constants (IssueKey, ProjectKey, IssueTransitionId, linkType, and others) use non-Camel-prefixed string values, bypassing the HttpHeaderFilterStrategy which only guards the 'Camel/'/'camel' header namespace at the HTTP boundary. Fixes are confirmed in 4.14.8, 4.18.3, and 4.21.0; no public exploit has been identified at time of analysis, and this vulnerability is not listed in CISA KEV.
Missing authentication on the Atlassian Connect install callback in Mattermost allows a remote attacker to inject a rogue sharedSecret into an in-progress Jira integration setup. Affected versions span the 10.11.x, 11.5.x, 11.6.x, and 11.7.x release trains, all of which expose the POST /ac/installed endpoint without validating the caller's identity during the pending-install window. No public exploit has been identified at time of analysis, but a successful injection corrupts the integration's trust handshake, yielding high integrity and availability impact against the Jira connection. The vendor CVSS vector assigns PR:L, which conflicts with the description's 'remote unauthenticated attacker' language - this discrepancy warrants direct verification with Mattermost advisory MMSA-2026-00654.
Server-Side Request Forgery in GeoServer 2.26.x prior to 2.26.4 and 2.27.x prior to 2.27.3 allows unauthenticated remote attackers to coerce the server into issuing HTTP requests to attacker-chosen destinations by abusing weak prefix matching of the proxy base URL inside the XML entity resolver. No public exploit identified at time of analysis, and EPSS exploitation probability sits at 0.06% (19th percentile), but the trivial network-only attack vector and default-enabled ENTITY_RESOLUTION_ALLOWLIST since 2.25.0 raise the realistic exposure for internet-facing instances.
Arbitrary file write in GeoServer's Master Password Dump web page allows an authenticated administrator to write attacker-controlled content to any absolute filesystem path the GeoServer process can write to, including JSP files in a Tomcat webapps directory. Because GeoServer enforces no maximum master password length, an admin can embed malicious JSP code into the master password and dump it to an executable location, escalating to remote code execution on the host. No public exploit identified at time of analysis and the issue is not in CISA KEV.
Remote code execution in GeoServer (versions prior to 2.27.0) with the DB2 extension installed allows authenticated administrators to perform a JNDI injection attack via a crafted DB2 JDBC connection URL submitted through the Vector Data Sources page, ultimately triggering Java deserialization of untrusted data and arbitrary code execution. No public exploit identified at time of analysis, and the vulnerability is not on CISA KEV, but the attack pattern follows well-known JNDI/Log4Shell-style RCE techniques. Risk is meaningful only where the DB2 extension is deployed and an administrative account is reachable.
Path traversal in XWiki Platform's WebJars API enables a subwiki admin who can publish and install a malicious WebJar extension to write arbitrary files anywhere on the server filesystem. The affected Maven component `xwiki-platform-webjars-api` fails to validate that JAR entry paths extracted during extension installation remain within the intended export directory, allowing overwrite of configuration files or potential superadmin credential manipulation. No public exploit is identified and no CISA KEV listing exists; vendor-released patches are available across three version branches.
Cross-Site Request Forgery in GitLab CE/EE allows an unauthenticated attacker to create unauthorized Jira subscriptions within a targeted authenticated user's namespace by tricking the victim into clicking a specially crafted link. All GitLab installations from version 11.10 through the pre-patch 18.x releases are affected across both Community and Enterprise editions. No public exploit exists and this is not listed in CISA KEV; however, the broad version range spanning over seven years of releases and the prevalence of Jira integrations in enterprise GitLab deployments make patching a meaningful priority.
GitLab's Jira integration exposes out-of-scope Jira issues to authenticated GitLab users across all editions (CE and EE) from version 13.7 through the patched releases, due to the integration's project-scope filter operating only as a UI display control rather than an enforced access boundary. The Changed scope (S:C) in the CVSS vector reflects that impact crosses into Atlassian Jira - a component outside GitLab's own trust domain - allowing confidential Jira issue data to leak beyond intended project boundaries. No public exploit exists and no active exploitation has been confirmed; EPSS is negligible at 0.01% (3rd percentile), placing this firmly in low-exploitation-probability territory despite a broad version range spanning over five years of releases.
Incorrect authorization in Mattermost Server lets any authenticated user forge a '/share-issue-publicly' post action, so that when a victim user interacts with the crafted post, Jira ticket content the victim is authorized to see is relayed to the attacker. Affected lines are 10.11.x through 10.11.7, 10.12.x through 10.12.3, 11.0.x through 11.0.5, and 11.1.x through 11.1.0, and exploitation requires the Jira plugin to be installed, an account able to post into a channel the victim reads, and victim interaction (CVSS 3.1 4.1, AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N). No public exploit code and no confirmed active exploitation were identified at time of analysis, and the exposure is limited to Jira ticket data rather than server compromise.
Mattermost Server versions 10.11.x through 11.1.0 contain an authorization bypass in the Jira plugin's post-to-comment feature that lets an authenticated user read posts and attachments from channels they are not allowed to access. Exploitation requires a valid Mattermost account and an enabled/configured Jira integration where posts can be attached as Jira comments, with impact limited to confidentiality of exposed post content; no public exploit identified at time of analysis. The CVSS 3.1 score of 4.3 reflects a moderate issue rather than a high-severity breach.
Improper authentication enforcement in the Mattermost Jira plugin lets an unauthenticated attacker who knows a valid Mattermost user ID send crafted plugin payloads that spoof that user and inject arbitrary Jira issue-key paths, causing the plugin to issue authenticated GET and POST requests to the connected Jira server. The flaw affects Mattermost Server 11.1.x through 11.1.0, 11.0.x through 11.0.5, 10.12.x through 10.12.3, and 10.11.x through 10.11.7, but only when the Jira plugin (versions <= 4.4.0) is installed, enabled, and connected to Jira; default installations without the Jira integration are not exposed. Per the CVSS vector the attack is unauthenticated and needs no user interaction, and the decisive practical barrier is that the attacker must possess or guess a usable Mattermost user ID. No confirmed active exploitation has been reported (not in CISA KEV) and no public exploit code has been identified; EPSS is low at 0.26% (17th percentile), so this is a mid-tier priority rather than an emergency. Mattermost Advisory ID: MMSA-2025-00555.
Broken access control in Cervantes's JiraController allows any authenticated user to create, edit, or delete Jira tickets belonging to other projects, breaking project-level isolation in the tool's Jira integration. All releases from alpha 0.3 through v1.3-beta are affected (tracked by CPE cpe:2.3:a:cervantessec:cervantes), and successful abuse yields high integrity impact with limited confidentiality impact across the shared Jira workspace. Exploitation requires a valid low-privileged account (CVSS PR:L) and Jira integration must be in use; no public exploit code has been identified at time of analysis, and the issue is not in CISA KEV, though the vendor has published a fix and the aggregate decision label places remediation in the current week.
Path traversal in Backstage's optional @backstage/plugin-scaffolder-backend-module-confluence-to-markdown package (versions before 0.3.25) allows an authenticated user who can execute a template using the confluence:transform:markdown action and control the repository file location to write generated content outside the task workspace, potentially overwriting files writable by the Backstage backend process. The vulnerability is rated CVSS 7.1 with high integrity and low availability impact but no confidentiality impact; exploitation requires the module to be installed and enabled, and the attacker must supply directory-traversal sequences in the repoUrl input. The issue is fixed in version 0.3.25 (Backstage release v1.54.6), and no public exploit has been identified at time of analysis.
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote caller to read any file accessible to the MCP process and have it uploaded to an attacker-controlled endpoint. The issue affects only deployments running the HTTP transports (streamable-http or sse) with READ_ONLY_MODE=false, where a request that carries X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token but no Authorization header is accepted as a 'pat' identity, so the attacker-chosen Atlassian URL is used to build the attachment client and the confluence_upload_attachment (or Jira attachment) tool accepts an arbitrary server-side file_path. CVSS 3.1 rates it 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact, a public Docker-based proof of concept was confirmed by the reporter so publicly available exploit code exists, and EPSS is low at 0.30% (23rd percentile) with no confirmed actively exploited (CISA KEV) status; version 0.22.0 fixes the flaw.
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network caller abuse the streamable HTTP transport, which accepts requests carrying no user identity and silently falls back to the operator's global Atlassian credentials, to force the upload_attachment tool to read any file readable by the MCP process and push its contents into an attacker-chosen Jira issue or Confluence page, where the attacker can retrieve them. Exploitation requires the server to be running the streamable HTTP transport, reachable by the attacker, and configured with shared operator credentials - stdio-only deployments and deployments that enforce per-user identity/tokens are not exposed - and impact is confidentiality-only (file exfiltration), with no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the underlying issue is a path-traversal flaw (CWE-22) fixed in version 0.22.0, and the practical risk is bounded more by who actually deploys this MCP server over the network than by exploit maturity.
MCP Atlassian servers before 0.22.0 write their plaintext OAuth fallback token file using permissions inherited from the process umask, so on a shared host with a permissive or default umask another local account can read the file and reuse the stored refresh and access tokens for Atlassian (Confluence/Jira) access. The flaw is a local, multi-user exposure rather than a remote one: the attacker must already hold a separate account on the same machine and the deployment must actually use the plaintext fallback storage path, which is why the independent assessment scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N instead of the vendor's AV:N rating. Because the leaked refresh token keeps working even after access-token rotation, credential rotation alone does not close the exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in the vendor-released version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an accepted MCP caller to read arbitrary files from the host on which the server runs: the confluence_upload_attachment tool opens a caller-supplied file_path after only converting it with os.path.abspath, with no check that the resolved path stays inside the workspace, and then uploads the contents as a Confluence attachment the caller can download back. The vulnerability is an access-gated, confused-deputy arbitrary-file-read (CWE-22, assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, no integrity or availability impact); exploitation requires an authenticated MCP caller (PR:L), a server older than 0.22.0 configured with Confluence credentials that can write attachments, and a space the attacker can read back - single-user local stdio deployments where the caller already owns the host gain nothing. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in version 0.22.0.
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to 0.22.0, where the Jira update_issue tool converts a caller-supplied attachments argument into local filesystem paths and passes them to the attachment upload implementation without any workspace confinement. A caller able to invoke the update_issue tool can therefore use the server as a confused deputy, reading arbitrary files (e.g. credentials, config, SSH keys) readable by the server process and attaching their contents to a Jira issue the caller controls, with confidentiality impact only - no write or code execution through this flaw. Exploitation is access-gated: the vendor rates it AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6), while our independent assessment scores it PR:L/S:U, since a permitted MCP caller and a shared-credential deployment are realistic prerequisites; no public exploit code has been identified at time of analysis.
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read arbitrary files readable by the server's OS user and exfiltrate them by pushing them to Confluence as attachments. The upload code path converts a caller-supplied file_path to an absolute path without the workspace confinement that had already been added to the download path (CVE-2026-27825), so relative or absolute traversal sequences escape the intended workspace. The independent assessment scores the flaw CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only, no integrity or availability impact), requiring an authenticated caller with access to the MCP tool; the vendor's advisory scored it 8.6 with PR:N and S:C. No public exploit identified at time of analysis, and instances at 0.22.0 or later are not affected.
Unauthenticated network callers can drive Jira and Confluence tool handlers using an operator's globally configured credentials in sooperset/mcp-atlassian prior to 0.22.0, when the server is run over the HTTP streamable-http transport without an independent authentication boundary. The root cause is a missing-authentication flaw (CWE-306) scored CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), giving remote, unauthenticated, low-complexity read and write access with the permissions of the configured service account and no availability impact. Exploitation is configuration-dependent - stdio deployments and instances fronted by an authenticating proxy or enforcing per-user OAuth identities are not exposed - and no public exploit or CISA KEV listing was identified at time of analysis. The issue is fixed in version 0.22.0.
MCP Atlassian server versions prior to 0.22.0 allow an authenticated MCP caller to read arbitrary files from the server host by supplying an absolute or traversal path to the file_path argument of the jira_upload_attachment or confluence_upload_attachment tools, whose bytes are then uploaded into Atlassian and can be read back by the same caller. Exploitation is conditional: it requires the server to be deployed in HTTP or multi-user mode (not single-user stdio), a permitted caller able to invoke the upload tools (CVSS PR:L), and shared operator credentials so the exfiltrated content lands where the attacker can retrieve it; impact is confidentiality-focused (C:H) with limited integrity effect (I:L) and no availability impact. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), though EPSS context was not provided; the vendor-released fix is version 0.22.0.
Arbitrary local file read in MCP Atlassian (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP caller who can reach the Jira or Confluence upload_attachment tool over the HTTP-exposed 'streamable-http' transport to supply a traversal or absolute file_path that is not confined to the workspace, causing the server process to read sensitive local files and exfiltrate them as Atlassian attachments. The vendor rates this 8.3 (CVSS 4.0) with PR:L, high confidentiality impact and no integrity or availability impact, consistent with our independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. Exploitation is limited by prerequisites: working Atlassian upload credentials and tool access must already be held, the HTTP transport must be exposed rather than stdio-only, and reachable data is bounded to files readable by the server process user; no public exploit code was identified at time of analysis and the issue is not listed in CISA KEV.
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised the configured Atlassian backend return a 3xx redirect pointing at an internal address (for example the 169.254.169.254 cloud metadata service), which the MCP server's HTTP session then follows - potentially returning cloud IAM credentials or other internal service data to the attacker. Only deployments configured through the basic-auth or oauth_pat branches are exposed, because those fetcher sessions fail to attach the _make_ssrf_safe_hook redirect validator that the header-PAT branch sets via attach_ssrf_hook=True; header-PAT deployments are not affected. Publicly available exploit code exists (no CISA KEV listing, so no confirmed active exploitation), the vendor fix ships in 0.22.0, and EPSS remains low at 0.32% (26th percentile) with the assessed vector requiring high attack complexity and a malicious upstream prerequisite.
Arbitrary server-local file read and exfiltration in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, low-privileged MCP caller abuse the upload_attachment tool for Confluence or Jira to read files on the server host via a caller-supplied file_path, then retrieve the pages' contents as a normal attachment. The vulnerability is CWE-22 (path traversal): the pre-0.22.0 code only normalized the path with os.path.abspath and performed no workspace confinement, so absolute paths and traversal sequences that escape the working directory are accepted. Impact is confidentiality-only (no write or code execution) and exploitation is conditionally gated - it matters primarily in shared-credential or multi-tenant deployments where a caller's legitimate upload capability exceeds its intended file-read scope; single-user, locally trusted deployments face negligible additional exposure. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the vendor fix is available in version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a low-privileged authenticated MCP caller write attacker-chosen files into the server's working directory, because validate_safe_path defaults its base directory to os.getcwd() and the Confluence attachment call sites omit base_dir. Overwriting an importable Python module in that location can escalate to code execution once the application imports the modified module, and the vector intentionally bypasses the earlier remediation tracked as CVE-2026-27825. Exploitation requires permitted MCP tool access (CVSS vector shows PR:L, i.e. authenticated with low privileges) and a subsequent import or re-import of the overwritten module, so code execution is not immediate; no public exploit code has been identified at time of analysis and there is no CISA KEV entry. The vendor rates this 8.3, while an independent assessment confirms it is a genuine remote-exploitable code-execution path whose real-world priority is moderated by those preconditions.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 allows unauthenticated callers to reach internal or cloud metadata endpoints by exploiting a DNS-rebinding race, because the server validates a hostname's resolved IP and then lets Requests/urllib3 resolve that same hostname again at connection time. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N (7.5): no authentication is needed, but the attacker must control authoritative DNS for a low-TTL name that answers publicly during validation and privately during connection, and the server must actually be able to reach a valuable internal target for the attack to pay off. This is a bypass of the earlier CVE-2026-27826 hardening rather than a new class of bug, no public exploit code or confirmed active exploitation was identified at time of analysis, and environments already running 0.22.0 or with no reachable internal/metadata endpoints are not exploitable.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 applies its ENABLED_TOOLS and TOOLSETS least-privilege filters only when tools are enumerated via tools/list, and never re-checks them when a request is dispatched through tools/call. An authenticated, low-privileged MCP client that knows or guesses the exact name of an excluded tool can therefore invoke read, write, and delete operations against Confluence and Jira that the operator deliberately hid, yielding full confidentiality, integrity, and availability impact against Atlassian data (CVSS 3.1 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, CWE-862 Missing Authorization). The flaw is meaningful only where the toolset configuration is the trust boundary - the highest risk is in shared-credential or multi-tenant deployments - and no public exploit code was identified at time of analysis. A vendor-released patch is available in version 0.22.0.
Information disclosure in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an authenticated caller of the MCP server to read Jira issues, agile boards, and Confluence pages that the operator intended to exclude via JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER, because the Jira search path only checks whether a project clause is present rather than whether it is permitted, the Confluence search path applies an incomplete case-sensitive space check (and lets a caller-supplied spaces_filter replace rather than narrow the configured allowlist), and the Jira board APIs (get_board_issues, get_agile_boards) omit project-filter enforcement entirely. The flaw requires low privileges (an accepted MCP client) and no user interaction, but it only yields data beyond the intended scope when the server's shared operator credentials hold broader Atlassian access than the configured filter - the typical shared-credential, delegated, or multi-tenant MCP deployment. There is no confirmed active exploitation and no public exploit identified at time of analysis; the issue is fixed in 0.22.0, and an independent assessment rates it a moderate-priority filter-bypass/authorization control failure rather than a top-tier emergency.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticated caller to force the MCP server to send requests to an arbitrary destination of the attacker's choosing by supplying the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers, which are consumed by _process_authentication_headers without passing through validate_url_for_ssrf. A successful attack redirects the server's Atlassian fetchers at internal services or cloud metadata endpoints, leaking response data back to the caller (scope-changing, high confidentiality impact, no integrity or availability impact per the assessed vector); no public exploit code was identified at time of analysis and EPSS data was not supplied. The defect is an incomplete remediation of the earlier SSRF CVE-2026-27826, and the project shipped a fix in version 0.22.0.
Unauthenticated network clients that can reach an mcp-atlassian server running in HTTP (streamable-http) transport mode can invoke Atlassian tools using the operator's globally configured Jira or Confluence credentials, inheriting that account's read and write access to both products. The flaw is an authentication deficiency (CWE-287) in which the request path through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, and _get_fetcher accepts a request without a verified user identity and falls back to the shared, operator-scoped credential set; exploitation requires no authentication (PR:N), user interaction, or special privilege once the endpoint is reachable, which is why the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N (10.0). Exposure is limited to the shared-credential/multi-tenant deployment pattern - stdio-transport installs and per-user token deployments that never fall back to global credentials are not affected - and at the time of analysis no public exploit code had been identified and the issue was not confirmed actively exploited (CISA KEV).
Server-side request forgery in MCP Atlassian (sooperset) versions before 0.22.0 lets unauthenticated callers drive the server into issuing HTTP requests to internal or cloud-metadata addresses by exploiting a DNS-rebinding race in the header-based authentication flow. Only deployments on the header_pat branch, which trust caller-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers, are exposed; the URL is validated for SSRF once and then re-resolved by the HTTP client at connection time, so a low-TTL attacker-controlled hostname can return a public IP during validation and 127.0.0.1 or 169.254.169.254 during the actual request, with roughly 50 percent success per attempt. Publicly available exploit code exists (a DNS-rebinding proof of concept using rbndr.us), EPSS is low at 0.42 percent (36th percentile), there is no KEV listing indicating confirmed actively exploited (CISA KEV) status, and the vendor-released patch is version 0.22.0.
Arbitrary server-local file disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an authenticated, permitted Confluence MCP caller read any file accessible to the server process by passing a traversal or absolute path to the upload_attachment tool and receiving the contents back as a published attachment. Exploitation requires only a valid MCP caller session (no user interaction, low privileges per PR:L), and the scope change in the CVSS vector reflects the server process acting as a confused deputy on behalf of the caller, yielding high confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no CISA KEV listing; the practical risk is highest in shared-credential or multi-tenant MCP deployments where the caller is less privileged than the server process, and is low in single-user deployments where the caller already owns the underlying filesystem. Vendor-released patch: 0.22.0.
Server-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0 allows remote, unauthenticated attackers to make the server issue HTTP requests to internal or otherwise protected network resources. The flaw lives in validate_url_for_ssrf, which parses a URL's authority differently from the Requests connection layer when the server runs the header-based Jira/Confluence URL authentication flow, so a crafted backslash-containing URL can pass validation as an external hostname while the HTTP client actually connects to an internal host. Exploitation is limited to deployments that accept client-supplied Atlassian base URLs, requires the attacker to win the parser-versus-connection-layer discrepancy reliably, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Stored cross-site scripting in GoCD's Compare Pipeline page affects versions 18.3.0 through 25.x and allows an attacker holding commit access to a tracked material to inject URI or HTML special characters into a commit comment that GoCD later renders as an unescaped tracking-tool link. Successful exploitation within a victim's browser session can expose a privileged user's session or permit changes performed with that victim's credentials and privileges, though the CVSS 4.0 vector (AC:H/AT:P/PR:L/UI:P) and the layered prerequisites make this a non-trivial, non-drive-by issue. The flaw is fixed in GoCD 26.1.0, and no public exploit has been identified at time of analysis.
Authenticated denial of service in Atlassian Confluence Data Center allows a low-privileged logged-in user to make the application unavailable to its intended users, with no confidentiality or integrity impact. The flaw was introduced across a broad swath of releases (8.9.0 through 10.2.0) and Atlassian rates it High with a CVSS 4.0 score of 7.1. Fixed builds are 9.2.24 and later on the 9.2 branch and 10.2.17 and later on the 10.2 branch; no public exploit code or confirmed active exploitation was identified at time of analysis.
Improper authorization in Atlassian Jira Service Management Data Center 11.3.0 through 11.3.10 lets an authenticated, low-privileged attacker reach functionality and data they should not be able to access, with the vendor scoring it 7.1 in CVSS 4.0 (AV:N/AC:L/PR:L/UI:N/VI:H). Atlassian states the flaw was discovered through its own penetration-testing program and that the impact could extend from exposure of sensitive resources to arbitrary code execution, though the published CVSS 4.0 vector only credits a high integrity impact and rates confidentiality and availability as none. No CISA KEV listing, EPSS score, or public exploit code was provided in the source data, so at time of analysis this should be treated as a confirmed but not yet observed-in-the-wild authorization bypass; patched versions (11.3.11 and later) are already available.
An improper authorization flaw in Atlassian Confluence Data Center lets an authenticated, low-privileged user reach resources and functionality they should not be able to access, resulting in high confidentiality impact against the affected instance. The defect was introduced across a broad set of release trains — 7.4.0, 7.13.0, 8.5.0, 8.9.0, 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 — meaning most currently maintained Data Center deployments built on those lines are exposed until upgraded. Atlassian rates the issue 7.1 (CVSS 4.0, AV:N/AC:L/PR:L/UI:N/VC:H) and has shipped fixes in 9.2.24 and 10.2.17; there is no evidence of public exploit code or confirmed active exploitation at time of analysis.
MCP Atlassian, the Model Context Protocol server that bridges AI clients to Confluence and Jira, resolves client-supplied attachment paths on the server itself, so a remote client with write-tool access can read arbitrary files from the server host in versions before 0.22.0. The confluence_upload_attachment, confluence_upload_attachments and jira_update_issue tools all funnel an unconfined file_path into os.path.abspath() plus open(), and the resulting bytes are uploaded to Atlassian as an attachment — giving the attacker a convenient exfiltration channel for server files, environment-held Atlassian credentials, or other tenants' data. The vendor advisory includes a working proof-of-concept (publicly available exploit code exists), but no active exploitation is confirmed (no CISA KEV listing); the CVSS 3.1 score is 7.7 with EPSS not provided in the input. Only local single-user stdio deployments are outside the trust boundary.
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constraints when neither jwtIssuer nor jwtAudience is configured, causing the embedded Vert.x HTTP server to accept any unexpired token signed by any key in the trusted keystore. Affected are Apache Camel versions 4.8.0 through 4.21.x across both the application server and management server paths. An attacker who possesses a valid JWT from any identity provider trusted by the configured keystore - such as a token legitimately issued for a different service in a shared IdP environment - can authenticate to the Camel HTTP endpoints without holding credentials intended for that service. No public exploit has been identified at time of analysis, and CISA KEV listing is absent.
Improper authorization in Atlassian Bamboo Data Center across six affected release lines (10.0.x through 12.1.x) enables authenticated low-privilege users to bypass access controls and reach restricted resources or functionality, with Atlassian tagging the flaw as carrying arbitrary code execution risk. The vulnerability was discovered through Atlassian's own penetration testing program and affects Data Center deployments only - not Bamboo Cloud. No public exploit code or CISA KEV listing exists at time of analysis, but the high confidentiality and integrity impact ratings (VC:H/VI:H in CVSS 4.0) and the RCE tag make this a credible escalation risk in any environment where untrusted or lightly-privileged users hold Bamboo accounts.
Broken authentication in Atlassian Crowd Data Center 7.2.1 permits a remote, unauthenticated attacker to perform actions on behalf of any other user, effectively bypassing the platform's identity and session controls. The flaw was introduced specifically in version 7.2.1, discovered through Atlassian's Penetration Testing program, and carries a CVSS 4.0 score of 8.8 with scope-changing impact that cascades to all downstream SSO-federated applications. No active exploitation (CISA KEV) and no public exploit code have been identified at time of analysis, though the cross-system propagation potential demands urgent patching.
Stored cross-site scripting combined with privilege escalation in Confluence Data Center and Server lets an unauthenticated attacker persist malicious HTML/JavaScript that runs in a victim's browser, enabling actions performed as a higher-privileged user and abuse of insecure default configurations. Atlassian rates it Critical (vendor CVSS 4.0 score 9.3; the advisory body text separately cites 8.6), and it affects a long list of 7.x through 10.2.x branches. There is no public exploit identified at time of analysis and it is not on CISA KEV; it was found through Atlassian's bug bounty program.
Arbitrary file read via path traversal in mcp-atlassian prior to 0.22.0 allows any authenticated MCP client to supply an absolute or traversal path to the confluence_upload_attachment tool, causing the server to open and exfiltrate the targeted file as a Confluence attachment. On Linux deployments, /proc/self/environ exposes live API credentials including CONFLUENCE_API_TOKEN, AWS keys, and database passwords, enabling full Atlassian account takeover and lateral movement. A confirmed prompt injection attack chain means threat actors who can write content an AI agent will read - such as a malicious Jira ticket - can trigger the same credential exfiltration with zero MCP credentials; publicly available exploit code and a demonstration video exist.
SSRF protection bypass in Flowise (npm/flowise ≤ v3.1.2) allows complete circumvention of all IPv4 CIDR deny rules via IPv4-mapped IPv6 addresses, rendering the SSRF fix introduced in v3.0.13 for CVE-2026-31829 entirely ineffective. An attacker who controls DNS for a hostname referenced in a Flowise chatflow HTTP component can set a AAAA record to `::ffff:169.254.169.254` or any RFC1918 target; Flowise resolves the address, the `isDeniedIP()` kind mismatch silently skips all IPv4 CIDR checks, and the request reaches cloud IMDS endpoints or internal services. A publicly available proof-of-concept script (poc_ssrf_bypass.js) confirms the bypass against ipaddr.js@2.2.0; no CISA KEV listing has been identified at time of analysis.
Credential exfiltration in swagger-typescript-api (npm, versions <= 13.12.1) allows a malicious OpenAPI spec to steal a developer's bearer token during code generation: when `--authorizationToken` is set, the generator attaches that token to the Authorization header of every request it makes while resolving external `$ref` URLs, with no same-origin check, so a `$ref` pointing at an attacker-controlled host receives the token verbatim. The stolen credential is typically high-value (GitHub PAT, OAuth bearer, CI service-account token) and its capture is equivalent to full account/scope takeover. A working proof-of-concept was supplied by the reporter (publicly available exploit code exists); it is not listed in CISA KEV and there is no evidence of active exploitation.
Remote code execution in Atlassian Sourcetree for Mac and Windows 3.4.11-3.4.12 enables an authenticated attacker to execute arbitrary code on a victim's machine via code injection (CWE-94), achieving full confidentiality, integrity, and availability compromise. The attack requires low-privilege authentication and user interaction - consistent with a scenario where a victim opens or processes attacker-controlled repository content within the application. No public exploit identified at time of analysis; EPSS at 0.30% (22nd percentile) reflects low current exploitation probability, and the vulnerability was responsibly disclosed through Atlassian's Bug Bounty program rather than discovered in active exploitation.
Denial of service in Atlassian Confluence Data Center allows an authenticated attacker to render the application unavailable to legitimate users by triggering resource exhaustion that disrupts the host's services. Affected releases span the 9.0.x through 10.2.x branches, with a CVSS 4.0 score of 7.1 (High) driven entirely by availability impact. No public exploit has been identified at time of analysis; the flaw was discovered internally via Atlassian's penetration testing program rather than through in-the-wild activity.
Information disclosure in Atlassian Confluence Data Center allows an unauthenticated remote attacker to read sensitive information from affected instances, carrying a CVSS 4.0 score of 8.2 (High). The flaw was introduced across a wide span of releases (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, 10.2.0) and was found internally by Atlassian. No public exploit identified at time of analysis and it is not listed in CISA KEV, but the network-reachable, unauthenticated nature makes patching a priority for internet-facing deployments.
Path traversal in XWiki running on Jetty 12+ lets remote users read arbitrary files the Jetty process can access by sending doubly URL-encoded '../' sequences to the skin resource endpoint (e.g. /xwiki/bin/skin/..%252f/..). Depending on how deep the webapp sits below root, this exposes both in-webapp secrets such as WEB-INF/xwiki.cfg and Hibernate configuration, and out-of-webapp OS files like /etc/passwd. No public exploit or active exploitation is tracked, but the vendor advisory (GHSA-qj4x-9g63-25g6) itself publishes working request URLs, so weaponization is trivial.
Remote code execution in XWiki Pro Macros (com.xwiki.pro:xwiki-pro-macros) versions >=1.13 and <1.14.5 allows any authenticated user with page-edit rights to execute arbitrary Groovy code via the excerpt-include macro, which fails to escape the included page's title and renders excerpt content with the macro's elevated rights. A working proof-of-concept is published in the GHSA advisory demonstrating injection through both a crafted page title and excerpt body. No public exploit identified at time of analysis as actively used, but the publicly available exploit code exists in the advisory itself.
Two-factor authentication bypass in syracom AG Secure Login (2FA) plugin 3.4.0.x for Atlassian Jira, Confluence, and Bitbucket allows an attacker holding valid first-factor credentials to skip the 2FA challenge entirely by injecting strings like 'AtlassianMobileApp' or 'JIRA' into the HTTP User-Agent header. The plugin treats such requests as mobile-app traffic and waives 2FA enforcement on protected web resources, effectively neutralizing the security control the plugin exists to provide. No public exploit identified at time of analysis, but the technique is trivial to reproduce from the public advisory text.
Information disclosure in XWiki Platform's LiveTableResults macro allows unauthenticated remote attackers to reconstruct user password hashes and salts one bit at a time by sending approximately 768 crafted requests with manipulated class-per-property parameters. This is a bypass of the prior fix for GHSA-5cf8-vrr8-8hjm, which failed to account for an alternate parameter path. No public exploit is identified at time of analysis, but the technique is fully described in the vendor advisory.
Authentication bypass in Microsoft's SAML SSO plugins for Atlassian Jira (versions 1.0.0 through 1.3.2) and Confluence (versions 1.0.0 through 7.3.x) allows a remote, unauthenticated attacker to impersonate other users and elevate privileges over the network due to an incorrectly implemented authentication algorithm. Rated CVSS 9.1 with full confidentiality and integrity impact, the flaw is deemed automatable with total technical impact by CISA's SSVC framework, though EPSS remains low (0.12%) and no public exploit has been identified at time of analysis. A vendor patch is available.
Server-side request forgery combined with missing authentication in firefighter-incident Python package allows unauthenticated remote attackers to exfiltrate AWS IAM credentials from cloud metadata endpoints. The `/api/v2/firefighter/raid/jira_bot` endpoint accepts arbitrary URLs in the `attachments` parameter, fetches them server-side without validation, and uploads responses as Jira attachments — enabling SSRF against internal services including `http://169.254.169.254/` (AWS EC2 Instance Metadata Service). Vendor-released patch (version 0.0.54) enforces authentication and validates attachment URLs to block private/link-local/loopback addresses. No public exploit identified at time of analysis, but exploitation is trivial given detailed advisory with exact vulnerable code paths.
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoStream-based remote aggregation repository reads objects from an Infinispan cache using java.io.ObjectInputStream with no ObjectInputFilter applied. Any attacker able to write to the backing Infinispan cache can plant a malicious serialized gadget that executes in the application context during routine get/recover operations. Publicly available exploit code exists, though EPSS is low (0.08%) and there is no evidence of active exploitation.
Remote code execution in Atlassian Bamboo Data Center versions 9.6.0 through 12.1.0 allows authenticated attackers to execute arbitrary OS commands via command injection vulnerability. The attack requires low-privilege authentication (PR:L) but no user interaction, enabling complete system compromise across confidentiality, integrity, and availability with cross-scope impact (SC:H/SI:H/SA:H indicating container escape or lateral movement potential). Atlassian has released patches for three major version branches (9.6.25, 10.2.18, 12.1.6). No active exploitation confirmed in CISA KEV at time of analysis, though the authenticated nature and critical CVSS 9.4 score warrant immediate patching for internet-exposed instances with broad user access.
Improper authorization in GitLab CE/EE Jira Connect integration allows authenticated users with minimal workspace permissions to steal installation credentials and impersonate the GitLab application. Affects versions 14.3 through 18.8.6, 18.9.0-18.9.2, and 18.10.0. Vendor-released patches available in versions 18.8.7, 18.9.3, and 18.10.1. High CVSS score (8.1) reflects significant confidentiality and integrity impact with low attack complexity. No public exploit identified at time of analysis, though detailed disclosure exists via HackerOne report.
Remote code execution in Atlassian Bamboo Data Center versions 9.6.0 through 12.1.0 allows authenticated attackers with high privileges to execute arbitrary code on affected systems with a CVSS score of 8.6. The vulnerability impacts multiple major versions with no patch currently available, requiring immediate upgrade to patched releases such as 9.6.24, 10.2.16, or 12.1.3. Organizations unable to upgrade should prioritize access controls for high-privileged accounts until remediation is possible.
LibreChat versions 0.8.2 through 0.8.2-rc3 contain an authentication bypass vulnerability in the Model Context Protocol (MCP) OAuth callback endpoint that allows attackers to steal OAuth tokens by tricking victims into completing an OAuth flow, resulting in account takeover of the victim's MCP-linked services like Atlassian and Outlook. No active exploitation is known (not in KEV), no POC is publicly available, and EPSS data is not yet available for this newly disclosed vulnerability.
MCP Atlassian server has a path traversal vulnerability enabling unauthorized access to Confluence and Jira data outside the intended scope.
Unauthenticated attackers can abuse the MCP Atlassian server to perform arbitrary outbound HTTP requests by manipulating HTTP headers, enabling credential theft from cloud instance metadata endpoints or internal network reconnaissance without requiring authentication. The vulnerability exists in the HTTP middleware layer prior to version 0.17.0, affecting Atlassian Confluence and Jira deployments. No patch is currently available.
XXE injection in Atlassian Crowd Data Center and Server 7.1.0+ enables authenticated attackers to read local and remote files, significantly compromising confidentiality and availability. The vulnerability requires high privileges to exploit but accepts no user interaction, affecting multiple Crowd versions until patching to 7.1.3 or later. No patch is currently available for all affected versions.
This High severity RCE (Remote Code Execution) vulnerability was introduced in version 5.2 of Confluence Data Center and Server. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
All versions of Confluence Data Center and Server are affected by this unexploited vulnerability. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Atlassian has been made aware of an issue reported by a handful of customers where external attackers may have exploited a previously unknown vulnerability in publicly accessible Confluence Data. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Actively exploited in the wild (cisa kev) and public exploit code available.
There is a command injection vulnerability using environment variables in Bitbucket Server and Data Center. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Multiple API endpoints in Atlassian Bitbucket Server and Data Center 7.0.0 before version 7.6.17, from version 7.7.0 before version 7.17.10, from version 7.18.0 before version 7.21.4, from version. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
The Atlassian Questions For Confluence app for Confluence Server and Data Center creates a Confluence user account in the confluence-users group with the username disabledsystemuser and a hardcoded. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Use of Hard-coded Credentials vulnerability could allow attackers to gain access using credentials embedded in source code.
In affected versions of Confluence Server and Data Center, an OGNL injection vulnerability exists that would allow an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Affected versions of Atlassian Jira Server and Data Center allow remote attackers to read particular files via a path traversal vulnerability in the /WEB-INF/web.xml endpoint. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Affected versions of Atlassian Confluence Server allow remote attackers to view restricted resources via a Pre-Authorization Arbitrary File Read vulnerability in the /s/ endpoint. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
There was a server-side template injection vulnerability in Jira Server and Data Center, in the ContactAdministrators and the SendBulkMail actions. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Atlassian Crowd and Crowd Data Center had the pdkinstall development plugin incorrectly enabled in release builds. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Confluence Server and Data Center had a path traversal vulnerability in the downloadallattachments resource. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
The HipChat for JIRA plugin before 6.30.0 for Atlassian JIRA allows remote authenticated users to execute arbitrary Java code via unspecified vectors, related to "Velocity Template Injection. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and EPSS exploitation probability 82.5%.
Directory traversal vulnerability in the Issue Collector plugin in Atlassian JIRA before 6.0.4 allows remote attackers to create arbitrary files via unspecified vectors. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable. Public exploit code available and EPSS exploitation probability 65.8%.
Path traversal in the Backstage Confluence-to-Markdown scaffolder module can let an authenticated Backstage user who runs a template with attacker-influenced Confluence content cause file writes outside the intended image directory, affecting integrity and potentially availability of the scaffolder workspace. The vulnerable package is @backstage/plugin-scaffolder-backend-module-confluence-to-markdown before 0.3.25; exploitation requires the optional module to be deployed and wired into a template, plus an attacker able to create or modify Confluence attachment metadata. There is no public exploit identified at time of analysis, and the issue is fixed in version 0.3.25 and Backstage release v1.54.6.
Server-side request forgery in DevaslanPHP project-management affects versions 1.2.1 through 1.2.4 and v2.0.0-beta1 and allows an authenticated, low-privileged user to make the application issue requests to attacker-chosen destinations. The flaw sits in the updateJiraProjects function of the /jira-import endpoint, where host, username and token parameters are accepted without an adequate authorization check (per the independent assessment, a missing canAccess check), so any user who can reach the Jira Import feature can force outbound connections from the server while only obtaining limited read/write effect. Publicly available exploit code exists (also reflected by the E:P metric in the vendor-supplied CVSS 4.0 vector), but there is no indication of confirmed active exploitation, and the vendor was contacted early and did not respond. This is a genuine but low-priority issue: the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, i.e. partial confidentiality and integrity impact only, gated behind authenticated access to the import feature.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an MCP caller who controls the public Jira base URL have a Jira user-lookup request redirected to an internal address, bypassing the SSRF redirect protections previously added for CVE-2026-27826. The vulnerable path is JiraUserMixin._lookup_user_by_permissions, which calls the module-level requests.get instead of the fetcher's protected session, so the response hook that enforces redirect validation is never applied. Impact is limited and blind (confidentiality-only, no integrity or availability effect) and, per the independent assessment, requires the attacker to control the Jira endpoint plus a server that issues a redirect to an internal target, making it most realistic in HTTP/multi-user or shared-credential deployments rather than single-user stdio setups with a fixed trusted Jira URL. No public exploit code was identified at time of analysis and there is no KEV listing; v0.22.0 resolves the issue.
Local credential disclosure in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 allows a co-resident local user or process to read stored Atlassian OAuth access and refresh tokens and reuse the associated Atlassian session. The server creates its ~/.mcp-atlassian directory and the oauth-<client_id>.json token file without explicit owner-only permission modes (CWE-732), so the resulting group- or world-readable bits - an artifact of a permissive process umask - expose the tokens to anyone with read access on the host; the CVSS vector (AV:L/PR:L) confirms this requires an existing local account and no network reachability. Only multi-user or multi-process hosts that rely on the OAuth token-file fallback are exposed; single-user hosts with a restrictive umask are not. No public exploit identified at time of analysis, and the vendor CVSS of 5.5 understates impact only marginally - the independent assessment adds a low integrity component (I:L) because a stolen refresh token can also be used to act within the victim's Atlassian tenant. The issue is fixed in version 0.22.0.
Reflected cross-site scripting in MCP Atlassian versions prior to 0.22.0 lets unauthenticated remote attackers inject markup or script through the OAuth error query parameter, which the CallbackHandler._send_response method in oauth_setup.py interpolates into an HTML page without escaping (CWE-79). Exploitation requires a deployment that uses the interactive OAuth setup flow and a targeted user who is actively completing that flow and opens the attacker's crafted authorization callback, which is why the assessed impact is confined to the victim's browser context (CVSS 5.4, C:L/I:L, UI:R) with no server-side code execution or Atlassian data-plane access. No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in version 0.22.0.
Authenticated path traversal in MCP Atlassian (mcp-atlassian) prior to 0.22.0 lets a permitted MCP caller supply an absolute or traversal-laden file_path to the Confluence attachment-upload flow and cause the server to read and upload an arbitrary local file using the operator's credentials, exposing file contents to the linked Confluence instance. The flaw is a direct gap left by the CVE-2026-27825 fix, which hardened download destinations but never constrained upload source paths; only confidentiality is affected (no write or availability impact), and exploitation is bounded to files readable by the server process. No public exploit identified at time of analysis, and the issue is fully resolved by upgrading to 0.22.0.
Path traversal in MCP Atlassian (mcp-atlassian) before 0.22.0 allows an MCP caller that already holds attachment-upload authorization to supply an absolute path or ../ sequence to upload_attachment, causing the server to read an arbitrary server-local file and exfiltrate it through a Jira or Confluence attachment upload. The flaw is authenticated (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) and confidentiality-only: the resolved path is never confined to the server workspace, but there is no write, code-execution, or availability impact through this specific issue. No KEV listing and no public exploit code were identified at time of analysis, and the practical risk is bounded by the requirement that the caller is already trusted to invoke attachment tooling - highest in shared-credential or multi-tenant MCP deployments where the caller should not have host filesystem visibility. The vendor-released fix is version 0.22.0.
Authorization-boundary bypass in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 lets an authorized MCP caller search Jira projects and Confluence spaces that fall outside the administrator-configured allowlist, by supplying caller-controlled projects_filter/spaces_filter arguments that replace the operator's restriction or by embedding an explicit project/space clause that suppresses it. Rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), exploitation requires an already-authorized MCP caller plus a shared Atlassian credential whose access extends beyond the allowlist; the result is read-only information exposure with no integrity or availability impact. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); vendor-released patch: 0.22.0.
Plaintext storage of Atlassian OAuth credentials in MCP Atlassian before 0.22.0 lets any local user or process that can read the persisted token file recover live access and refresh tokens and reuse them against Confluence and Jira. The vulnerable code path is OAuthConfig._save_tokens, which writes ~/.mcp-atlassian/oauth-<client_id>.json using process-default permissions; on a host with a permissive umask, same-group or other local accounts can read it. Exploitation requires a pre-existing local foothold, a permissive umask, and that the OAuth plaintext-fallback file was actually created - it is not remotely exploitable and is not exposed on single-user hosts with a restrictive umask; no public exploit code was identified at time of analysis and this CVE is not in CISA KEV.
Path traversal in the MCP Atlassian MCP server (all versions prior to 0.22.0) allows an authenticated MCP caller that is authorized to invoke the Jira or Confluence attachment-upload tools to read arbitrary files as the server process. The upload tools accept a caller-supplied file_path and, before the fix, only normalised it with os.path.abspath without confining it to a workspace, so any path readable by the server account - tokens, keys, configuration - can be packaged and exfiltrated to an Atlassian issue or page; CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects high confidentiality loss but no integrity or availability impact, and no public exploit code has been identified at time of analysis. The issue matters most in shared-credential or multi-tenant deployments, where a low-privilege caller gains read access far beyond its intended Atlassian scope.
Server-side request forgery in the MCP Atlassian MCP server (versions 0.17.0 through 0.21.x) allows remote unauthenticated attackers to force the server to make outbound requests to internal addresses such as the cloud metadata endpoint 169.254.169.254. The flaw is an incomplete-fix TOCTOU: validate_url_for_ssrf resolves and approves the attacker-supplied X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url host once at middleware time, but the actual HTTP client re-resolves the raw hostname at connect time with no IP pinning, so a DNS-rebinding name can pass validation with a public IP and then resolve to a link-local or RFC1918 address. Exploitation is a documented, publicly described proof-of-concept rather than confirmed in-the-wild activity (no CISA KEV listing), and the vendor has released version 0.22.0 as the fix.
Server-side request forgery in KS-GEN-AI jira-mcp-server 0.2.0 allows a local low-privileged attacker to make the server issue arbitrary HTTP requests by manipulating the imageUrl argument passed to axios.get within the add_attachment_from_public_url function. The CVSS 4.0 vector (AV:L/PR:L/E:P) confirms local access is required, low privileges suffice, and proof-of-concept code exists. No vendor patch has been released; the project maintainer had not responded to the responsible disclosure issue at time of analysis.
Draft release attachment disclosure in Gitea exposes files uploaded to draft releases to unauthenticated network callers via UUID-based web endpoints, bypassing access controls that correctly gate the parallel API handlers. This is an incomplete fix for CVE-2026-27660: that advisory's PR #36659 added `canAccessReleaseDraft` checks to every API code path but left the web-side `ServeAttachment` handler ungated, allowing anyone who obtains an attachment UUID to download its contents with no authentication. A working proof-of-concept is documented in the advisory and confirmed against Gitea v1.27.0+dev; no public exploit identified at time of analysis beyond the advisory PoC, and the vulnerability does not appear in CISA KEV.
Authorization bypass in Apache Camel's camel-jira component (versions 4.0.0 through pre-4.21.0) allows unauthenticated HTTP clients - in routes that bridge an HTTP consumer to a jira: producer - to drive arbitrary JIRA issue operations using the endpoint's configured service-account credentials, including deleting or transitioning issues, creating issues in unauthorized projects, modifying fields, and manipulating watchers. The root cause is that JIRA control header constants (IssueKey, ProjectKey, IssueTransitionId, linkType, and others) use non-Camel-prefixed string values, bypassing the HttpHeaderFilterStrategy which only guards the 'Camel/'/'camel' header namespace at the HTTP boundary. Fixes are confirmed in 4.14.8, 4.18.3, and 4.21.0; no public exploit has been identified at time of analysis, and this vulnerability is not listed in CISA KEV.
Missing authentication on the Atlassian Connect install callback in Mattermost allows a remote attacker to inject a rogue sharedSecret into an in-progress Jira integration setup. Affected versions span the 10.11.x, 11.5.x, 11.6.x, and 11.7.x release trains, all of which expose the POST /ac/installed endpoint without validating the caller's identity during the pending-install window. No public exploit has been identified at time of analysis, but a successful injection corrupts the integration's trust handshake, yielding high integrity and availability impact against the Jira connection. The vendor CVSS vector assigns PR:L, which conflicts with the description's 'remote unauthenticated attacker' language - this discrepancy warrants direct verification with Mattermost advisory MMSA-2026-00654.
Server-Side Request Forgery in GeoServer 2.26.x prior to 2.26.4 and 2.27.x prior to 2.27.3 allows unauthenticated remote attackers to coerce the server into issuing HTTP requests to attacker-chosen destinations by abusing weak prefix matching of the proxy base URL inside the XML entity resolver. No public exploit identified at time of analysis, and EPSS exploitation probability sits at 0.06% (19th percentile), but the trivial network-only attack vector and default-enabled ENTITY_RESOLUTION_ALLOWLIST since 2.25.0 raise the realistic exposure for internet-facing instances.
Arbitrary file write in GeoServer's Master Password Dump web page allows an authenticated administrator to write attacker-controlled content to any absolute filesystem path the GeoServer process can write to, including JSP files in a Tomcat webapps directory. Because GeoServer enforces no maximum master password length, an admin can embed malicious JSP code into the master password and dump it to an executable location, escalating to remote code execution on the host. No public exploit identified at time of analysis and the issue is not in CISA KEV.
Remote code execution in GeoServer (versions prior to 2.27.0) with the DB2 extension installed allows authenticated administrators to perform a JNDI injection attack via a crafted DB2 JDBC connection URL submitted through the Vector Data Sources page, ultimately triggering Java deserialization of untrusted data and arbitrary code execution. No public exploit identified at time of analysis, and the vulnerability is not on CISA KEV, but the attack pattern follows well-known JNDI/Log4Shell-style RCE techniques. Risk is meaningful only where the DB2 extension is deployed and an administrative account is reachable.
Path traversal in XWiki Platform's WebJars API enables a subwiki admin who can publish and install a malicious WebJar extension to write arbitrary files anywhere on the server filesystem. The affected Maven component `xwiki-platform-webjars-api` fails to validate that JAR entry paths extracted during extension installation remain within the intended export directory, allowing overwrite of configuration files or potential superadmin credential manipulation. No public exploit is identified and no CISA KEV listing exists; vendor-released patches are available across three version branches.
Cross-Site Request Forgery in GitLab CE/EE allows an unauthenticated attacker to create unauthorized Jira subscriptions within a targeted authenticated user's namespace by tricking the victim into clicking a specially crafted link. All GitLab installations from version 11.10 through the pre-patch 18.x releases are affected across both Community and Enterprise editions. No public exploit exists and this is not listed in CISA KEV; however, the broad version range spanning over seven years of releases and the prevalence of Jira integrations in enterprise GitLab deployments make patching a meaningful priority.
GitLab's Jira integration exposes out-of-scope Jira issues to authenticated GitLab users across all editions (CE and EE) from version 13.7 through the patched releases, due to the integration's project-scope filter operating only as a UI display control rather than an enforced access boundary. The Changed scope (S:C) in the CVSS vector reflects that impact crosses into Atlassian Jira - a component outside GitLab's own trust domain - allowing confidential Jira issue data to leak beyond intended project boundaries. No public exploit exists and no active exploitation has been confirmed; EPSS is negligible at 0.01% (3rd percentile), placing this firmly in low-exploitation-probability territory despite a broad version range spanning over five years of releases.
Incorrect authorization in Mattermost Server lets any authenticated user forge a '/share-issue-publicly' post action, so that when a victim user interacts with the crafted post, Jira ticket content the victim is authorized to see is relayed to the attacker. Affected lines are 10.11.x through 10.11.7, 10.12.x through 10.12.3, 11.0.x through 11.0.5, and 11.1.x through 11.1.0, and exploitation requires the Jira plugin to be installed, an account able to post into a channel the victim reads, and victim interaction (CVSS 3.1 4.1, AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N). No public exploit code and no confirmed active exploitation were identified at time of analysis, and the exposure is limited to Jira ticket data rather than server compromise.
Mattermost Server versions 10.11.x through 11.1.0 contain an authorization bypass in the Jira plugin's post-to-comment feature that lets an authenticated user read posts and attachments from channels they are not allowed to access. Exploitation requires a valid Mattermost account and an enabled/configured Jira integration where posts can be attached as Jira comments, with impact limited to confidentiality of exposed post content; no public exploit identified at time of analysis. The CVSS 3.1 score of 4.3 reflects a moderate issue rather than a high-severity breach.
Improper authentication enforcement in the Mattermost Jira plugin lets an unauthenticated attacker who knows a valid Mattermost user ID send crafted plugin payloads that spoof that user and inject arbitrary Jira issue-key paths, causing the plugin to issue authenticated GET and POST requests to the connected Jira server. The flaw affects Mattermost Server 11.1.x through 11.1.0, 11.0.x through 11.0.5, 10.12.x through 10.12.3, and 10.11.x through 10.11.7, but only when the Jira plugin (versions <= 4.4.0) is installed, enabled, and connected to Jira; default installations without the Jira integration are not exposed. Per the CVSS vector the attack is unauthenticated and needs no user interaction, and the decisive practical barrier is that the attacker must possess or guess a usable Mattermost user ID. No confirmed active exploitation has been reported (not in CISA KEV) and no public exploit code has been identified; EPSS is low at 0.26% (17th percentile), so this is a mid-tier priority rather than an emergency. Mattermost Advisory ID: MMSA-2025-00555.