8가지 Atlassian Data Center 제품이 공유하는 파일 읽기 취약점과 패치 시점

요약 (TL;DR)

• Atlassian Data Center는 Atlassian의 협업 소프트웨어의 자체 호스팅(self-hosted) 에디션으로, 기업이 자체 서버에서 운영하는 버전이며, 이 8가지 제품은 코드 호스팅, 프로젝트 추적, 팀 위키, 빌드 서버 및 중앙 사용자 디렉토리를 포괄합니다.
• Atlassian은 2026년 10월 5일자로 CVE-2026-21589에 대한 권고문을 발표했습니다. 이 취약점은 심각도 9.3으로 평가되었으며, 패치가 적용되지 않은 모든 버전의 웹 애플리케이션 루트 디렉토리 내 특정 파일을 인증 없이 읽을 수 있게 합니다.
• 이 결함은 8가지 제품 모두가 웹 리소스 라이브러리를 공유하기 때문에 발생했으며, 익스플로잇 경로는 콜론 두 개(double colon) 시퀀스를 슬래시(/)로 변환하여 플러그인 리소스 엔드포인트를 통해 디렉토리 탐색 요청을 구성합니다.
• 파일 하나를 읽는 것이 첫 단계였습니다. Crowd 통합 배포 환경에서 이 읽기 작업은 Jira, Confluence 및 Bitbucket의 관리자 접근 권한으로 이어지는 자격 증명(credentials)에 도달할 수 있으며, 이는 watchTowr가 엔드투엔드로 시연했습니다.
• 이후 패치 적용 시간이 시작되었습니다. 공개적인 개념 증명(proof of concept) 코드가 2026년 10월 7일에 게시되었고, 허니팟 네트워크는 게시 후 두 시간 이내에 악용 시도를 기록했습니다.
• Atlassian은 개별 인스턴스가 영향을 받았는지 확인할 수 없으므로, 탐지 작업은 고객에게 달려 있습니다. 접근 로그에서 탐색 패턴을 검토하고 모든 접속(hit)을 파일이 읽힌 것으로 간주해야 합니다.
• 임시 완화 조치로는 WAF 또는 프록시 규칙, 5개 제품에 대한 Tomcat RewriteValve 규칙, 그리고 모든 클러스터 노드, 미러 및 미러 팜 노드에 적용되는 urlrewrite.xml 규칙이 있습니다.
• 자체 호스팅 팀을 위한 구조적인 핵심은 Atlassian이 유지보수 릴리스(maintenance releases)로 수정 사항을 배포한다는 점이며, 이는 소유자와 기간을 가진 업그레이드 프로젝트로 이 작업을 만든다는 의미입니다.

8가지 제품 뒤에 숨겨진 하나의 공유 라이브러리

Atlassian의 권고문은 영향을 받는 제품군을 모호함 없이 명시합니다: Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible 및 Fisheye의 모든 버전 중 패치가 적용된 릴리스 이전에 배포된 제품들입니다. 해당 회사는 이 취약점을 CVSS 4.0 기준으로 Critical 등급(9.3점)으로 평가했으며, 공격 벡터는 네트워크 접근 가능, 권한 불필요, 사용자 상호작용 불필요로 되어 있습니다.

Netics editorial statistic card showing the 9.3 CVSS 4.0 rating for CVE-2026-21589 and the fact that no login is required.

Atlassian의 권고문을 바탕으로 작성된 Netics 에디토리얼 카드입니다: 자격 증명이나 사용자 상호작용이 필요 없는 파일 읽기 취약점에 대한 공급업체의 자체 평가입니다.

범위(scope)는 이 취약점이 왜 주목받았는지 설명합니다. 이 제품들은 소스 저장소, 내부 문서, 스프린트 기록 및 이를 연결하는 식별자 기록을 보유하고 있으며, Atlassian의 표현은 영향도를 솔직하게 유지합니다:

이 보안 권고는 파일 읽기 취약점을 설명합니다. 연구진은 실제 배포 환경에서 이 파일 읽기가 어떻게 작동하는지 설명하며, 그 차이는 점수(score)가 전달하는 것보다 상황의 긴급성을 더 잘 설명해 주기 때문에 주목할 가치가 있습니다.

