Jira·Confluence 서버의 파일, 바깥에서 얼마나 보이고 있을까? Atlassian CVE-2026-21589 점검 기록

이미지 출처: CISA KEV

접근 로그를 넘기다 보면 가끔 눈에 걸리는 줄이 있음. 응답 코드는 200이고 응답 크기는 수십 KB인데, 요청 경로를 보면 정적 리소스도 아니고 평소에 보던 REST API도 아닌 그런 줄. 그냥 넘겼다가 나중에 보니 서버 안쪽 파일이 그대로 밖으로 나간 흔적이었던 경우가 생각보다 많은 것 같다. 이번 Atlassian CVE-2026-21589이 바로 이런 종류라서, 탐지와 완화 위주로 정리해 봄.

핵심 요약

• CVE-2026-21589는 여러 Atlassian 제품에서 외부에 노출되면 안 되는 파일이나 디렉터리에 바깥에서 접근할 수 있게 되는 취약점(CWE-552 계열)임
• 설정 파일, 내부 경로, 자격증명 단서가 새어 나가면 다음 단계 공격의 발판이 되기 때문에 '정보 노출일 뿐'이라고 넘기면 안 됨
• 벤더 패치 적용이 1순위이고, 그 전까지는 외부 노출 차단, 리버스 프록시 경로 제한, 접근 로그 소급 점검을 병행해야 함

1. 어떤 취약점인지 한 줄로

이름 그대로 "외부 당사자가 접근할 수 있는 파일 또는 디렉터리" 문제임. 애플리케이션이 내부용으로 쓰는 파일을, 인증이나 경로 검증을 충분히 거치지 않은 채 웹 요청으로 내어주는 구조적 결함이라고 보면 됨.

• 영향 대상은 Atlassian의 여러 제품군으로 묶여 있음. 사내에서 많이 쓰는 Jira, Confluence 같은 셀프 호스팅(Data Center/Server) 환경이 주로 관심 대상임
• 정확한 영향 버전과 수정 버전은 Atlassian 보안 권고문 기준으로 확인해야 함. 제품마다 수정 버전 라인이 다르게 나오는 경우가 많아서 "우리 Jira는 괜찮았으니 Confluence도 괜찮겠지"라고 생각하면 안 됨
• CISA KEV 형식의 이름이 붙은 건 실제 악용 정황이 확인됐다는 뜻이라서, 일반 패치 주기보다 앞당겨 처리할 항목임

2. 파일 몇 개 보이는 게 왜 위험한가

처음엔 나도 "코드 실행도 아니고 파일 읽기 정도면…" 하고 우선순위를 낮게 잡았던 적이 있음. 근데 실제 침해 사례를 따라가 보면 정보 노출이 첫 단추인 경우가 정말 많았음.

• 설정 파일: DB 연결 정보, 외부 연동 토큰, 내부 호스트명이 들어 있을 수 있음
• 내부 경로·버전 정보: 공격자가 다음에 쓸 취약점을 고르는 지도가 됨
• 첨부파일·내보내기 산출물: Jira 이슈나 Confluence 페이지에 붙은 문서 자체가 민감 정보인 경우가 많음
• 세션·캐시 관련 파일: 경우에 따라서는 계정 탈취 쪽으로 이어질 여지도 있음

그러니까 이 취약점은 단독으로 끝나는 게 아니라 연쇄 공격의 정찰 단계를 공짜로 열어주는 것이라고 이해하는 게 맞는 것 같음.

3. 우리 서버가 당했는지 확인하는 방법

공격 재현을 해볼 필요까지는 없고, 방어자 입장에서는 로그를 보는 게 훨씬 현실적임.

• 리버스 프록시·WAF 로그 소급: 취약점 공개 시점 전후로, 평소 쓰지 않는 경로에 대한 200 응답을 뽑아봄. 특히 인증 쿠키 없는 요청인데 응답 크기가 큰 건 우선 확인 대상임
• 요청 패턴 이상치: 짧은 시간에 같은 IP가 경로만 바꿔가며 연속 요청한 흔적은 자동화 스캐너일 확률이 높음
• 애플리케이션 로그: Atlassian 제품의 access log, 그리고 Tomcat 로그를 같이 봐야 프록시에서 빠진 부분이 보임
• 노출됐을 수 있는 비밀값 목록화: 설정 파일이 나갔을 가능성이 조금이라도 있으면, 그 안에 있던 DB 비밀번호, API 토큰, 연동 계정은 교체 대상으로 바로 분류함

4. 완화 순서

개인적으로는 아래 순서로 처리하는 걸 추천함. 패치가 제일 확실하지만 운영 환경은 바로 재기동이 어려운 경우가 많아서 그 사이를 메워줄 조치가 꼭 필요했음.

• 1단계 – 노출면 줄이기: 인터넷에 직접 열려 있는 인스턴스라면 VPN이나 SSO 게이트웨이 뒤로 숨기는 것부터 함
• 2단계 – 프록시 경로 제한: 리버스 프록시에서 업무상 필요한 경로만 허용하고, 나머지 내부 리소스 경로는 차단하는 허용 목록 방식으로 바꿈
• 3단계 – 벤더 패치: 권고문에 나온 수정 버전으로 업그레이드함. 제품별로 따로 확인하는 거 잊지 말기
• 4단계 – 비밀값 교체: 노출 가능성이 있었던 자격증명은 패치 후에 반드시 바꿈. 패치는 문을 닫는 거지 이미 나간 정보를 회수해주지는 않기 때문임
• 5단계 – 탐지 규칙 남기기: 이번에 찾은 이상 패턴을 SIEM 규칙으로 남겨두면 비슷한 유형이 또 나왔을 때 훨씬 빨리 대응할 수 있음

5. 정리하며

Atlassian 제품은 회사의 업무 기록이 전부 모이는 곳이다 보니, 파일 하나가 새어 나가는 것만으로도 생각보다 많은 게 드러나는 것 같다. "읽기만 되는 취약점"이라는 말에 마음 놓지 말고, 패치하고, 로그 다시 보고, 비밀값 바꾸는 것까지 한 세트로 묶어서 처리해 보셨으면 함. 혹시 운영하면서 이 건 때문에 이상한 로그를 발견했거나 프록시 차단 규칙을 어떻게 잡았는지 공유해 줄 수 있는 분이 있다면 댓글로 남겨주세요. 같이 보면서 더 단단하게 막아보아요!