TeamCity CVE-2026-63077 수정: 2026년 기업 긴급 업그레이드 가이드

TeamCity 공식 안내에 따르면 CVE-2026-63077은 TeamCity On-Premises에 영향을 주며, 수정되지 않은 서버에 대한 적극적인 악용과 악용 시도가 확인되었습니다. TeamCity Cloud는 사용자가 이 수정 작업을 수행할 필요가 없습니다. 자세한 영향 범위와 완화 조치는 공식 보안 업데이트에서 확인해야 합니다.

처음 30분에는 원인 분석보다 추가 접근과 변경을 막는 일이 우선입니다.

• 외부에서 TeamCity 관리 화면과 관련 서비스로 들어오는 접근을 제한합니다.
• 관리자 권한 변경, 플러그인 설치, 사용자 추가와 토큰 발급을 일시 중지합니다.
• 생산 서명, 배포, App Store 제출에 연결된 작업을 멈춥니다.
• 서버와 Agent의 로그, 감사 기록, 작업 기록을 삭제하지 않고 보존합니다.
• 의심스러운 Mac Agent를 생산 라우팅에서 제외합니다.
• 현재 시각과 조치 담당자, 변경된 방화벽 규칙을 별도 조사 기록에 남깁니다.

다음 체크리스트는 첫 대응 담당자가 조치 누락을 확인할 때 사용합니다.

• [ ] TeamCity 서버가 On-Premises인지 Cloud인지 확인했습니다.
• [ ] 인터넷에서 관리 화면으로 들어오는 접근을 제한했습니다.
• [ ] 관리자 계정, 플러그인, 토큰 변경을 일시 중지했습니다.
• [ ] 생산 서명과 배포 작업을 중지했습니다.
• [ ] 서버, Agent, 감사 기록과 빌드 기록을 별도 위치에 보존했습니다.
• [ ] 의심스럽거나 승인되지 않은 Mac Agent를 생산 풀에서 제외했습니다.
• [ ] 담당자, 조치 시각과 방화벽 변경 내역을 기록했습니다.

이 단계에서 서버를 바로 재설치하면 조사에 필요한 흔적이 사라질 수 있습니다. 반대로 네트워크 제한 없이 패치만 기다리면 추가 악용 가능성을 줄이지 못합니다. 따라서 접근 제한과 증거 보존을 동시에 진행해야 합니다.

공식 보안 안내에서는 2025.11.7과 2026.1.3을 수정이 포함된 버전으로 제시합니다. 현재 버전이 오래되었거나 플러그인 의존성이 복잡하다면 무조건 최신 버전으로 건너뛰기보다 지원되는 수정 버전과 기존 구성의 호환성을 먼저 대조해야 합니다. 수정 버전 정보는 TeamCity 보안 공지와 최신 보안 업데이트를 함께 확인해야 합니다.

즉시 업그레이드가 불가능한 경우에는 공식 보안 패치 플러그인을 임시 완화책으로 검토할 수 있습니다. 그러나 임시 패치는 침해 여부를 판정하거나 이미 생성된 산출물을 신뢰 가능한 상태로 되돌리는 수단이 아닙니다.

2026년 9월 1일 공개된 TeamCity 2026.2로 이동할 때도 기존 버전, 자바, 데이터베이스 드라이버와 플러그인 조건을 확인해야 합니다. TeamCity 2026.2 릴리스 문서와 현재 서버 및 Agent 업그레이드 문서를 유지보수 계획의 기준으로 삼는 편이 안전합니다.

백업 범위 확인

유지보수 창을 열기 전에 다음 항목을 별도로 확인합니다.

• TeamCity 데이터베이스 백업과 복구 가능 여부
• Data Directory와 서버 설정 파일의 별도 보존
• 플러그인 목록과 플러그인별 버전
• 서버가 사용하는 자바 실행 환경과 데이터베이스 드라이버
• VCS 연결 정보와 외부 저장소 연결 방식
• 최근 빌드 기록, 감사 로그와 조사 대상 작업의 식별 정보
• 암호와 토큰을 백업 파일에 평문으로 포함하지 않았는지 여부

데이터베이스 백업만으로는 서버 파일, 플러그인, 외부 비밀 저장소와 Mac 서명 자료가 모두 보존되지 않습니다. 특히 서명용 키체인은 TeamCity 서버 백업과 별개의 자산으로 취급하고, 조사 중인 기존 노드에서 그대로 새 환경으로 복사하지 않아야 합니다.

업그레이드 선택은 현재 버전, 유지보수 창, 플러그인 호환성에 따라 달라집니다. 아래 표는 버전 선택의 출발점이며, 최종 적용 전에는 공식 문서와 내부 검증 결과를 함께 승인해야 합니다.

이 표에서 공식 수정 버전으로 표시된 값은 보안 공지에 근거한 것입니다. 현재 환경이 해당 경로를 직접 지원하는지는 서버 버전과 플러그인 구성에 따라 달라집니다.