이 경로는 플러그인 리소스 엔드포인트(plugin resource endpoints)를 거치는데, 여기서 사용자 제어 리소스 이름이 로컬 파일 시스템을 통해 이를 해결하는 리소스 팩토리(resource factory)에 도달합니다. 이 과정에서 두 개의 파일이 중요하게 작용합니다. 하나는 웹 리소스를 파일에 매핑하는 아카이브(archive)이고, 다른 하나는 제품을 해당 ID 공급자(identity provider)에 매핑하는 설정 파일입니다. Crowd가 통합된 배포 환경에서는 두 번째 파일을 읽음으로써 중앙 디렉터리의 자격 증명(credentials)이 넘어오게 됩니다. 연구진은 여기서 사용자를 생성하고 관리자 그룹(administrators group)에 추가한 뒤, 다음과 같은 문장으로 마무리하며 이 패턴에 대해 어떤 심각도 점수보다 더 많은 것을 보여주었습니다: "축하해, 친구. 방금 Jira 관리자로 승진했어."

이 상황을 정확하게 유지하는 두 가지 주의사항(caveats)이 있습니다. 첫째, 이 기술은 Tomcat 애플리케이션 컨텍스트 외부로 이동할 수 없었고, 둘째, IP 주소별 접근을 제한하는 Crowd 설치 환경에서는 마지막 단계가 상당히 어려워집니다. 하지만 여전히 사실인 것은 순서입니다: 협업 제품의 읽기 전용 결함(read-only flaw)이 해당 제품을 문서화하는 시스템에 대한 관리자 제어권으로 이어질 수 있다는 것입니다.

Capture of Atlassian's Crowd product page describing centralised identity management and single sign-on.

Atlassian의 공식 Crowd 제품 페이지(atlassian.com, 2026년 10월 7일 조회): Confluence, Jira 또는 Bitbucket 설치 환경에서 읽은 자격 증명으로 도달하는 중앙 디렉터리.

개념 증명(Proof of Concept)이 공개되면서 패치 시계가 작동하기 시작했다

Atlassian은 10월 5일 월요일에 해당 권고(advisory)를 발표했으며, 자체 조사 결과 악용의 증거는 발견되지 않았다고 밝혔습니다. 하지만 그 평가는 빠르게 무너졌습니다. 공개적인 개념 증명(proof of concept)이 포함된 상세 기술 보고서가 10월 7일에 도착했고, Previdian의 허니팟 네트워크는 연구원 Ryan Dewhurst에 의해 BleepingComputer에 전해진 바와 같이 발표 후 두 시간 이내에 악용 시도를 기록했습니다.

이 메커니즘은 인터넷에 노출된 소프트웨어를 운영하는 사람이라면 누구나 익숙할 것입니다. 정확한 설명과 작동하는 익스플로잇(exploit)은 사소한 결함을 스캐닝 템플릿으로 변환하며, 제품 목록의 광범위함은 스캐너에게 넓은 주소 공간을 제공합니다. Dewhurst는 이러한 활동이 증가할 것으로 예상합니다. Atlassian의 입장은 정직합니다. 개별 고객 인스턴스가 침해되었는지 여부를 판단할 수 없기 때문에, 탐지 책임은 서버를 운영하는 팀에 있습니다.

여기서 탐지는 공개된 패턴을 이용한 로그 작업입니다. 각 요청 라인을 최대 두 번까지 디코딩하고, URL-인코딩 형태를 포함하여 슬래시(/), 백슬래시() 또는 콜론(:) 옆의 점 쌍(pair of dots)이 있는지 확인해야 합니다. 어떤 탐지 건도 사소한 문제가 아니라 침해로 간주되어야 하는데, 그 이유는 읽힌 파일에 나머지 시스템을 잠금 해제하는 자격 증명(credential)이 포함되어 있을 수 있기 때문입니다. 공급업체로부터 받은 검증된 비공개 권고가 이 종류의 작업에 대한 주요 기록으로 간주되며, 저희는 Zammad 익스플로잇 체인 및 상충되는 영향을 받는 버전 목록을 통해 공급업체 티켓이 두 데이터베이스가 불일치할 때 왜 더 신뢰받는지 다루었습니다.

