Skip to content
Security & Trust

CVE-2026-77246: one HTTP setup let unauthenticated callers pick an upload host

MCP Atlassian before 0.22.0, over HTTP with READ_ONLY_MODE=false and no Authorization identity

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
CVE-2026-77246: one HTTP setup let unauthenticated callers pick an upload host

AI-generated image for WebPulse. About our images

Key finding

CVSS 3.1 base score: 7.4 (HIGH) (Source: NIST NVD record CVE-2026-77246, score assigned by [email protected] (last modified September 28, 2026))

The feature and the leak are the same function

One familiar question about AI connectors is what a model might be talked into doing. CVE-2026-77246 points at a plainer one underneath it: who is allowed to ask the server for something, and who decides where the result goes. In the configuration the record describes, the requester had a say in both that the operator may not have intended.

The NIST National Vulnerability Database (NVD) record, published September 22, 2026 and last modified September 28, covers MCP Atlassian, a Model Context Protocol server for Confluence and Jira. NVD ties the flaw to a specific setup: releases older than 0.22.0, run over HTTP transport, with READ_ONLY_MODE turned off. In that setup the server takes requests that carry no Authorization identity.

A caller can also supply headers such as X-Atlassian-Confluence-Url, and the server lets them pick where an upload goes: a public hostname of the caller's choosing, or one covered by MCP_ALLOWED_URL_DOMAINS.

With those two gaps open, it is enough to ask the Confluence attachment tool (confluence_upload_attachment), or the Jira attachment tool, to upload a path on the server's own disk. The MCP process then transmits that file to the chosen endpoint. Version 0.22.0 contains the fix.

7.4 (HIGH)
CVSS 3.1 base score
Source: NIST NVD record CVE-2026-77246, score assigned by [email protected] (last modified September 28, 2026)

Who is asking, and where the file goes

Security teams know this shape as the confused deputy: a component holding real authority acts for a party that should never have been able to direct it. The MCP process can read files on its host and reach the network. Uploading attachments is what it is built to do. In the described setup, the server did not require an identity from the caller, and it did not limit the destination to hosts the operator had chosen: a caller could select any public hostname.

The lesson here is that an agent connector's risk is set by the host it runs on, not only by the product it fronts. A team may think of it as "the Jira integration." The process is also a program on a machine, with that machine's file access and network egress. A control that checks neither who is calling nor where the output is going leaves that authority open to whoever can reach the endpoint.

0.22.0
Fixed in version
Source: NIST NVD record CVE-2026-77246, citing the MCP Atlassian v0.22.0 release (last modified September 28, 2026)

Reading the score without over-reading it

The scorer, [email protected], rated the flaw 7.4 (HIGH) under CVSS 3.1. In plain terms, the vector assumes an attacker on an adjacent network rather than one reaching in from anywhere on the internet. It assumes low complexity, no privileges and no user action, and it records a changed scope and a high confidentiality impact, with no integrity or availability impact. None of this tells you how your organisation exposes its MCP server, so that has to be established locally. Nothing in the NVD record describes exploitation in the wild.

The record also names READ_ONLY_MODE=false as part of the condition. A setting whose name signals write access is a decision about exposure. The record does not say why any team would turn it off, but whatever the reason, teams that do take on a different risk than teams that leave it on. That is a configuration choice, and it deserves an owner and a written reason.

Where the cost lands

One reading of the record is that the exposure sits less with the Atlassian administrator than with whoever owns the host the connector runs on, since the files in question are that host's. If the connector was rolled out as a productivity feature, that host owner may never have been asked to review it. It is worth asking directly.

Questions to put to your team

1. Do we run MCP Atlassian anywhere, in HTTP transport mode, and which version? Anything before 0.22.0 falls within the record, subject to the other conditions below.

2. Is READ_ONLY_MODE set to false in any deployment, and who approved that?

3. Which networks can reach the endpoint? Does it answer a request that carries no Authorization identity?

4. What files can the connector's process read, and can its host send traffic to arbitrary public hostnames?

5. Is there an inventory of every MCP server running in the organisation, with a named owner for each?

In the configuration the record describes, a connector that lets the caller choose the destination has handed over the mailroom. The fix here is a version number, but the durable control is deciding, for every agent tool, who may ask and where the answer may go.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.

CVEs in this analysis
CVE-2026-77246
Share this insight