저장소 경로 한 칸을 벗어나면 — Artifactory가 걸러내지 못한 파일명

이미지 출처: CISA KEV

사내 빌드 파이프라인에서 아티팩트 저장소는 늘 조용한 존재입니다. 젠킨스가 돌고, 이미지가 올라가고, 개발자들은 npm install 한 줄로 그걸 내려받죠. 아무도 저장소 자체를 의심하지 않습니다. 그런데 그 저장소가 "파일을 어디에 저장할지"를 사용자가 준 문자열로 결정하고 있다면 어떨까요. CVE-2026-66384는 바로 그 지점, JFrog Artifactory가 경로 문자열을 지정된 디렉터리 안으로 제대로 가두지 못한 문제로 등록되어 있습니다.

핵심 요약

• JFrog Artifactory에서 파일 경로가 지정된 저장소 디렉터리 밖으로 벗어날 수 있는 결함(경로 제한 미흡, CWE-22 계열)이 보고됨
• 아티팩트 저장소는 CI/CD의 상류에 있어, 임의 위치 쓰기·읽기가 성립하면 곧바로 공급망 오염으로 번짐
• 방어는 버전 업데이트가 우선이고, 그 전까지는 업로드 경로에 대한 로깅·역프록시 필터·저장소 권한 최소화로 시간을 벌 수 있음

이 취약점이 말하는 것

이름이 길어서 어렵게 보이지만 뜯어보면 단순함. "Improper Limitation of a Pathname to a Restricted Directory"는 흔히 경로 탐색(Path Traversal)이라 부르는 그 문제임. 프로그램이 기준 디렉터리를 정해두고 그 아래에만 파일을 두려 했는데, 입력으로 들어온 이름에 상위 디렉터리를 가리키는 조각이 섞여 있어 결과적으로 기준 밖으로 빠져나가는 상황.

Artifactory 맥락에서 특히 아픈 이유는 이 제품이 하는 일 자체가 "임의의 이름을 가진 파일을 받아서 디스크에 얹는 것"이기 때문임. 패키지 이름, 버전 문자열, 아카이브 내부 엔트리 이름까지 전부 외부에서 들어오는 데이터. 그중 어느 하나라도 정규화 전에 경로 조립에 쓰이면 저장 위치가 흔들림.

왜 아티팩트 저장소가 특히 위험한가

일반 웹 애플리케이션에서 경로 탐색이 터지면 설정 파일이 새는 정도로 끝나는 경우가 많습니다. 하지만 저장소는 위치가 다릅니다. 수백 대의 빌드 서버와 배포 대상이 이 한 곳을 신뢰하고 물건을 받아가는 구조거든요.

• 저장소가 관리하는 영역 밖에 파일이 놓이면, 애플리케이션 설정이나 기동 스크립트가 조용히 바뀔 수 있음
• 반대로 읽기 방향이면 저장소 내부 자격증명·라이선스·토큰 파일이 노출될 여지
• 무엇보다 다른 저장소(repo) 영역으로 넘어가는 경로가 성립하면, A 팀 권한으로 B 팀 아티팩트를 덮어쓰는 그림이 나옴

마지막 항목이 개인적으로는 제일 무섭다고 봅니다. 외부 인터넷에 노출되지 않았으니 괜찮다고들 하시는데, 이런 결함은 내부 사용자 한 명의 업로드 권한만으로도 경계를 넘게 만들거든요.

공격은 개념적으로 이렇게 성립함

재현 코드를 늘어놓을 이유는 없고, 원리만 정리하면 이렇게 됨.

• 공격자는 정상적으로 인증된 업로드 경로를 사용함. 여기까지는 감사 로그상 평범한 배포로 보임
• 파일명 또는 저장 대상 경로에 해당하는 필드에, 기준 디렉터리를 벗어나는 상대 경로 조각을 끼워넣음
• 서버가 그 문자열을 정규화(canonicalize)하지 않고 그대로 이어붙이면, 최종 저장 위치가 의도한 저장소 밖이 됨
• 변형으로는 URL 인코딩된 구분자, 이중 인코딩, 압축 파일 내부 엔트리 이름을 이용하는 방식이 알려져 있음

