빌드 서버가 믿는 창고, 그 창고는 누구를 믿었나 — JFrog Artifactory 인가 오류(CVE-2026-42016) 방어 노트

이미지 출처: CISA KEV

개발팀이 아침에 커밋을 올리면 CI가 돌고, 빌드 결과물은 Artifactory에 차곡차곡 쌓임. 배포 서버는 그 창고에서 파일을 꺼내 쓰고, 개발자들은 npm이나 Maven, Docker 이미지를 거기서 받아옴. 이 창고 하나가 조직 전체의 코드 흐름을 떠받치고 있는데, 정작 그 창고가 "이 사람이 이 저장소를 만져도 되는가"를 잘못 판단한다면 어떻게 될까. CVE-2026-42016은 바로 그 지점, JFrog Artifactory의 인가(Authorization) 판단이 어긋난 문제를 다루는 취약점임.

핵심 요약

• JFrog Artifactory에서 권한 검사가 잘못 적용되어(Incorrect Authorization) 사용자가 본래 허용된 범위를 넘어 리소스에 접근·조작할 수 있는 취약점임
• 아티팩트 저장소는 공급망의 중심이라, 인가 오류 하나가 빌드 산출물 오염과 내부 정보 유출로 번질 수 있음
• 대응은 패치 적용, 권한 모델 재점검, 접근 로그 기반 이상 탐지 세 가지를 같이 가져가는 것이 핵심임

1. 어떤 종류의 문제인가

이번 건은 이름부터 힌트가 있음. "인증(Authentication) 우회"가 아니라 "인가(Authorization) 오류"임. 인증은 "너 누구냐"를 확인하는 단계고, 인가는 "그래서 너 이거 해도 되냐"를 판단하는 단계임. 즉 공격자가 로그인 자체를 뚫는 게 아니라, 정상적으로 로그인한 계정이 자기 권한 밖의 것을 할 수 있게 되는 구조임. 이런 유형은 흔히 CWE-863(Incorrect Authorization) 계열로 분류되는데, 코드 어딘가에서 권한 검사를 빠뜨렸거나, 검사는 하는데 엉뚱한 기준으로 했거나, 특정 경로만 검사가 느슨하게 걸려 있는 식으로 나타남.

Artifactory 맥락에서 생각해보면 위험한 시나리오는 대충 이런 것들임.

• 읽기 권한만 받은 외주 개발자 계정이 특정 저장소에 쓰기·삭제를 할 수 있게 됨
• 프로젝트 A에만 접근이 허용된 계정이 프로젝트 B의 내부 아티팩트나 메타데이터를 열람함
• 권한 관리 API나 특정 엔드포인트를 통해 원래 관리자만 할 수 있는 설정 조회·변경이 가능해짐

개인적으로 인가 오류 취약점을 볼 때마다 느끼는 건, 이게 RCE처럼 화려하지 않아서 우선순위에서 밀리기 쉬운데 공급망 도구에서는 오히려 더 무섭다는 점임. 빌드 산출물 하나를 바꿔치기하면 그걸 받아가는 모든 서버와 개발자 PC가 영향을 받으니까 말임.

2. 왜 아티팩트 저장소에서 유독 위험한가

보통 웹 서비스의 인가 오류는 "남의 데이터를 봤다" 수준에서 끝나는 경우가 많음. 그런데 Artifactory는 다름. 여기 저장된 건 단순 데이터가 아니라 실행될 코드임. 라이브러리, 컨테이너 이미지, 설치 패키지 같은 것들이 CI/CD 파이프라인을 타고 그대로 운영 환경까지 흘러감. 그래서 권한을 넘어선 쓰기가 가능해지면 다음 같은 연쇄가 이론적으로 가능함.

• 내부 라이브러리 버전에 변조된 파일을 덮어씀 → 다음 빌드부터 모든 서비스에 포함됨
• 도커 베이스 이미지 태그를 오염시킴 → 신규 배포되는 컨테이너 전체에 영향
• 저장소 설정이나 원격 프록시 설정을 바꿈 → 외부에서 가져오는 패키지 출처 자체가 바뀜

읽기 방향도 가볍지 않음. 내부 전용 패키지에는 회사 도메인 구조, 내부 API 주소, 가끔은 하드코딩된 설정값까지 들어 있는 경우가 많아서, 정찰 단계에서 이만한 정보원이 없음. 그러다보니 인가 오류 하나가 "정보 유출 → 표적 선정 → 산출물 변조"로 이어지는 출발점이 될 수 있다는 걸 염두에 두는 게 좋을 것 같음.

3. 방어자가 먼저 할 일: 패치와 노출면 정리

순서를 정리하면 이렇게 가는 걸 추천함.

