토큰 없이도 문이 열렸다는 보고 — Artifactory CVE-2026-42018, 인증 자체가 흔들린 경우의 대응 순서

이미지 출처: CISA KEV

바이너리 저장소를 운영해 본 사람이라면 아는 감각이 하나 있음. 개발자들은 저장소를 "그냥 파일이 있는 곳"으로 생각하지만, 실제로는 회사 전체 빌드가 매일 수백 번씩 신뢰를 걸고 들어가는 관문이라는 것. 그 관문에서 이번에는 '권한을 잘못 줬다'가 아니라 '누구인지 확인하는 단계 자체가 제대로 작동하지 않았다'는 보고가 나옴. NVD에 등록된 CVE-2026-42018, JFrog Artifactory의 Improper Authentication(부적절한 인증) 취약점임.

핵심 요약

• CVE-2026-42018은 Artifactory에서 인증 검증이 불완전하게 이뤄져, 정상적인 자격 증명 없이도 보호된 기능에 닿을 수 있는 유형의 결함임(CWE-287 계열).
• 인가(무엇을 할 수 있나) 문제였던 CVE-2026-42016과 달리 이번엔 인증(누구인가) 단계의 결함이라, 영향 범위가 더 넓게 잡힐 수 있음.
• 대응 순서는 벤더 패치 적용 → 외부 노출 차단 → 접근 로그에서 '주체 없는 요청' 추적 → 토큰·자격 증명 재발급 순으로 잡는 것을 권함.

1. 인가 취약점과 인증 취약점, 무엇이 다른가

같은 제품에서 비슷한 시기에 번호가 붙은 취약점이 두 개 있다 보니 혼동하기 쉬움. 짧게 정리하면 이렇게 됨.

• 인증(Authentication): "너 누구야?"를 확인하는 단계. 아이디/비밀번호, 액세스 토큰, API 키, SSO 세션이 여기에 해당함.
• 인가(Authorization): 확인된 사용자가 "그걸 해도 되는가"를 판단하는 단계. 저장소별 읽기/쓰기 권한, 관리자 기능 접근 여부 등.

인가 결함은 '이미 로그인한 누군가'가 전제이므로, 최소한 내부 계정 하나는 있어야 함. 반면 인증 결함은 그 전제조차 무너뜨림. 계정이 없거나, 만료된 토큰이거나, 아예 빈 자격 증명으로도 특정 경로에서 인증된 것처럼 처리될 수 있다는 뜻임. 그래서 같은 "Improper"라는 단어가 붙어 있어도 방어자가 잡아야 할 우선순위는 인증 쪽이 한 단계 위라고 개인적으로는 봄.

2. 이 결함이 왜 아티팩트 저장소에서 유독 아픈가

Artifactory는 단순 파일 서버가 아님. Maven, npm, PyPI, Docker, Helm 등 수십 종의 패키지 프로토콜을 하나의 게이트웨이로 흡수하는 구조임. 문제는 각 프로토콜이 자격 증명을 전달하는 방식이 제각각이라는 점.

• 어떤 클라이언트는 Basic 인증 헤더로, 어떤 클라이언트는 Bearer 토큰으로, 어떤 클라이언트는 프로토콜 고유의 핸드셰이크로 신원을 넘김.
• 이 다양한 경로를 하나의 인증 계층이 받아내다 보니, 특정 경로에서만 검증이 느슨해지는 틈이 생기기 쉬움. 예를 들어 익명 접근이 허용된 저장소와 그렇지 않은 저장소를 구분하는 로직, 토큰의 서명·만료·발급자를 검증하는 로직 중 한 군데만 빠져도 결과는 "인증 없이 통과"가 됨.
• 저장소가 뚫리면 다음 단계는 뻔함. 빌드 서버가 그 저장소에서 받아 가는 의존성에 손을 대거나, 캐시된 원격 아티팩트를 바꿔치기하거나, 프라이빗 소스가 담긴 패키지를 그대로 내려받는 것. 공급망 공격의 출발점으로 이보다 좋은 자리가 없음.

정확한 영향 버전과 점수는 벤더 공지와 NVD 페이지를 기준으로 확인해야 하고, 여기서는 '어떤 유형의 위험이며 무엇부터 봐야 하는가'에 집중함.