Netics editorial before-and-after card contrasting the disclosure on 5 October with the exploitation attempts recorded two days later.

Atlassian의 권고와 BleepingComputer의 보도를 바탕으로 제작된 Netics 편집 카드: 공급업체의

이번 주 자체 호스팅 팀이 해야 할 일

업그레이드 경로는 다소 까다로운 특성을 가지고 있습니다. Atlassian은 더 이상 바이너리 패치를 배포하지 않기 때문에, 이를 해결하려면 새로운 유지보수 릴리스로 이동해야 합니다. 업그레이드를 미뤄온 팀에게는 테스트 기간, 롤백 계획, 그리고 책임자가 필요한 프로젝트가 됩니다.

이번 주에 업그레이드가 불가능한 경우, 권고안의 세 가지 완화책이 클러스터를 적절하게 보호합니다. 트래버설 패턴을 차단하는 WAF(Web Application Firewall) 또는 프록시 규칙은 모든 8개 제품에서 작동합니다. 이 중 5개는 또한 모든 노드의 Tomcat RewriteValve 규칙으로 요청을 차단할 수 있으며, 이후 재시작이 필요합니다. Bitbucket은 모든 노드, 미러 및 미러 팜 노드에 적용되는 urlrewrite.xml의 규칙을 사용하며, 역시 재시작이 뒤따릅니다. Crucible와 Fisheye는 방화벽 옵션만으로 충분합니다.

모든 작업이 끝났다고 말하기 전에 주의를 기울여야 할 두 가지 운영 세부 사항이 있습니다. 로그인 페이지 뒤에 있는 인스턴스도 여전히 주의가 필요합니다. 왜냐하면 인증되지 않은 취약점은 비밀번호를 요구하지 않기 때문입니다. 또한, 지원 종료(end-of-life) 릴리스 역시 영향을 받는 버전이므로, 전체 시스템 감사(fleet audit)를 수행하면 더 이상 수정 사항을 받지 못하는 설치 환경을 파악할 수 있고, 이것이 마이그레이션 논의가 구체화되는 지점입니다.

이것이 자체 호스팅 패치 모델에 미치는 영향

자체 호스팅 소프트웨어는 데이터와 구성에 대한 통제권을 제공하며, 또한 패치 일정까지도 확보해 줍니다. 클라우드 환경에서 제품을 운영하는 공급업체 조직은 한 번 패치하고 넘어갑니다. 하지만 자체 하드웨어에서 동일한 제품을 운영하는 회사는 일정을 물려받고, 잠재적 피해 범위(blast radius)를 가지며, 얼마나 오랫동안 위험을 감수할지 선택해야 합니다.

Capture of the fixed-versions section of Atlassian's advisory for CVE-2026-21589, listing the patched release numbers for all eight Data Center products.

Atlassian의 CVE-2026-21589에 대한 공식 권고안(confluence.atlassian.com, 2026년 10월 5일 게시, 2026년 10월 7일 조회)은 영향을 받는 8개 제품 각각의 수정된 릴리스를 보여줍니다.

이러한 선택 지점이 가장 많은 노출을 안고 있습니다. 보안 권고(advisory)와 실제 적용된 패치 사이의 간극은 공격자가 얻는 시간적 창구이며, 이 취약점에 대한 공개와 관찰된 악용 시도 사이에 2일이라는 시간이 있다는 것은 그 창구가 얼마나 좁아졌는지 보여줍니다. 실질적인 대응 방안은 노출된 관리 인터페이스를 소유자(owner), 목록(list), 검토 주기(review cadence)가 있는 범주로 취급하는 것입니다. 이는 평이한 언어 알림을 통한 인프라 모니터링의 배경이 되는 것과 동일한 규율입니다. 즉, 외부에서 접근 가능한 서비스가 무엇인지 알고 있어야 하며, 개념 증명(proof of concept)이 그 질문을 시급하게 만들기 전에 미리 알아야 합니다.

원래 Netics 블로그에 게시되었습니다.