NOW Briefing
Atlassian 자체 호스팅 제품 미인증 임의 파일 읽기 취약점 (CVE-2026-21589)
■ 개요
Atlassian은 2026년 10월 5일 보안 권고를 공개하고 자체 호스팅 제품 8개에 영향을 주는 임의 파일 읽기 취약점 CVE-2026-21589를 수정했습니다. 대상은 Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd Data Center와 Crucible, Fisheye입니다. 벤더는 각 제품의 패치 이전 모든 버전이 영향을 받는다고 밝혔습니다. 이슈 추적·문서 협업·소스 저장소를 담당하는 개발 조직의 핵심 업무 시스템이 한꺼번에 영향을 받습니다.
공격자는 로그인 없이 요청만으로 웹 애플리케이션 루트 디렉터리 안의 파일을 읽을 수 있습니다. 다만 벤더는 대상 파일의 정확한 이름과 경로를 미리 알고 있어야 하며, 이 취약점으로 디렉터리 내용을 나열하거나 열거할 수는 없다고 명시했습니다. 경로가 널리 알려진 애플리케이션 설정 파일이 주된 노출 대상이고, 여기에 데이터베이스 접속 정보 같은 자격증명이 들어 있는 배포에서는 해당 자격증명이 그대로 노출될 수 있습니다.
이미 실제 악용이 관측돼 우선순위를 높여야 합니다. 권고 공개 다음 날인 10월 6일 보안 업체 watchTowr가 기술 분석을 공개했습니다. BleepingComputer 보도에 따르면 그로부터 두 시간 안에 위협 인텔리전스 업체 Previdian의 허니팟(공격을 유인하는 미끼 시스템) 네트워크에서 악용 시도가 관측됐습니다. watchTowr도 FAQ에서 10월 6일 기준 실제 악용을 관측했다고 밝혔습니다. Atlassian은 클라우드 제품은 이미 패치했고 악용 증거도 확인되지 않아 클라우드 고객은 별도 조치가 필요하지 않다고 안내했습니다. 조치 대상은 자체 호스팅 인스턴스입니다.
■ 요약
| 항목 | 내용 |
|---|---|
| CVE ID | CVE-2026-21589 (리소스 다운로드 경로 처리의 미인증 임의 파일 읽기) |
| CVSS 점수 | CVSS v4.0 9.3 |
| 취약점 유형 | 경로 조작(path traversal)을 통한 미인증 파일 읽기 |
| 영향/위험 | • 로그인 없이 웹 애플리케이션 루트 내 파일 읽기 가능 • 설정 파일 노출 시 데이터베이스 접속 정보 등 자격증명 유출 가능 • 보도 기준, Crowd 연동 Jira 배포에서 WEB-INF/classes/crowd.properties의 평문 자격증명을 확보하고 Crowd에 접근할 수 있으며 해당 자격증명의 권한이 충분한 경우 관리자 계정 생성으로 이어질 수 있음• 디렉터리 나열·열거는 불가하며 정확한 파일 경로를 알아야 함 |
| 취약 버전 | Bitbucket·Confluence·Jira Software·Jira Service Management·Bamboo·Crowd Data Center·Crucible·Fisheye: 패치 이전 모든 버전 |
| 패치 버전 | • Bitbucket Data Center 9.4.26 / 10.2.8 / 10.5.1 • Confluence Data Center 9.2.26 / 10.2.19 • Jira Software Data Center 9.12.40 / 10.3.26 / 11.3.12 • Jira Service Management Data Center 5.12.40 / 10.3.26 / 11.3.12 • Bamboo Data Center 10.2.24 / 12.1.12 • Crowd Data Center 6.3.7 / 7.0.3 / 7.1.7 / 7.2.4 • Crucible, Fisheye 4.9.15 |
■ 기술 분석
watchTowr 분석 기준으로 이 취약점의 원인은 여러 Atlassian 제품이 함께 사용하는 웹 리소스 라이브러리(atlassian-plugins-webresource)의 경로 처리에 있으며, 플러그인 정적 리소스를 내려주는 다운로드 경로가 공격 표면이 됩니다. 이 라이브러리를 공유하는 8개 제품이 한꺼번에 영향을 받고, 제품마다 동일한 요청 형태가 통합니다.
핵심은 이중 콜론(::)을 슬래시(/)로 되돌리는 처리입니다. 요청이 자바 웹 서버(Tomcat)의 경로 정규화 단계를 지날 때 ::는 경로 구분자로 인식되지 않기 때문에, 상위 디렉터리 이동 표기(..)가 걸러지지 않은 채 애플리케이션까지 전달됩니다. 이후 리소스 라우터가 ::를 /로 복원하면 상위 경로를 가리키는 경로가 완성되고, 공격자는 웹 애플리케이션 내부 설정·클래스 디렉터리(WEB-INF) 아래 파일을 인증 없이 읽을 수 있습니다. 연구 분석 기준으로 읽기 범위는 Tomcat 애플리케이션 컨텍스트 내부로 제한됩니다. 노출 가치가 큰 대상은 WEB-INF/web.xml과 WEB-INF/classes/ 하위의 *.properties·*.xml 설정 파일이며, 배포에 따라 데이터베이스 계정이나 연동 자격증명이 평문으로 담겨 있습니다.
패치 전후를 줄 단위로 대조할 수 있는 공개 diff는 확인되지 않았습니다. Atlassian 제품 소스가 공개돼 있지 않고, 벤더 권고와 연구 보고에도 수정 커밋이 포함되지 않았습니다. 다만 watchTowr는 디컴파일한 리소스 라우터 코드에서 슬래시를 ::로 치환하고 다시 되돌리는 함수 쌍을 원인 지점으로 지목했고, 벤더가 임시 완화책으로 제시한 차단 정규식도 .. 앞뒤에 오는 슬래시·역슬래시·이중 콜론과 그 URL 인코딩 변형(중첩 인코딩 포함)을 함께 다룹니다. 이를 종합하면 수정 범위는 단일 문자열 치환보다 넓은 경로 해석 전반에 걸쳐 있다고 추정됩니다.
■ PoC
watchTowr는 10월 6일 기술 분석과 함께 Jira·Confluence·Bitbucket 대상 취약 여부 점검 스크립트를 공개했습니다. Help Net Security 보도 기준 watchTowr는 완전한 익스플로잇을 공개하지 않았지만, BleepingComputer는 PoC가 공개됐다고 보도해 해석이 갈립니다.
이와 별개로 제3자가 공개한 GitHub 저장소에는 익스플로잇 코드가 올라와 있습니다. 해당 스크립트는 제품별 다운로드 경로를 돌면서 알려진 설정 파일 경로를 요청하며, 경로 탐색 문자열은 이중 콜론의 URL 인코딩 형태(%3a%3a)로 만듭니다.
아래 코드는 공개 PoC 원문인 exploit.py의 요청 경로 생성 함수 build_path() 일부입니다. 코드는 수정하지 않고 그대로 옮겼습니다. 파일 전체는 참고 자료에 연결한 원문 링크에서 확인할 수 있습니다.
def build_path(anchor, route, prefix, depth, target_file):
traversal = "..%3a%3a" * depth
if prefix:
return f"/{prefix}{route}/{anchor}{traversal}{target_file}"
return f"/download/{route}/{anchor}{traversal}{target_file}"
⚠️ WARN
공격 조건이 단순해 스캐닝 도구로 대량 탐색하기 쉽고, 보도 기준 취약점 스캐너 Nuclei의 탐지 템플릿도 공개됐습니다.
외부에 노출된 인스턴스는 패치 적용 전까지 접근 차단을 함께 적용해야 합니다.
■ 탐지 및 점검
• 액세스 로그에서 ..가 /, \, :: 바로 앞이나 뒤에 붙는 요청 경로를 찾습니다. 벤더가 제시한 차단 정규식은 중첩 URL 인코딩 변형까지 포함하므로 원본 로그 문자열에 그대로 적용할 수 있습니다.
• 리소스 다운로드 경로 요청 중 WEB-INF나 .properties·.xml 설정 파일을 가리키면서 200으로 응답한 기록이 있는지 확인합니다. 응답 크기와 반환 본문까지 함께 확인해야 실제 파일 내용이 전달됐는지 판단할 수 있고, 경로 패턴만 일치하는 기록은 별도로 점검합니다.
• 요청 본문·응답 본문까지 확인하려면 프록시 본문 로깅이나 전체 패킷 캡처가 있어야 합니다. 방화벽·NetFlow 로그만으로는 어떤 파일이 요청됐는지 알 수 없습니다.
• 보도된 관측 사례 기준으로 38.60.157.86, 146.70.187.234, 159.26.119.225에서 유입된 요청 이력을 점검합니다. 공격 인프라는 쉽게 바뀌므로 이 값만으로 탐지를 끝내지 않습니다.
• 각 인스턴스가 기술 분석이 공개된 2026년 10월 6일 이후 패치 적용 시점까지 인터넷에 직접 노출돼 있었는지, 그 기간의 로그가 보존돼 있는지 확인합니다.
• 애플리케이션 서버 앞단의 웹 방화벽(WAF)이나 리버스 프록시에서 위 패턴 차단 규칙의 적용 여부와 차단 로그를 함께 검증합니다.
✅ CHECK
로그 보존 기간이 짧아 10월 5~7일 구간 기록이 이미 삭제된 환경은 "확인되지 않음"으로 분류하고 자격증명 교체 범위에 포함해야 합니다.
■ 대응 방안
• 제품별 고정 버전(Confluence 9.2.26·10.2.19, Jira Software 9.12.40·10.3.26·11.3.12 등)으로 즉시 업그레이드합니다.
• 즉시 업그레이드가 어려우면 해당 인스턴스를 인터넷에서 분리하거나 접근 가능한 출발지를 제한합니다. 벤더도 사용자 인증이 적용된 인스턴스를 포함해 공개 인터넷에서 접근 가능한 인스턴스는 패치 전까지 외부 접근을 차단하라고 권고했습니다.
• 임시 완화책으로 벤더 권고의 차단 정규식을 웹 방화벽에 적용하거나, Tomcat의 URL 재작성 밸브(RewriteValve) 규칙(Confluence·Jira Service Management·Jira·Bamboo·Crowd) 또는 Bitbucket의 urlrewrite.xml 규칙을 적용합니다. 완화책은 패치를 대체하지 않습니다.
• 패치 전 외부 노출 이력이 있는 인스턴스는 침해 가능성을 전제로 우선 조사하고, 설정 파일에 담긴 데이터베이스 계정과 Crowd 연동 자격증명을 교체합니다.
• 클라우드 제품은 벤더가 패치를 완료해 고객 조치가 필요하지 않으므로, 점검 범위를 자체 호스팅 인스턴스 목록으로 한정해 누락 없이 식별합니다.
💡 TIP
자격증명 교체는 데이터베이스 계정부터 시작해 연동 서비스 계정, 애플리케이션 링크용 비밀값 순으로 진행하면 서비스 중단 범위를 줄일 수 있습니다.
[참고 자료]
• Atlassian 보안 권고 — CVE-2026-21589
• watchTowr Labs 기술 분석 — Atlassian 미인증 임의 파일 읽기
• watchTowr 위협 인텔리전스 권고 — CVE-2026-21589
• watchTowr FAQ — CVE-2026-21589
• BleepingComputer — PoC 공개 후 악용 시작 보도



