JFrog Artifactory 키 인증 우회 취약점 (CVE-2026-82329)

NOW Briefing

Brief 1 JFrog Artifactory 자체 호스팅 버전에서 인증 없이 관리자 권한을 얻을 수 있는 인증 우회 취약점(CVE-2026-82329)이 공개됐습니다. 별도 설정을 바꾸지 않은 기본 상태의 인스턴스가 영향을 받습니다.

Brief 2 패치 공개 나흘 뒤인 9월 1일, 위협 인텔리전스 업체 watchTowr의 미끼 시스템(허니팟)에서 실제 공격 활동이 관측됐습니다. 관측된 활동에서 공격자는 관리자 토큰을 발급받아 사용자·그룹·자격증명 세트와 연합 접근 구성을 열거했고, 이 취약점은 미국 사이버보안·인프라보안국(CISA)의 악용 확인 취약점 목록(KEV)에도 등재됐습니다.

Brief 3 사용 중인 릴리스 브랜치에 맞는 패치 버전으로 즉시 업그레이드하고, 노출 이력이 있는 인스턴스는 관리자 토큰 발급 내역과 자격증명 사용·변경 이력을 점검한 뒤 관련 토큰과 자격증명을 재발급해야 합니다.

‍

JFrog Artifactory 키 인증 우회 취약점 (CVE-2026-82329)

‍

■ 개요

‍

JFrog Artifactory는 빌드 결과물과 외부 라이브러리를 한곳에 모아 관리하는 바이너리 아티팩트 저장소로, 기업 CI/CD(빌드·배포 자동화 파이프라인)의 중심에 놓이는 제품입니다. 국내에서도 SLEXN(슬렉슨)과 CURVC(커브)가 자사 제품 페이지에서 JFrog Platform 제품군을 공급 제품으로 소개하고 있습니다. CVE-2026-82329는 미인증 공격자가 네트워크 접근만으로 관리자 권한을 획득할 수 있는 취약점입니다.

벤더 문서 기준으로 이 취약점은 기본 설정 상태에서 성립하며, 유효한 자격증명이 필요하지 않습니다. 영향 대상은 자체 호스팅(self-hosted) 배포판이고, JFrog는 클라우드 환경의 경우 이미 조치돼 사용자 조치가 필요하지 않다고 밝혔습니다.

JFrog는 2026년 8월 28일 6개 릴리스 브랜치의 패치와 보안 권고를 공개했습니다. 공개 보도에 따르면 9월 1일 watchTowr가 자사 허니팟에서 실제 공격 활동을 관측했고, 같은 보고는 대규모 스캐닝과 대량 악용이 아직 나타나지 않았다고 밝혔습니다. 9월 2일에는 CISA가 이 취약점을 KEV 목록에 등재했습니다. 동작이 확인된 공개 PoC 코드도 있으므로, 인터넷에 노출된 인스턴스는 패치 우선순위를 최상위로 두어야 합니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-82329 (기본 설정에서 빈 조인 키가 신뢰 목록에 포함되는 인증 우회)
CVSS 점수	CVSS v3.1 9.8
취약점 유형	CWE-287, 인증 없이 성립하는 인증 우회
영향/위험	• 인증 없이 네트워크 접근만으로 관리자 권한 획득 가능(벤더 문서 기준) • watchTowr 허니팟 관측 기준, 공격자가 관리자 토큰을 발급하고 사용자·그룹·자격증명 세트·연합 접근 구성을 열거함 • 관리자 권한 확보 시 빌드 파이프라인 변조와 하위 배포 영향 가능성을 연구진이 지적함 • CISA KEV 등재(2026-09-02), 조치 기한 2026-09-05
취약 버전	• 7.161.0~7.161.19 • 7.146.0~7.146.36(벤더 권고) / 7.146.0~7.146.37(NVD) • 7.133.0~7.133.28 • 7.125.0~7.125.19 • 7.117.0~7.117.27 • 7.111.4~7.111.21(벤더 권고, 상단이 패치 버전과 겹침) / 7.111.4~7.111.20(NVD)
패치 버전	• 7.161.20 • 7.146.38 • 7.133.29 • 7.125.20 • 7.117.28 • 7.111.21

