Atlassian CVE-2026-21589: Jira·Confluence 등 8개 제품, PoC 공개 2시간 만에 공격 시도

무슨 일이 일어났나

Atlassian은 2026년 10월 5일(월) 자체 설치형 제품 8종에 공통으로 들어 있는 취약점 CVE-2026-21589를 공개하고 수정 버전을 배포했습니다. 로그인하지 않은 공격자가 서버 안의 파일을 읽어 갈 수 있는 결함이고, SecurityWeek에 따르면 CVSS 점수는 9.3(치명적)입니다.

영향을 받는 제품은 Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd의 Data Center 버전과 Crucible, Fisheye입니다. 개발팀 이슈 관리, 사내 위키, 소스코드 저장소, 빌드 서버, 계정 관리까지 회사 개발 인프라의 거의 전부입니다.

문제는 속도였습니다. BleepingComputer 보도에 따르면 보안 기업 watchTowr Labs가 기술 분석과 작동하는 공격 코드(PoC)를 공개했고, 그로부터 2시간 안에 보안 기업 Previdian의 허니팟(공격을 관찰하려고 일부러 열어 둔 미끼 서버)에 실제 공격 시도가 찍혔습니다.

왜 위험한가

콜론 두 개가 슬래시로 바뀌는 순간

원인은 여러 제품이 함께 쓰는 웹 리소스 라이브러리에 있습니다. 플러그인이 화면에 쓸 이미지나 스크립트를 내려주는 주소를 처리할 때, 이 라이브러리가 ::(콜론 두 개)를 /(경로 구분자)로 바꿔 버립니다.

보안 필터는 ../처럼 상위 폴더로 올라가는 문자열을 막도록 만들어져 있습니다. 그런데 요청이 들어올 때는 :: 모양이라 필터를 통과하고, 안쪽에서 /로 바뀐 뒤에야 진짜 경로가 됩니다. 경비실에서 검사를 마친 가방 안에서 물건이 모양을 바꾸는 셈입니다.

이 방식으로 공격자는 원래 공개되면 안 되는 애플리케이션 파일을 로그인 없이 받아 갈 수 있습니다.

파일 하나가 관리자 계정이 된다

SecurityWeek에 따르면 이 취약점에는 한계가 있습니다. 읽을 수 있는 범위가 웹 애플리케이션 폴더 안이고, 공격자가 파일의 정확한 경로를 미리 알아야 합니다. 폴더 목록을 둘러보는 기능은 없습니다.

그런데 Atlassian 제품은 설치 구조가 공개돼 있어서 중요한 설정 파일의 위치가 이미 알려져 있습니다. watchTowr가 보여 준 시나리오가 그렇습니다. Crowd와 연동된 Jira에서는 WEB-INF/classes/crowd.properties 파일에 애플리케이션 접속 정보가 평문으로 들어 있습니다. 이걸 읽은 뒤 Crowd API로 Jira 관리자 계정을 새로 만들 수 있었다고 BleepingComputer는 전했습니다.

"파일 읽기"라는 이름보다 실제 영향이 훨씬 크다는 뜻입니다. 관리자 권한을 얻으면 이슈에 적힌 내부 정보, 위키 문서, 소스코드에 모두 접근할 수 있습니다.

보도 시점에 따라 엇갈린 "악용 여부"

SecurityWeek 기사 시점에는 "실제 악용 증거는 없다"였습니다. 같은 날 BleepingComputer는 PoC 공개 직후 허니팟에서 공격 시도가 관측됐다고 보도했습니다. 두 보도는 모순이라기보다 시간 차이입니다. 패치 공개, PoC 공개, 공격 시도가 하루 이틀 사이에 연달아 일어났습니다.

허니팟 관측은 "공격자들이 인터넷에서 취약한 서버를 찾아 공격을 던지기 시작했다"는 신호입니다. 실제 기업 서버가 뚫렸다는 공식 확인은 아직 없습니다. 다만 Atlassian 스스로 개별 고객의 침해 여부는 알 수 없다고 밝혔기 때문에, 판단은 각 회사의 몫으로 남았습니다.

Previdian이 공개한 공격 시도 출발 IP는 3개입니다.

나에게 어떤 영향이 있는가

Atlassian Cloud 사용자

회사가 회사명.atlassian.net 주소로 Jira나 Confluence를 쓴다면 이번 영향 목록(자체 설치형 Data Center·Server 제품)에 해당하지 않습니다. 따로 할 일은 없습니다.

회사 서버에 직접 설치해 쓰는 경우

사내 서버나 자체 클라우드에 Jira, Confluence, Bitbucket을 설치해 운영한다면 바로 해당됩니다. 특히 인터넷에서 접속 가능한 인스턴스는 지금 이 순간에도 자동화된 스캔 대상이 될 수 있습니다.

일반 직원이라면

직접 서버를 관리하지 않아도 영향은 있습니다. Jira 이슈나 Confluence 문서에 비밀번호, API 키, 고객 정보를 적어 둔 적이 있다면 그 정보가 함께 노출될 수 있습니다. 당분간 회사 보안팀의 비밀번호 변경 요청이나 계정 점검 안내에 협조해 주세요.

지금 할 수 있는 대응법

서버 관리자

1. 수정 버전으로 바로 업데이트합니다. SecurityWeek가 정리한 수정 버전은 아래와 같습니다. 사용 중인 버전 계열에 맞는 번호 이상으로 올리면 됩니다.
2. 당장 패치가 어렵다면 인터넷 연결부터 끊습니다. Atlassian은 패치 전까지 외부 접속을 막으라고 권고했습니다. VPN 뒤로 옮기는 것만으로도 자동 스캔은 피할 수 있습니다.
3. 임시 차단 규칙을 겁니다. WAF나 프록시에서 Atlassian이 지정한 경로 조작 패턴을 막고, Confluence·JSM·Jira·Bamboo·Crowd는 Tomcat RewriteValve 규칙, Bitbucket은 URL 재작성 규칙을 적용할 수 있습니다. 어디까지나 패치 전까지의 임시 조치입니다.
4. Crowd 연동 자격증명을 교체합니다. crowd.properties에 들어 있던 애플리케이션 비밀번호는 이미 읽혔다고 가정하고 바꿉니다.
5. 관리자 계정 목록을 점검합니다. 10월 5일 이후 새로 생긴 관리자 계정, 처음 보는 Crowd API 호출을 확인합니다.
6. 로그에서 흔적을 찾습니다. 웹 리소스 경로에 ::가 반복되는 요청, 위 표의 IP에서 온 접속 기록을 검색합니다.

일반 사용자

1. Jira·Confluence에 적어 둔 비밀번호나 API 키가 있다면 지우고, 해당 키는 새로 발급합니다.
2. 회사 보안팀의 계정 점검 안내가 오면 미루지 말고 처리합니다.
3. "Jira 계정이 잠겼다"는 식의 메일이 오면 링크를 누르지 말고 평소 쓰는 주소로 직접 접속해 확인합니다. 큰 취약점이 알려진 직후에는 이를 미끼로 삼은 피싱이 늘어납니다.

패치 공개에서 공격 시도까지 걸린 시간은 이틀이 채 안 됐습니다. PoC가 나온 뒤로는 2시간이었습니다. "다음 정기 점검 때 올리자"는 판단이 통하지 않는 유형의 취약점입니다.

참고

• BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release
• SecurityWeek: Atlassian Patches Critical Vulnerability Affecting 8 Products
• watchTowr Labs: CVE-2026-21589 Atlassian Data Center and Server Products Vulnerability