설치 명령 자체보다 중요한 것은 업그레이드 전후의 상태를 분리해 확인하는 것입니다. 다음 순서를 유지하면 서버 수정과 복구 검증이 섞이는 문제를 줄일 수 있습니다.

1. 서버 중지와 백업 확인

변경 승인 후 TeamCity 서버를 중지하고, 백업 완료 시각과 복구 테스트 결과를 기록합니다. 백업이 끝나지 않았거나 파일 범위가 불명확하면 설치를 진행하지 않고 유지보수 창을 다시 잡아야 합니다.

2. 수정 버전 또는 공식 완화책 적용

현재 버전과 목표 버전을 기록한 뒤 공식 수정 버전으로 이동합니다. 즉시 이동할 수 없는 경우에만 공식 보안 패치 플러그인을 임시로 적용하고, 최종 업그레이드 날짜와 담당자를 변경 기록에 남깁니다.

3. 관리 화면과 보안 상태 확인

서버가 정상적으로 시작되면 관리 화면 로그인, 사용자·권한 목록, 플러그인 상태와 보안 패치 적용 상태를 확인합니다. 여기서 정상 로그인은 침해 부재를 의미하지 않습니다. 로그 조사는 서버가 다시 올라온 뒤에도 계속되어야 합니다.

4. VCS와 작업 대기열 확인

읽기 전용에 가까운 검증 작업으로 VCS 연결을 확인하고, 중단된 작업이 자동으로 생산 배포로 이어지지 않는지 점검합니다. 대기 중인 작업은 코드 출처, 실행 Agent, 사용 자격 증명과 산출물 저장 위치를 확인한 뒤 재실행 여부를 결정합니다.

5. Agent 연결과 업데이트 조건 확인

Agent가 온라인으로 보이는지만 확인하지 말고 승인 상태, 호스트 식별 정보, 연결 주소와 자동 업그레이드 결과를 함께 기록합니다. Agent 자동 업그레이드 중 강제 재시작을 걸면 업그레이드가 불완전해질 수 있으므로, 공식 업그레이드 절차의 동작 조건을 따라야 합니다.

2026.1 또는 2026.2로 이동하는 경우에는 자바 21 요구 조건과 데이터베이스 드라이버를 별도로 검토해야 합니다. TeamCity의 Java 21 안내에 맞지 않는 실행 환경을 먼저 바꾸지 않으면 보안 수정이 호환성 장애로 이어질 수 있습니다.

서버가 복구된 뒤에도 기존 Mac Build Agent를 즉시 생산에 투입해서는 안 됩니다. 서버, Mac Build Agent, 작업 공간, 서명 노드와 하위 산출물 저장소는 서로 다른 조사 대상으로 나누어야 합니다.

각 Agent에는 다음 정보를 기록합니다.

• TeamCity에 표시되는 Agent 이름과 호스트 식별 정보
• 승인 또는 비승인 상태
• serverUrl과 연결 시각
• 자동 업그레이드 성공 여부
• 설치된 Xcode와 빌드 도구 상태
• 최근 작업의 저장소, 브랜치와 실행 계정
• 작업 공간에 남은 파일과 키체인 접근 흔적

Agent 상태와 승인 처리는 공식 Agent 문서의 기준과 실제 관리 화면을 서로 대조해야 합니다. 출처가 불분명하거나 이름이 바뀐 Agent는 승인하지 말고 기존 신뢰 노드와 분리해 조사합니다.

깨끗한 Mac에서는 다음 순서로 최소 검증을 진행합니다.

1. 생산 라우팅을 끄고 새 Agent를 격리된 풀에 연결합니다.
2. 저장소에서 테스트 코드를 새로 가져옵니다.
3. 의존성을 다시 설치하고 기존 작업 공간을 재사용하지 않습니다.
4. Xcode 선택, 컴파일과 테스트 단계를 실행합니다.
5. 아카이브는 생성하되 처음에는 서명과 배포를 실행하지 않습니다.
6. 로그와 생성 파일을 비교한 뒤 제한된 서명 작업을 수행합니다.

macOS Agent의 시작 조건은 공식 macOS Agent 안내와 현재 운영 방식이 일치하는지 확인해야 합니다. 오프라인 환경에서는 Agent 자동 업데이트 파일을 내려받지 못할 수 있으므로, 업데이트가 성공했다고 가정하지 말고 실제 버전과 연결 상태를 기록해야 합니다.

패치와 Agent 복구가 끝나지 않은 상태에서 모든 비밀을 한 번에 교체하면 원인 추적이 어려워질 수 있습니다. 반대로 조사만 하며 노출된 자격 증명을 계속 사용하면 공격자가 같은 경로를 재사용할 수 있습니다. 보안 담당자와 시스템 담당자가 교체 순서와 증거 보존 범위를 함께 승인해야 합니다.

조사표 작성

다음 항목을 한 행씩 기록합니다.