핵심은 "인증을 뚫는 문제가 아니다"라는 점. 이미 들어온 사용자가 자기 몫보다 넓은 범위를 만지게 되는 권한 경계의 문제임. 그래서 로그를 봐도 인증 실패가 안 찍힘.

어떻게 탐지할 것인가

이런 유형은 실패한 로그인처럼 눈에 띄는 신호를 남기지 않기 때문에, 볼 곳을 미리 정해두는 게 중요함.

• 요청 URI와 업로드 파일명에서 상위 경로 패턴을 찾음. 문자 그대로의 형태뿐 아니라 퍼센트 인코딩·이중 인코딩 변형까지 정규화한 뒤 매칭해야 함
• Artifactory 접근 로그에서 PUT 계열 요청의 대상 경로가 저장소 이름 규칙을 벗어나는 케이스를 뽑아 봄. 정상 배포는 경로 형태가 대체로 일정하기 때문에 이탈이 드러남
• 파일시스템 쪽에서는 데이터 디렉터리 바깥에 Artifactory 프로세스 소유로 새 파일이 생기는지 감시. 무결성 모니터링(FIM) 규칙 한 줄이면 됨
• 배포되지 않은 시간대의 쓰기, 그리고 같은 계정이 평소 쓰지 않던 저장소 영역을 건드리는 패턴도 좋은 신호

완화는 이 순서로

순서를 뒤집지 않는 게 좋습니다. 우회 규칙부터 만들다가 정작 패치가 밀리는 경우를 여러 번 봤거든요.

• 벤더가 공지한 수정 버전으로 올리는 것이 1순위. 경로 정규화 결함은 필터링으로 완전히 막기 어려운 종류라서, 우회 규칙은 어디까지나 시간 벌기임
• 앞단 역프록시에서 경로 정규화 후 상위 참조가 남는 요청을 차단. 정규화 이전에 매칭하면 인코딩 변형에 그대로 뚫림
• 업로드 권한을 저장소 단위로 최소화. "배포용 계정 하나로 전부 올린다"는 구조는 이런 결함이 나올 때마다 피해 범위를 최대로 만듦
• Artifactory 프로세스를 전용 계정으로 돌리고, 데이터 디렉터리 밖 쓰기 권한을 OS 차원에서 제거. 애플리케이션 버그가 파일시스템 경계까지 뚫지는 못하게 막는 이중 방어
• 관리 콘솔과 업로드 엔드포인트를 사내망·VPN 뒤로 두기. 노출 면적을 줄이는 건 언제 해도 손해가 아님

점검할 때 같이 보면 좋은 것들

• 익명 사용자(anonymous)의 읽기·쓰기 권한이 살아 있는지
• 더 이상 쓰지 않는 원격 저장소·프록시 설정이 남아 있는지
• 백업 파일과 시스템 export 산출물이 웹 경로에서 접근 가능한 위치에 있지는 않은지
• 배포 계정 토큰의 만료 정책과 회전 주기

정리하며

경로 탐색은 90년대부터 있던 문제인데도 여전히 매년 새 CVE로 올라옵니다. 문자열을 이어붙이는 코드가 계속 새로 쓰이는 한 사라지지 않을 것 같기도 하고요. 다만 이번처럼 공급망의 상류에 있는 제품에서 나오면 무게가 달라집니다. 내 서버 한 대의 문제가 아니라, 그 저장소에서 물건을 받아가는 모든 시스템의 문제가 되니까요.

오늘 저녁에 사내 Artifactory 버전 한 번 확인해 보시고, 접근 로그에서 업로드 경로 패턴만이라도 훑어보시는 걸 추천드립니다. 저도 이번 주에 저희 쪽 저장소 권한 정리를 다시 해볼 생각입니다. 같이 점검해보아요. 각자 환경에서 발견한 것들 있으면 댓글로 공유해주시면 좋겠습니다.