3. 방어자가 밟아야 할 순서

순서가 중요함. 로그부터 뒤지다가 패치를 미루면 조사하는 동안에도 문은 열려 있는 셈이라, 아래 순서를 추천함.

① 패치 적용 여부부터 확정

• JFrog 보안 권고에서 CVE-2026-42018이 수정된 버전을 확인하고, 운영 중인 인스턴스 버전과 대조함. 셀프호스팅이라면 업그레이드 창을 잡고, SaaS라면 벤더 측 적용 완료 공지를 확인함.
• HA 구성이면 노드 전체가 같은 버전인지 반드시 확인. 한 노드만 구버전이면 로드밸런서가 그쪽으로 보내는 순간 의미가 없어짐.

② 즉시 패치가 어렵다면 노출면 줄이기

• Artifactory가 인터넷에 직접 열려 있는지 확인. 개발 편의 때문에 공인 IP로 열어 둔 경우가 생각보다 많음. VPN이나 사내망으로 제한하고, 리버스 프록시에서 허용 경로를 화이트리스트로 좁힘.
• 익명 접근(Anonymous Access)이 켜져 있다면 이번 기회에 끄는 것을 검토. 익명 허용 자체가 취약점은 아니지만, 인증 결함과 결합하면 판단 로직을 더 헷갈리게 만드는 요인이 됨.

③ 로그에서 '주체가 비어 있는 요청' 찾기

• access.log, request.log, 그리고 access 서비스의 감사 로그를 함께 봄. 주목할 패턴은 사용자명이 비어 있거나 anonymous로 찍혔는데 보호된 저장소에 성공(2xx) 응답이 남은 기록임.
• 특정 IP나 User-Agent가 짧은 시간에 여러 저장소를 훑고 지나간 흔적, 평소 쓰지 않는 프로토콜 엔드포인트로 들어온 요청, 업무 시간 밖의 대량 다운로드도 같이 확인.
• SIEM으로 로그를 보내고 있다면 위 조건을 탐지 룰로 굳혀 두는 것을 권함. 이번 CVE가 끝나도 인증 계층의 이상 징후를 잡는 룰은 계속 쓸모가 있음.

④ 자격 증명과 아티팩트 무결성 점검

• 인증 우회 가능성이 있었던 기간에 발급·사용된 액세스 토큰과 API 키는 전부 회전(rotation)하는 것이 안전함. 특히 CI/CD 파이프라인에 박혀 있는 서비스 계정 토큰을 빼먹기 쉬움.
• 중요 저장소의 아티팩트 체크섬을 빌드 시점 기록과 대조. 바꿔치기 흔적이 없는지 확인하는 것이 공급망 관점에서 가장 중요한 마무리임.

4. 개념 수준에서 본 공격자의 움직임

실행 가능한 절차는 다루지 않지만, 방어자가 시나리오를 그려 보는 건 필요함. 공격자는 먼저 인터넷에 노출된 Artifactory 인스턴스를 찾고, 인증이 느슨하게 처리되는 특정 엔드포인트나 프로토콜 경로를 골라 접근을 시도함. 성공하면 조용히 목록을 훑어 내부 패키지명, 버전 체계, 의존성 구조를 먼저 파악하고, 그 다음에야 값어치 있는 아티팩트를 내려받거나 변조를 시도함. 그러니 탐지 룰도 '대량 다운로드'만이 아니라 '탐색 단계의 목록 조회'까지 잡을 수 있게 설계하는 편이 좋음.

마무리

CVE-2026-42016을 다뤘던 글에서 "저장소가 누구를 믿었는가"를 이야기했다면, 이번 글은 그보다 앞선 질문임. 믿기 전에 누구인지 제대로 물어봤는가. 인증 결함은 화려하지 않지만 뚫리면 뒤에 있는 모든 방어가 의미를 잃는 자리라, 패치 우선순위를 높게 잡는 걸 개인적으로는 강하게 추천함. 여러분 조직의 Artifactory는 어디에 열려 있고, 익명 접근은 켜져 있는지 오늘 한 번만 확인해 보길 바람. 점검하다가 막히는 부분이나 다른 탐지 아이디어가 있으면 댓글로 나눠 주세요. 같이 정리해 보아요!