• 서버 로그의 시간과 작업 식별자
• 계정, 권한 변경과 토큰 발급 기록
• 승인되지 않은 Agent의 이름과 최초 확인 시각
• 실행된 저장소, 브랜치와 빌드 결과
• 산출물 저장소로 전송된 파일
• 서명 또는 배포 작업의 실행 여부
• 조사 담당자와 다음 조치

공식 공지에 제시된 이상 징후와 내부 로그를 대조하되, 정상적인 자동화 작업도 함께 표시해야 합니다. 정상 작업을 모두 침해로 분류하면 복구 판단이 흐려지고, 비정상 작업을 정상으로 처리하면 조사 범위가 축소됩니다.

교체 대상 분류

• VCS 접근 토큰과 저장소 계정
• 패키지 및 빌드 산출물 저장소 자격 증명
• 배포 서버와 클라우드 계정의 접근 키
• TeamCity 서버와 Agent 연결에 사용되는 비밀
• Apple 개발자 계정, 인증서와 프로비저닝 자료
• Mac 서명 키체인의 비밀과 자동 서명 설정
• 알림, 배포 승인과 외부 서비스용 토큰

취약점이 노출된 기간에 생성된 앱과 패키지는 새 자격 증명으로 다시 만들었다는 이유만으로 신뢰해서는 안 됩니다. 소스 커밋, 실행 Agent, 작업 공간 상태와 생성 시점을 연결할 수 없는 산출물은 배포 후보에서 제외하고 다시 생성하는 편이 안전합니다.

생산 복구의 승인 조건은 “서버가 켜졌다”가 아니라 다음 다섯 가지 결론으로 구성해야 합니다.

• [ ] 서버 수정 버전과 보안 완화 상태가 기록되었습니다.
• [ ] 조사 범위에 포함된 자격 증명이 교체되었습니다.
• [ ] 배포 대상 산출물의 출처와 재생성 여부를 설명할 수 있습니다.
• [ ] 복귀하는 Agent의 호스트 식별 정보와 승인 상태가 확인되었습니다.
• [ ] 문제가 재발했을 때 이전 단계로 되돌릴 방법이 준비되었습니다.

그 후에도 한 번에 전체 작업을 열지 않고 단계적으로 방출합니다.

1. 격리된 깨끗한 Mac에서 코드 가져오기를 실행합니다.
2. 컴파일과 테스트만 수행하고 결과를 비교합니다.
3. 서명하지 않는 아카이브를 생성합니다.
4. 제한된 자격 증명으로 테스트 서명을 수행합니다.
5. 승인된 저장소에만 결과를 전달합니다.
6. 마지막으로 소수의 생산 작업을 허용합니다.
7. 로그와 산출물 추적이 정상일 때 추가 작업을 엽니다.

기존 노드와 새 노드의 결과가 다르면 성능 차이로 단정하지 말고 Xcode, 의존성, 환경 변수, 키체인과 작업 공간을 비교해야 합니다. 차이를 설명할 수 없으면 기존 노드는 재설치, 추가 조사 또는 폐기 중 하나로 결정해야 합니다.

팀에 예비 Mac이 없다면 단기간 격리된 Mac 환경을 마련해 Agent를 재구축하고 핵심 빌드를 다시 실행하는 방법을 검토할 수 있습니다. 이때 원격 Mac PoC와 보안 격리 점검표를 먼저 작성하면 접근 권한, 초기화, 로그 보존과 회수 조건을 구매 전에 합의할 수 있습니다. 장기 운영을 검토하는 팀은 NUKCLOUD 서비스 구성과 기존 보안 통제를 대조하되, 기업 내부 정책과 데이터 보존 요건을 별도로 확인해야 합니다.

자체 Mac 노드만 사용하는 팀은 하드웨어를 직접 통제할 수 있지만, 예비 장비와 깨끗한 복구 환경이 없으면 긴급 조사 중 생산 용량이 사라질 수 있습니다. 반대로 단기 원격 Mac을 추가하면 물리 장비 구매 없이 격리된 Agent를 만들 수 있지만, 네트워크 접근 정책, 비밀 전달 방식과 작업 종료 후 초기화 절차를 먼저 정해야 합니다.

현재 환경의 약점이 예비 노드 부족, 장비 조달 지연, 동일한 서명 환경을 다시 만들 수 없는 문제라면 NUKCLOUD의 Mac 환경을 단기 검증 자원으로 비교할 가치가 있습니다. 다만 장기간 고정 부하, 물리 장치 연결, 사내망에 대한 직접적인 저지연 접근이 필수인 팀에는 자체 장비가 더 적합할 수 있습니다. 원격 Mac은 기존 TeamCity 서버의 신뢰 문제를 대신 해결하지 않으므로, 격리·자격 증명 교체·산출물 검증은 반드시 별도로 수행해야 합니다.

TeamCity CVE-2026-63077 수정은 설치 완료로 끝나지 않습니다. 외부 노출을 줄이고, 공식 수정 경로를 적용하고, Mac Agent와 자격 증명을 조사한 뒤, 깨끗한 환경에서 실제 iOS CI/CD 흐름을 검증해야 생산 복구를 승인할 수 있습니다.