Artifactory 인증 우회가 공개 사흘 만에 공격으로 번졌다

JFrog가 2026년 8월 28일 공개한 치명적 Artifactory 인증 우회 취약점 CVE-2026-82329가 9월 1일 실제 공격에 쓰인 정황이 포착됐다. SecurityWeek의 watchTowr 관측 보도 에 따르면 허니팟에서 공격자가 관리자 토큰을 만들고 사용자·그룹·자격증명 집합 등을 조회하는 활동이 확인됐다.

직접 패치해야 하는 대상은 조직이 운영하는 자가 호스팅 Artifactory다. JFrog 공식 보안 권고 는 기본 구성에서 네트워크 접근이 가능한 비인증 공격자가 관리자 권한을 얻을 수 있다고 설명하고, 7.111.21·7.117.28·7.125.20·7.133.29·7.146.38·7.161.20을 브랜치별 수정 버전으로 제시했다. JFrog Cloud 환경은 이미 보호 조치가 적용돼 별도 작업이 필요 없지만, 자가 호스팅 환경은 업그레이드와 침해 흔적 확인이 모두 필요하다.

허니팟에서 관리자 토큰 생성이 관측됐다

관측된 행위는 취약 서버를 찾는 탐색에 그치지 않았다. 공격자는 관리자 토큰을 생성한 뒤 사용자, 그룹, 자격증명 집합과 연합 액세스 구성을 열거했다. 이는 취약점이 관리자 권한 획득에 실제로 활용될 수 있다는 JFrog의 설명과 맞닿아 있다.

확인 범위에는 한계가 있다. 공개된 근거는 watchTowr의 Attacker Eye 허니팟 네트워크이며, JFrog는 당시 실제 악용을 독립적으로 확인하지 않았다. 피해 조직 수, 공격 캠페인의 규모, 구체적인 침해지표도 공개되지 않았으므로 이를 대규모 공급망 침해가 확인된 사건으로 확대해 표현할 수는 없다.

그럼에도 관리자 토큰은 패치만으로 해결되지 않을 수 있다. 이미 발급된 토큰은 자체 만료·폐기 절차를 따르는 독립 자격증명이므로, 프로그램을 업데이트했다고 기존 토큰이 자동으로 사라진다고 가정해서는 안 된다. 저장소 설정 변경이나 빌드 산출물 변조는 현재 확인된 피해가 아니라 관리자 권한 탈취에서 파생될 수 있는 위험이지만, 사후 조사가 필요한 이유는 충분하다.

브랜치마다 수정 버전이 다르다

공식 권고가 제시한 자가 호스팅 환경의 취약 구간과 수정 기준은 다음과 같다. 운영 중인 버전이 해당 구간에 들어가면 같은 유지보수 브랜치의 수정판 이상으로 올려야 한다.

• 7.111 계열: 7.111.21 미만은 7.111.21 이상으로 업데이트한다.
• 7.117 계열: 7.117.0 이상 7.117.28 미만은 7.117.28 이상으로 업데이트한다.
• 7.125 계열: 7.125.0 이상 7.125.20 미만은 7.125.20 이상으로 업데이트한다.
• 7.133 계열: 7.133.0 이상 7.133.29 미만은 7.133.29 이상으로 업데이트한다.
• 7.146 계열: 7.146.0 이상 7.146.38 미만은 7.146.38 이상으로 업데이트한다.
• 7.161 계열: 7.161.0 이상 7.161.20 미만은 7.161.20 이상으로 업데이트한다.

7.146 계열에서는 7.146.37이 아니라 7.146.38이 수정판이라는 점에 주의해야 한다. 여러 노드로 구성된 환경이라면 관리 화면에 표시되는 대표 노드만 보지 말고, 로드밸런서 뒤의 모든 노드와 재해복구 환경까지 설치 버전을 대조해야 한다. 외부 요청을 처리하는 구버전 노드 하나가 남아 있어도 공격 표면은 닫히지 않는다.

