Atlassian의 CVSS 9.3 파일 읽기 취약점이 실제로 악용되고 있다. 권고문은 8개 제품의 모든 버전을 영향 대상으로 적었다

Atlassian은 10월 5일, 자체 호스팅 제품 8종에 존재하는 임의 파일 접근 취약점에 대한 보안 권고문을 공개했다. 10월 7일에는 BleepingComputer가 이 취약점이 실제로 악용되고 있다고 보도했다. 두 날짜 사이의 간격은 이틀이지만, 정작 중요한 간격은 그보다 짧다. 보안 기업 Previdian은 공개된 개념 증명(PoC)이 나온 뒤 약 두 시간 만에 자사 허니팟 네트워크에 악용 시도가 도달했다고 밝혔다.

취약점은 CVE-2026-21589로, CVSS v4.0 기준 9.3을 받았다. 인증도, 사용자 상호작용도, 특별한 권한도 필요하지 않다. Atlassian 자신의 설명은 의도적으로 좁다.

이 임의 파일 접근 취약점은 인증되지 않은 공격자가 영향을 받는 버전에서 웹 애플리케이션 루트 디렉터리 내의 특정 파일에 접근할 수 있게 한다.

좁은 표현이 감추고 있는 것

문자 그대로 읽으면 이것은 실질적인 제약이 붙은 파일 노출 버그다. 공격자는 원하는 파일의 정확한 경로를 알고 있어야 한다. 이 취약점으로는 디렉터리 목록을 받아 둘러볼 수 없다. CVSS 벡터가 기밀성을 높음으로, 무결성과 가용성을 없음으로 평가한 이유가 바로 이 제약이다. 아무것도 쓰이지 않고 아무것도 중단되지 않는다.

같은 이유로 점수가 중간 수준이 아니라 여전히 9.3이기도 하다. 자체 호스팅 Atlassian 환경에서 노려볼 가치가 있는 파일 경로는 비밀이 아니다. 모든 설치본에서 동일한 경로이고, 벤더 자신의 문서에 적혀 있으며, 소프트웨어 사본을 열어보면 드러난다. Atlassian의 권고문과 함께 기술 분석을 공개한 watchTowr 연구진은, 애플리케이션 루트 안의 알려진 설정 파일 경로를 읽는 것만으로도 Atlassian의 ID 관리 제품과 통합된 환경에서는 자격 증명을 확보해 관리자 권한으로 상승할 수 있음을 입증했다. 관리자 계정을 안정적으로 내주는 '읽기 전용' 버그는 실무에서는 읽기 전용 버그가 아니다.

CVSS 벡터의 하위 시스템 영향 지표 — 하위 시스템의 기밀성, 무결성, 가용성이 모두 높음 — 는 채점 측이 같은 말을 다르게 표현한 것이다. Jira와 Confluence는 조직이 티켓 댓글에 자격 증명을 적고, 위키 페이지에 아키텍처를 올리고, 호스트명이 달린 사고 타임라인을 남겨 두는 곳이다. Bitbucket은 소스 코드를 두는 곳이다. 파일 읽기는 입구이고, 목적인 경우는 드물다.

영향 버전과 수정 버전

Atlassian은 8개 제품 모두에 대해 출시된 전 버전을 영향 대상으로 명시했다. 그대로 두어도 안전한 구버전 브랜치는 없다.

Atlassian Cloud 고객은 영향을 받지 않는다. 벤더가 자사 호스팅 인스턴스에 이미 패치를 적용했고 고객 측 조치는 필요 없다고 밝혔다. 노출은 전적으로 자체 호스팅 환경에 있다. Atlassian이 Server 라이선스를 종료한 뒤로 그것은 Data Center 환경을 뜻하며, 바로 Cloud로 옮기지 않기로 선택한 조직들에 집중되어 있다. 규제 산업, 방위 사업자, 정부 기관, 그리고 Jira를 자체 하드웨어에 계속 두어야 할 컴플라이언스 사유를 가진 대기업들이다.

두 시간이라는 숫자

Previdian의 허니팟 타이밍은 이 사안에서 가장 유용한 사실이며, 게다가 Atlassian에 관한 사실이 아니다. 널리 배포된 엔터프라이즈 소프트웨어의 인증 불필요 취약점에 대한 PoC가 공개되면, 그것은 이제 대부분의 변경 관리 절차가 유지보수 창을 잡는 속도보다 빠르게 스캔 트래픽으로 바뀐다. 두 시간은 긴급 패치를 변경 심의 위원회에 통과시킬 시간이 아니다. 권고문을 읽기에도 빠듯하다.

이것이 Atlassian이 권고문 본문보다 먼저 공개한 보조 완화 조치의 근거다. 완화용 파일은 10월 2일에 공개되었다. 벤더가 제시한 것은 네트워크 수준에서 외부 접근 제한, 트래버설 형태의 요청 경로를 거부하는 WAF 또는 프록시 규칙, 그리고 제품별 URL 재작성이다. Confluence, Jira, Jira Service Management, Bamboo, Crowd에는 Tomcat RewriteValve 설정이, Bitbucket에는 urlrewrite.xml 수정이 해당된다. 어느 것도 패치의 대체물은 아니다. 그러나 어느 것이든 패치보다 짧은 시간에 배포할 수 있다. 그게 핵심이다.

해야 할 일

위 버전으로 패치한다. 유지보수 창이 며칠 뒤라면 그동안 해당 제품용 벤더 완화 조치를 적용하고, 공개될 필요가 없는 인스턴스는 인터넷에서 분리한다. 그다음 접근 로그를 검토해 플러그인 리소스 엔드포인트를 향한 트래버설 형태의 요청 경로를 찾는다. 거슬러 올라가야 할 시점은 10월 7일이 아니라 10월 2일이다. PoC 공개는 대규모 스캔이 시작된 시점이지, 누군가 처음 알 수 있었던 시점이 아니다. 패치되지 않고 인터넷에 노출된 인스턴스에서는 애플리케이션 루트에서 도달할 수 있는 자격 증명을 모두 노출된 것으로 보고 교체한다.

이 취약점은 10월 6일 기준으로 CISA의 Known Exploited Vulnerabilities 목록에 없었다. 허니팟 데이터를 보면 그것은 서류 절차가 따라붙는 문제일 뿐이다.

Sources: Atlassian security advisory: CVE-2026-21589 · BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release · BleepingComputer: Atlassian warns of critical file-access flaw in Jira, Confluence · watchTowr: Atlassian arbitrary file access vulnerability FAQ