Atlassian heeft een kritiek Atlassian datacenter lek bekendgemaakt dat in acht zelf gehoste Data Center-producten kan leiden tot het uitlezen van bestanden. Het gaat om CVE-2026-21589, met een CVSS-score van 9,3, en de kern is dat een aanvaller geen login nodig heeft om specifieke bestanden te lezen.
Het belangrijkste detail: de aanvaller moet weten welke bestandsnaam en welk pad hij zoekt. Er is dus geen directory listing, maar als gevoelige bestanden toevallig in de webapp-root staan, kan het risico alsnog groot zijn. In dit artikel zetten we de impact, het patchpad en de tijdelijke maatregelen op een rij.
Wat is er precies mis met het Atlassian datacenter lek?
Volgens de Atlassian-melding betreft het een path traversal. Bij zo’n fout wordt een speciaal geconstrueerd bestandspad gebruikt om locaties te benaderen die normaal niet bereikbaar zouden mogen zijn.
Concreet betekent dit dat een verzoek, zonder privileges of gebruikersactie, bepaalde bestanden kan bereiken die binnen de web application root directory liggen. Dat is de map op de server waar de webapplicatie zelf draait.
Atlassian waarschuwt daarbij dat die locatie in sommige configuraties gevoelige bestanden kan bevatten. De adviseur zet dus vooral in op het voorkomen van ongeautoriseerde toegang tot die root.
Voor wie geldt het risico en voor welke producten?
Het probleem raakt acht Atlassian Data Center-producten vóór de door Atlassian genoemde vaste versies. Of de getroffen versies al dan niet end-of-life zijn, hangt af van het product en de release-lijn; Atlassian adviseert in elk geval om te upgraden naar een fixed long-term support (LTS)-versie of nieuwer.
In de publicatie staan ook opmerkingen over verschillen tussen het CVE-record en interne velden in tickets, met als gevolg dat je bij het plannen van een update niet alleen op één getal moet vertrouwen. Atlassian geeft daarom per product vaste versies waar je naartoe moet.
Verder meldt Atlassian dat de cloudproducten niet langer aan actie toe zijn, omdat ze al gepatcht zijn. Voor zelf gehoste omgevingen is het verhaal anders: daar moeten beheerders maatregelen nemen totdat de upgrade is afgerond.
Waarom is ‘alleen bekende paden’ toch een probleem?
Op papier klinkt het als een beperking: de aanvaller moet de exacte bestandsnaam en het exacte pad kennen. Je zou denken: zonder listing valt er weinig te halen.
Toch kan het risico in de praktijk groter zijn, omdat:
- veel omgevingen standaardbestandsstructuren hebben, waardoor een aanvaller gericht kan proberen;
- er eerder vergelijkbare kwetsbaarheden in Atlassian-omgevingen zijn gezien, wat patroonkennis aantrekkelijk maakt voor aanvallers.
Atlassian heeft in de advisory daarnaast gezegd dat ze geen bewijs hebben gevonden voor misbruik in hun cloudomgeving, maar voor self-hosted kan het bedrijf niet bevestigen of jouw instantie al is geraakt.
Wat is de aanbevolen aanpak: patchen of (tijdelijk) blokkeren?
De hoofdregel is helder: patch eerst. Atlassian plaatst de mitigaties expliciet als beperkt en nadrukkelijk geen vervanging van een upgrade.
Kan je niet meteen upgraden? Dan adviseert Atlassian om de instantie, als dat haalbaar is, offline te halen. Is dat niet mogelijk, dan kun je de toegang beperken: een instantie die vanuit het publieke internet bereikbaar is—ook als er een login nodig is—moet tijdelijk worden afgeschermd van buiten netwerktoegang of je moet een tijdelijke blocking rule toepassen totdat de upgrade klaar is.
Daarna kun je de mitigatie-intentie nog verfijnen per product.
Tijdelijke mitigaties: welke blokkades kun je inzetten?
Atlassian beschrijft drie tijdelijke blocking rules, die allemaal verzoeken blokkeren met een URL die verdachte pad-separators bevat. De blokkade betreft URL-segmenten waarin .. direct naast een van deze tekens staat: /, \ of ::. Ook URL-gecodeerde varianten worden in de regel afgevangen.
Welke rule je moet gebruiken verschilt per product:
- Voor alle acht producten: een regel via web application firewall (WAF) of reverse proxy die URLs matcht en blokkeert.
- Confluence, Jira Software, Jira Service Management, Bamboo en Crowd: een Tomcat RewriteValve-regel die op elke node draait. Je moet die service stoppen, herstarten en bevestigen dat de regel actief is.
- Bitbucket: een regel in urlrewrite.xml die op elke node, mirror en mirror farm node wordt toegepast, gevolgd door een restart.
- Crucible en Fisheye: zij gebruiken alleen de eerste optie (WAF/reverse proxy) volgens de advisory.
Als je mitigaties inzet zonder patch, blijf dan strikt in de tijd: de maatregelen zijn bedoeld om een periode te overbruggen, niet om het structurele probleem op te lossen.
Hoe kun je controleren of er al toegang is geprobeerd?
Atlassian zegt dat ze in hun onderzoek voor cloud geen aanwijzingen hebben gevonden voor exploitatie. Voor self-hosted kun je echter niet met zekerheid terugredeneren op basis van die conclusie.
Daarom raadt Atlassian aan dat je securityteams access logs doorzoeken. Atlassian noemt twee benaderingen:
- Decodeer elke requestregel in de log, tot maximaal twee keer, en zoek naar patronen waarin .. direct naast /, \ of :: staat.
- Gebruik Atlassian’s beschreven block pattern op de raw logregels.
Let op: de advisory geeft niet uitgebreid hoe je het verschil bepaalt tussen een mislukte poging en een verzoek dat daadwerkelijk een bestand heeft opgeleverd. Voor jouw incidentrespons betekent dat: bekijk bij een match ook wat er verder in de logs en bestandswijzigingen te zien is na de vermoedelijke poging.
Vergelijking met eerdere path traversal-incidenten
Deze publicatie plaatst het lek in de context van een eerder bekende kwetsbaarheid: CVE-2021-26086 in Jira Server en Data Center. Die fout is eveneens beschreven als path traversal en stelde remote aanvallers in staat om specifieke bestanden te lezen. De Amerikaanse CISA heeft die kwetsbaarheid in november 2024 in een lijst van “known exploited vulnerabilities” opgenomen.
Die geschiedenis is vooral relevant voor je prioritering. Als jouw Atlassian-omgevingen eerder al de juiste basisbescherming kregen, dan is dat goed; maar een path traversal vraagt altijd om dezelfde combinatie van patching en logcontrole.
CVSS-score 9,3: hoe moet je die toepassen?
Atlassian berekende de score met CVSS v4.0 en kwam uit op 9,3. Ze geven aan dat je vooral moet beoordelen hoe de score in jouw omgeving uitpakt.
De score focust op het feit dat de kwetsbaarheid zonder privileges en via netwerkbereik kan worden geraakt. Voor vertrouwelijkheid is het effect hoog, terwijl integriteit en beschikbaarheid niet als driver zijn meegenomen. Daarnaast wijst Atlassian naar impact op andere systemen als hoog—zonder in detail te duiden waarom dat in hun berekening zo uitpakt.
Voor beheerders betekent dit praktisch: behandel het als ernstig, zeker als jouw omgeving extern bereikbaar is.
Wat kun je nu meteen doen?
Als je Atlassian Data Center draait, is de verstandigste route een korte actielijst die je vandaag al kunt starten:
- Inventariseer welke van de acht betrokken producten bij jou draaien en in welke versies.
- Plan de upgrade naar de vaste versies die Atlassian noemt (bij voorkeur een LTS-lijn).
- Beperk publieke toegang tot je de patch afrondt: houd instances uit het publieke netwerk of gebruik tijdelijke blokkades.
- Check access logs op de door Atlassian beschreven path traversal patronen.
Als je meer wilt lezen over hoe je Atlassian- en andere omgevingsrisico’s praktisch benadert—zeker rond toegang en datalekken—kan ook het artikel over CPR-datalek via bedrijfstoegang helpen om je denkwijze richting toegangsbeheer en impactanalyse te scherpen.
Daarnaast sluit de bredere focus op basismaatregelen aan bij security fundamentals: ook bij snelle updates blijft logica over bereikbaarheid, patchdiscipline en monitoring leidend.
Conclusie
De Atlassian datacenter lek (CVE-2026-21589) laat zien hoe belangrijk het is om self-hosted omgevingen strak te beheren. Zonder login kan een aanvaller via path traversal specifieke bestanden lezen wanneer de juiste paden bekend zijn en wanneer die bestanden in de webapp-root beschikbaar zijn.
Upgraden naar de door Atlassian genoemde fixed versies is de hoofdactie. Lukt dat niet direct, dan is offline halen of het toepassen van de door Atlassian beschreven tijdelijke blokkades de tweede stap—altijd met focus op het zo snel mogelijk oplossen. Tot slot: controleer access logs om te beoordelen of er al verdachte verzoeken zijn geweest.
Bron: https://thehackernews.com/2026/10/critical-atlassian-flaw-lets.html
