Kritisk Atlassian-fejl rammer otte Data Center-produkter – Cloud er lappet

Atlassian offentliggjorde 5. oktober 2026 en kritisk advarsel om CVE-2026-21589, som berører otte selvhostede produkter; virksomheden vurderer fejlen til 9,3 efter CVSS 4.0 og oplyser, at berørte Atlassian Cloud-tjenester allerede er lappet. En angriber kan uden login få adgang til bestemte filer, hvis filens præcise navn og sti er kendt. Egne installationer kræver derfor en kontrol af produkt og version, mens Cloud-kunder ikke selv skal installere en rettelse for denne fejl.

Det franske CERT-FR advarede 6. oktober 2026 om risiko for brud på datas fortrolighed i berørte Atlassian-produkter. Atlassians produktliste omfatter Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo og Crowd Data Center samt Crucible og Fisheye, som står under deres egne produktnavne. Den nødvendige rettelse afhænger af den installerede versionsgren, ikke blot af produktnavnet.

Fejlen giver adgang til kendte filer

Sårbarheden vedrører filer i webapplikationens rodmappe. En angriber skal på forhånd kende både filnavn og præcis sti; fejlen giver ikke mulighed for at opliste mapper for at finde dem. Risikoen er derfor særlig relevant, hvis en installation har følsomme filer på en placering, som kan forudsiges eller kendes af andre.

Adgang uden login betyder, at en almindelig login-side ikke i sig selv beskytter en offentligt tilgængelig installation. Det mulige resultat er indsigt i filer, ikke automatisk adgang til alle data i produktet. Ved offentliggørelsen havde Atlassians undersøgelse ikke fundet tegn på udnyttelse, men den oplysning afgør ikke, om en bestemt kundeinstallation har modtaget mistænkelige anmodninger.

Vælg rettelse efter produkt og versionsgren

CERT Santés oversigt over rettede versioner dækker alle otte produkter. I listen er tallet til venstre den installerede gren og tallet til højre den første oplyste rettelse i den gren. Ligger installationen på samme gren under den angivne rettelse, skal den opdateres. En gren, der ikke står på listen, kræver overgang til en oplyst rettet version eller en nyere understøttet version.

• Bitbucket Data Center: 9.4 → 9.4.26; 10.2 → 10.2.8; 10.5 → 10.5.1.
• Confluence Data Center: 9.2 → 9.2.26; 10.2 → 10.2.19.
• Jira Software Data Center: 9.12 → 9.12.40; 10.3 → 10.3.26; 11.3 → 11.3.12.
• Jira Service Management Data Center: 5.12 → 5.12.40; 10.3 → 10.3.26; 11.3 → 11.3.12.
• Bamboo Data Center: 10.2 → 10.2.24; 12.1 → 12.1.12.
• Crowd Data Center: 6.3 → 6.3.7; 7.0 → 7.0.3; 7.1 → 7.1.7; 7.2 → 7.2.4.
• Crucible: 4.9 → 4.9.15.
• Fisheye: 4.9 → 4.9.15.

Grænserne skal anvendes på hver enkelt installation. En rettet Confluence-installation ændrer eksempelvis ikke status for et separat Bitbucket- eller Jira Service Management-miljø. I en Data Center-klynge bør versionskontrollen omfatte alle relevante noder, så en tilbageværende node med en ældre udgave ikke overses.

Versionsnumrene er heller ikke udskiftelige på tværs af produktgrene. En administrator med eksempelvis en ældre Confluence-gren skal vælge en faktisk rettet udgivelse og planlægge den nødvendige opgradering til den gren. At sammenligne alene de første cifre i versionsnumrene kan give en forkert konklusion om, hvorvidt installationen er rettet.

Begræns ekstern adgang, hvis opdateringen må vente

En berørt installation, som ikke kan opdateres straks, bør fjernes fra internettet eller have sin eksterne netværksadgang begrænset. Det gælder også, når brugerne normalt møder et login: angrebet kræver ikke en godkendt konto. Begrænsningen er midlertidig og skal følges af en opdatering til en rettet produktversion.

1. Identificér: Registrér produkt, installeret version og versionsgren for hver instans. Medtag alle noder og afgør, om instansen kan nås udefra, også gennem en proxy.
2. Opdatér: Installer den rettede version for grenen, eller opgrader til en rettet, understøttet gren. Kontroller bagefter den version, der faktisk kører på hver relevant node.
3. Begræns: Kan opdateringen ikke gennemføres med det samme, så luk ekstern adgang eller indfør den beskrevne regel i en web application firewall eller proxy. Test, at reglen også håndterer URL-kodede varianter.
4. Kontrollér: Gennemgå adgangslogfiler for mistænkelige anmodninger fra tiden før og efter adgangsbegrænsningen.

Der findes produktspecifikke alternativer til en regel i firewall eller proxy. Confluence, de to Jira-produkter, Bamboo og Crowd kan bruge Tomcats RewriteValve på hver node. Bitbucket har en særskilt regel, som også skal anvendes på spejle og noder i spejlfarme. For Crucible og Fisheye er en regel i firewall eller proxy den beskrevne midlertidige mulighed. Reglernes nøjagtige indhold og placering er afgørende: en enkel blokering af synlige tegn kan overse kodede anmodninger.

Logfilerne kan vise, om der er forsøgt adgang

Ved gennemgang af adgangslogfiler er det relevante mønster to punktummer umiddelbart ved siden af en skråstreg, en omvendt skråstreg eller et dobbelt kolon. Tegnene kan også være URL-kodet. Anmodningerne kan derfor afkodes op til to gange før søgning, eller de rå loglinjer kan undersøges med det fulde mønster fra leverandørens vejledning.

Et fund skal vurderes sammen med den konkrete anmodning og serverens svar; mønsteret alene fastslår ikke, at en fil blev hentet. Omvendt giver fravær af fund ingen sikker konklusion, hvis logningen ikke dækker hele den relevante periode eller alle noder. Indtil en rettet version kører på installationen, afhænger dens beskyttelse af, om adgangen fortsat er effektivt begrænset.

Læs også:

• Fabric IQ åbner Power BI-data for AI-agenter – rettighederne følger med
• Nasdaq giver AI-agenter adgang til Calypso – data bliver hos kunden
• Skat som content creator: Gratis produkter tæller også som indtægt