‍

■ 기술 분석

‍

Artifactory는 여러 서비스 노드가 하나의 플랫폼으로 묶일 때 조인 키(join key, 노드끼리 서로를 신뢰할 때 사용하는 공유 비밀값)를 쓰고, 인증 컴포넌트인 JFrog Access는 노드가 제시한 서명 토큰(JWT)을 이 조인 키로 검증합니다. 원인은 신뢰할 조인 키 목록을 구성하는 과정에 있습니다. 추가 조인 키 설정이 비어 있는 기본 상태에서는 빈 문자열이 걸러지지 않고 그대로 신뢰 목록에 들어가며, 빈 값에서 파생된 서명 키는 32바이트가 모두 0x20인 고정값이 됩니다. 서명 비밀값이 공개된 것과 다름없으므로 토큰 위조를 막을 수 없습니다.

공개된 연구자 분석 문서는 artifactory-oss 7.161.19(JFrog Access 7.191.11)와 7.161.20(Access 7.191.14) 빌드에서 Access 관련 클래스를 추출·역컴파일해 비교하고, 신뢰 목록을 만드는 JoinKeyAccess.tryResolveJoinKeys()의 변경 지점을 정리했습니다. 아래는 그 문서에 실린 해당 변경 부분으로, - 줄이 취약 버전, + 줄이 패치 버전입니다. 스트림 처리에 .filter(Strings::isNotBlank) 한 단계가 추가되어 빈 값이 신뢰 목록에 들어가지 못하게 막습니다.