• 버전 확인과 업데이트: JFrog 보안 공지에서 이번 CVE가 수정된 버전을 확인하고 그 이상으로 올림. Self-hosted 환경이라면 관리자 UI 또는 시스템 정보 API로 현재 버전을 먼저 파악함. SaaS 환경은 벤더가 처리하지만, 자체 설치형은 직접 챙겨야 함
• 외부 노출 여부 점검: Artifactory가 인터넷에 직접 열려 있는지 확인함. 인가 오류는 "로그인한 사용자"가 전제라 해도, 셀프 가입이 켜져 있거나 익명 접근이 허용돼 있으면 사실상 아무나 조건을 만족하게 됨. 익명 접근(Anonymous Access)이 정말 필요한지 이 기회에 다시 물어볼 것
• 임시 완화: 즉시 패치가 어렵다면 리버스 프록시나 WAF 단에서 관리 API 경로에 대한 접근을 내부망·특정 IP로 제한하고, 권한이 낮은 계정의 쓰기 작업을 잠시 막는 것도 방법임

4. 권한 모델 자체를 다시 보기

패치는 이번 구멍을 메우는 것이고, 권한 모델 점검은 다음 구멍이 생겨도 피해를 줄이는 것임. Artifactory에는 사용자, 그룹, 퍼미션 타겟(Permission Target), 프로젝트 단위 역할 같은 계층이 있는데 운영하다보면 이게 차차 꼬여감. 아래 항목을 한 번씩 훑어보는 걸 권함.

• 퍼미션 타겟에 "모든 저장소(Any Repository)"로 걸린 권한이 있는지 — 있다면 정말 필요한지 확인
• CI 서비스 계정이 배포 권한(Deploy)과 삭제 권한(Delete)을 함께 갖고 있는지 — 삭제·덮어쓰기는 별도 계정으로 분리하는 편이 안전함
• 오래된 액세스 토큰과 API 키 — 만료 없이 발급된 토큰은 인가 오류와 결합하면 위력이 커짐. 주기적으로 회전시킬 것
• 관리자 계정 수 — 편의상 admin을 나눠 쓰고 있다면 개인 계정 + 최소 권한으로 정리
• 릴리즈 저장소의 덮어쓰기 금지(immutable) 설정 — 같은 버전에 재업로드가 안 되게 막아두면 변조 시나리오 상당수가 차단됨

5. 탐지: 어떤 로그를 보면 되는가

인가 오류는 익스플로잇 흔적이 화려하지 않음. 정상 로그인, 정상 요청처럼 보이는데 "이 계정이 이걸 했다는 게 이상하다"는 맥락으로만 잡힘. 그래서 로그를 계정·권한 관점으로 봐야 함.

• access.log / request.log: 읽기 전용이어야 할 계정에서 PUT·DELETE 요청이 나갔는지, 특정 계정이 평소 접근하지 않던 저장소 경로를 건드렸는지 확인
• 권한 변경 이벤트: 퍼미션 타겟 생성·수정, 그룹 멤버 추가, 토큰 발급 이벤트를 SIEM으로 보내고 관리자 외 계정에서 발생하면 알림
• 아티팩트 무결성: 릴리즈 산출물의 체크섬을 빌드 시점에 별도 저장해 두고, 저장소 내 체크섬과 주기적으로 비교. 서명(예: 컨테이너 이미지 서명)을 도입했다면 검증 실패 이벤트를 놓치지 말 것
• 비정상 시간대·출처: 서비스 계정이 평소와 다른 IP나 시간대에서 활동하는 패턴

이미 노출된 기간이 있었다면, 패치 이전 로그를 위 기준으로 한 번 되돌아보는 게 좋음. 특히 릴리즈 저장소에 덮어쓰기가 있었는지, 권한 관련 설정 변경이 있었는지 두 가지는 꼭 확인해 볼 것.

6. 정리하며

이번 취약점의 교훈은 사실 Artifactory에만 해당하는 게 아님. 빌드 서버가 창고를 믿고, 창고는 계정을 믿고, 계정은 권한 시스템을 믿는 구조에서 한 고리의 판단이 틀리면 신뢰가 통째로 옮겨간다는 점임. 패치는 당연히 하되, 이참에 "우리 저장소에서 누가 무엇을 쓸 수 있는가"를 표로 한 번 그려보는 걸 개인적으로 추천함. 막상 그려보면 생각보다 넓게 열려 있어서 놀라는 경우가 많더라고요. 여러분 환경에서는 어떤 식으로 아티팩트 권한을 관리하고 계신지, 좋은 방법이 있으면 댓글로 나눠 주세요. 같이 정리해 보아요.