SaaS와 자가 호스팅을 나누는 기준은 서버가 물리적으로 어디에 있는지가 아니라 운영 책임과 업데이트 주체다. JFrog가 관리하는 Cloud 인스턴스는 이미 보호됐지만, 조직의 데이터센터나 클라우드 계정에 직접 설치해 버전 수명주기를 관리하는 배포는 자체 패치 대상이다.

패치와 침해 조사를 분리하지 말아야 한다

우선순위는 외부 노출을 줄이고 수정 버전을 설치하는 것이다. 다만 인터넷에 노출된 취약 인스턴스는 패치 이전에 관리자 토큰이나 계정이 만들어졌을 가능성을 별도 사건으로 다뤄야 한다. 다음 순서는 공개된 공격 행위와 관리자 권한의 영향 범위를 바탕으로 한 사고 대응 점검안이다.

1. 노출 범위를 고정한다. 각 노드의 실행 버전, 외부 접근 경로, 프록시와 로드밸런서 뒤의 실제 대상, 패치 완료 시각을 기록한다. 즉시 업데이트할 수 없다면 관리 인터페이스와 API 접근을 신뢰 가능한 네트워크로 제한하되 이를 패치의 대체책으로 보지 않는다.
2. 관리자 토큰을 조사한다. 마지막으로 정상 상태가 확인된 시점 이후 생성된 토큰을 발급 주체, 권한, 생성 시각, 최근 사용 기록과 대조한다. 소유자를 설명할 수 없는 토큰은 관련 로그를 보존한 뒤 폐기하고, 노출 가능성이 있는 자격증명을 교체한다.
3. 사용자와 권한 변경을 확인한다. 새 관리자와 로컬 사용자, 기존 계정의 그룹 편입, 권한 대상, 연합 액세스 구성의 변경을 감사 기록과 비교한다. 정상 계정과 비슷한 이름만으로 승인된 사용자라고 판단해서는 안 된다.
4. 저장소와 빌드 경로를 대조한다. 배포 권한, 원격 저장소, 웹훅, 자동화 계정, 최근 업로드되거나 다시 게시된 산출물을 기존 기준선과 비교한다. 이상이 발견되면 영향을 받은 기간의 산출물을 신뢰할 수 있는 소스에서 재생성하고 연결된 CI/CD 자격증명의 교체 범위를 판단한다.
5. 모든 노드에서 패치를 검증한다. 수정 버전 이상이 실제 실행 중인지 확인하고 정상적인 게시·다운로드 작업을 시험한다. 이후 관리자 토큰 발급, 권한 상승, 사용자 생성과 저장소 설정 변경을 집중적으로 감시한다.

로그 보존 기간이 짧다면 감사 로그와 접근 로그를 회전 전에 별도로 보관해야 한다. 토큰을 일괄 폐기하면 자동화 작업이 중단될 수 있으므로 소유자와 사용처를 확인하며 교체하되, 출처를 설명할 수 없는 관리자 토큰은 서비스 편의보다 침해 억제를 우선할 사안이다.

공격 규모는 아직 확인되지 않았다

캐나다 사이버보안센터의 9월 1일 경보 도 공개 보고가 CVE-2026-82329의 실제 악용을 나타낸다고 알리고 영향받는 버전의 업데이트를 권고했다. 이는 정부 기관이 공개된 악용 정보를 대응 근거로 채택했다는 뜻이지, JFrog가 공격을 독립적으로 확인했다는 뜻은 아니다.

현재 확인된 상태는 수정판이 제공됐고, 공개 직후 허니팟에서 관리자 토큰 생성과 환경 열거가 관측됐다는 것이다. 반면 실제 피해 조직, 공격자의 후속 행위, 광범위한 스캔 규모와 침해지표는 아직 제시되지 않았다. 자가 호스팅 운영자는 그 불확실성을 패치 유예의 근거로 삼기보다 수정판 적용과 토큰·계정·권한·산출물 조사를 병행해야 하며, 사건의 실제 범위는 JFrog의 추가 설명과 독립적인 관측 자료가 나와야 판단할 수 있다.