-  Arrays.stream(joinKey.get().split(",")).map(String::trim).forEach(jKey -> {
+  Arrays.stream(joinKey.get().split(",")).map(String::trim).filter(Strings::isNotBlank).forEach(jKey -> {
        JoinKeyHashPair hashPair = new JoinKeyHashPair(jKey);
        joinKeyListValuesForContext.put(hashPair.getHash(), hashPair);
        log.warn("Adding join key with kid: {} to additional join keys", hashPair.getHash());
   });

Artifactory 바이너리는 비공개이므로 위 발췌는 벤더가 공개한 공식 diff가 아니라 연구자가 역컴파일해 정리한 결과입니다. 같은 문서는 JoinKeyHashPair 생성자가 null·공백 조인 키를 거부하도록 바뀐 점, 그리고 ProjectResource의 일부 엔드포인트 권한을 SERVICE에서 ADMIN으로 올린 점도 함께 정리했습니다.

기본 설치에서는 추가 조인 키 설정이 비어 있어, 어떤 키로 검증할지 지목하는 식별자(kid)가 빈 문자열의 SHA-256(e3b0c442…b855)인 신뢰 키가 등록됩니다. 공개 PoC 기준으로, 이 키로 서명한 위조 토큰을 노드 등록 경로로 보내면 관리자 범위를 가진 서비스 토큰이 발급되고, 이어서 플랫폼 관리자 토큰으로 승격됩니다. 공개 보고에서 관측된 "관리자 토큰 발급(minting admin tokens)"이 이 결과에 해당합니다.

‍

■ PoC

‍

인증 우회의 핵심은 누구나 알 수 있는 고정된 서명 비밀값과 그 키를 지목하는 kid 값입니다. 아래 코드는 공개 PoC 스크립트의 상수 정의부로, 코드는 수정하지 않고 그대로 옮겼습니다. 전체 코드는 참고 자료에 연결한 원문에서 확인할 수 있습니다.

BLANK_SECRET = b"\x20" * 32                    # JoinKeyUtils.getSigningKey("") == pkcs7(empty,32)
BLANK_KID = hashlib.sha256(b"").hexdigest()    # kid claim selecting the trusted blank join key

공개 PoC는 대상 인스턴스의 취약 여부를 판정하고 관리자 토큰 발급까지 확인하는 파이썬 스크립트 형태입니다. 작성자는 취약 버전 7.161.19와 패치 버전 7.161.20을 각각 대상으로 동작을 비교 검증(A/B)했다고 밝혔습니다. 외부 라이브러리 없이 파이썬 표준 라이브러리만으로 동작하며, 유효한 계정 자격증명 없이 실행됩니다.

⚠️ WARN

동작이 확인된 PoC 코드가 이미 공개돼 있고 실제 악용도 보고됐습니다.
패치 적용 전까지 인터넷에서 접근 가능한 인스턴스는 네트워크 차단으로 노출을 먼저 끊어야 합니다.

‍

■ 탐지 및 점검

‍

• 운영 중인 Artifactory의 정확한 버전을 확인해 해당 브랜치의 패치 버전 미만인지 판별합니다. 벤더 권고와 NVD의 영향 범위가 갈리는 브랜치가 있으므로, artifactory@7.146.36과 artifactory@7.146.37, artifactory@7.111.20과 artifactory@7.111.21은 모두 패치 여부를 별도로 확인하고, 해당 브랜치는 각각 artifactory@7.146.38, artifactory@7.111.21 이상으로 맞추는 것이 안전합니다.

• JFrog Access 서비스 로그에서 Adding join key with kid: 경고 로그를 검색하고, 기록된 kid 값이 빈 문자열의 SHA-256 해시(e3b0c442…b855)와 일치하는지 확인합니다. 이 로그는 빈 조인 키가 신뢰 목록에 등록됐음을 뜻합니다.

• 액세스 토큰 발급 이력에서 관리자 범위 토큰이 예상하지 못한 시점이나 출처에서 생성됐는지 점검합니다.

• 신규 관리자 계정 생성, 사용자·그룹·자격증명 목록의 대량 조회 등 관리 API 호출 흔적을 감사 로그에서 확인합니다.

• Artifactory 라우터가 인터넷에 직접 노출돼 있는지 확인하고, 리버스 프록시 액세스 로그에서 인증 헤더 없이 노드 등록 경로로 들어온 POST 요청을 찾습니다. 요청 본문까지 확인하려면 프록시 본문 로깅이나 전체 패킷 캡처가 설정돼 있어야 합니다.

✅ CHECK

패치 전에 인터넷에 노출된 이력이 있는 인스턴스는 침해 가능성을 전제로 조사 우선순위를 올려야 합니다.
로그에서 위조 토큰 사용 흔적이 보이지 않더라도 토큰 발급 자체가 정상 경로로 처리되므로, 발급 내역과 계정 변경 이력을 함께 대조해야 합니다.

‍

■ 대응 방안

‍

• 사용 중인 릴리스 브랜치에 맞는 패치 버전(7.161.20 / 7.146.38 / 7.133.29 / 7.125.20 / 7.117.28 / 7.111.21)으로 업그레이드합니다.

• 즉시 업그레이드할 수 없다면 벤더가 안내한 임시 대응책에 따라 무작위 16진수 값을 생성해 system.yaml의 shared.security.additionalJoinKeys에 설정하고, Access 서비스를 재시작해 적용합니다. 컨테이너 배포에서는 JF_SHARED_SECURITY_ADDITIONALJOINKEYS 환경변수로 같은 값을 지정합니다.

• 노출 이력이 있는 인스턴스는 액세스 토큰과 API 키를 폐기·재발급하고, 저장소에 등록된 외부 연동 자격증명도 함께 교체합니다.

• 관리자 계정 목록, 권한 설정, 리포지토리 구성을 패치 이전 기준선과 비교하고, 배포된 아티팩트의 무결성을 검증합니다.

• Artifactory를 인터넷에 직접 노출하지 않도록 접근 경로를 사내망이나 허용된 대역으로 제한합니다.

💡 TIP

Artifactory 관리자 권한은 빌드 파이프라인과 배포 산출물로 이어지므로, 패치만으로 대응을 끝내지 말고 파이프라인이 참조하는 하위 시스템의 자격증명까지 교체 범위에 포함해야 합니다.

‍