MCPStore.nl

Gepubliceerd:

29 CVE's voor mcp-atlassian: wat Jira- en Confluence-gebruikers nu moeten doen

Kort: op 22 september 2026 zijn 29 CVE-records gepubliceerd voor mcp-atlassian, de populairste community-MCP-server voor Jira en Confluence. Daaronder twee kritieke fouten waardoor niet-geauthenticeerde verzoeken via de HTTP-transport de Atlassian-credentials van de server konden gebruiken. Update naar minimaal versie 0.23.1; die dicht ook een latere kritieke fout in de SSE-transport.

mcp-atlassian (GitHub: sooperset/mcp-atlassian) is geen product van Atlassian, maar een open-sourceproject met bijna 6.000 sterren op GitHub. Het is vooral in trek bij organisaties die Jira of Confluence zelf hosten: Atlassians eigen remote MCP-server is bedoeld voor klanten van Atlassian Cloud. Juist in die hoek — interne Jira-omgevingen met gevoelige projecten — landt nu een opvallend grote stapel kwetsbaarheden.

Wat is er precies gemeld?

De securitypagina van het project telt 36 advisories. Daarvan zijn er 33 op 10 juli 2026 in één keer gepubliceerd, tegelijk met versie 0.22.0 die ze oplost: 2 kritiek, 19 hoog en 12 middel. GitHub, dat als CVE-uitgever optreedt, publiceerde de bijbehorende CVE-records grotendeels op 22 september. Daarom duiken ze nu pas op in kwetsbaarheidsdatabases.

De twee kritieke fouten gaan beide over authenticatie in de HTTP-transport:

Het grootste cluster zit in de upload-tools voor bijlagen. Via een zelfgekozen file_path kon een MCP-client willekeurige bestanden van de server lezen en als bijlage naar Jira of Confluence uploaden, inclusief bestanden met API-tokens. De advisory voor CVE-2026-73498 noemt het scenario waarin een AI-agent via onbetrouwbare content wordt verleid om die tool aan te roepen. Verder zijn er SSRF-fouten, het omzeilen van de project- en spacefilters en OAuth-tokens die leesbaar werden weggeschreven.

Daarna kwam er nog één bij. Op 19 augustus 2026 verscheen een kritieke advisory (CVSS 10.0) voor de SSE-transport: de authenticatie-middleware herkende de SSE-paden niet en liet alle verzoeken door. Getroffen zijn versies tot en met 0.23.0, opgelost in 0.23.1. Wie in juli naar 0.22.0 ging, is dus nog niet klaar.

Waarom zoveel fouten in één project?

Opvallend veel advisories hebben in de titel "incomplete fix". Ze gaan over pogingen om eerdere lekken uit februari 2026 te dichten (CVE-2026-27825, code-executie via een schrijfpad, CVSS 9.0; CVE-2026-27826, SSRF via headers, CVSS 8.2). CVE-2026-77271 laat bijvoorbeeld zien dat de padvalidatie uit versie 0.17.0 de werkmap als grens nam. In een container is dat de applicatiemap, waardoor een aanvaller de eigen Python-modules kon overschrijven.

Onze duiding: dit patroon is typerend voor een project dat begon als lokaal hulpmiddel voor één gebruiker en daarna uitgroeide tot netwerkdienst voor meerdere gebruikers. Een lokale server die via stdio met één ontwikkelaar praat, heeft een ander dreigingsmodel dan een HTTP-endpoint op het bedrijfsnetwerk. Bijna alle kritieke fouten zitten in die overgang: standaardwaarden die lokaal onschuldig zijn, maar op het netwerk de deur openzetten.

Ons advies

(1) Inventariseer waar mcp-atlassian draait, ook op laptops van ontwikkelaars, en controleer de versie. Alles onder 0.23.1 moet worden bijgewerkt. (2) Draait de server via HTTP of SSE? Behandel het dan als een incident en niet als gewone patchronde: controleer de logs van het serviceaccount in Jira en Confluence op onverwachte bijlage-uploads en zoekopdrachten, en roteer de API-tokens. (3) Geef het serviceaccount alleen de projecten en spaces die de agent echt nodig heeft. De ingebouwde filters bleken te omzeilen, dus rechten in Atlassian zelf zijn de echte grens. (4) Gebruik je Atlassian Cloud? Overweeg dan de officiële server van Atlassian. Een community-server is niet per definitie onveilig, maar het beheer ervan hoort op je patchkalender. Meer in onze gids veiligheid & watchouts en het overzicht MCP-servers voor productiviteit & samenwerking.

Wat betekent dit voor MCP in het algemeen?

Het protocol staat hier niet ter discussie: het zijn implementatiefouten in één server. Maar na het LiteLLM-lek van september is dit het tweede grote geval in korte tijd waarin een MCP-endpoint met ontbrekende of te ruime authenticatie de kern van het probleem is. De spec-herziening van 28 juli 2026 scherpt de autorisatie-eisen aan. Het nut daarvan hangt af van servers die die eisen ook echt afdwingen, en bij een zelf gehoste community-server ben je dat als organisatie in de eerste plaats zelf.

Bronnen

Veelgestelde vragen

Ben ik kwetsbaar als ik mcp-atlassian gebruik?

Versies vóór 0.22.0 bevatten de 33 fouten die in juli zijn gemeld; versies tot en met 0.23.0 bevatten daarnaast een kritieke authenticatiefout in de SSE-transport. Update naar minimaal 0.23.1. Het grootste risico loopt wie de server via HTTP of SSE op het netwerk aanbiedt.

Geldt dit ook voor de officiële Atlassian MCP-server (Rovo)?

Nee. mcp-atlassian is een community-project (sooperset/mcp-atlassian), los van Atlassian. De advisories gaan uitsluitend over dat project, niet over Atlassians eigen remote MCP-server.

Waarom komen er nu CVE's als de fixes al in juli uitkwamen?

De advisories verschenen op 10 juli 2026 samen met versie 0.22.0; de bijbehorende CVE-records werden op 22 september gepubliceerd. Vanaf dat moment kunnen tools die op CVE-data leunen de oude versies als kwetsbaar herkennen.

Laatst bijgewerkt: