패치가 있었는데도 Zimbra 서버 274대가 뚫렸다

2026년 8월 22일 인터넷 스캔에서 CVE-2026-73570 악용과 관련된 침해 아티팩트가 있는 Zimbra 인스턴스 274대가 탐지됐다. Shadowserver의 집계를 전한 BleepingComputer 에 따르면 같은 시점에 패치되지 않은 인스턴스도 최소 8,200대였지만, 비기본 설정이 필요한 취약점이어서 이들 모두가 공격 가능하거나 침해됐다는 의미는 아니다.

영향 대상은 Zimbra Collaboration 10.1.20 미만이면서 선택 구성 요소인 zimbra-snmp 패키지가 설치되고 SNMP 알림이 활성화된 서버다. IT Pro의 8월 26일 보도 는 인증되지 않은 공격자가 조작된 SMTP 요청을 보내 Zimbra 사용자 권한으로 운영체제 명령을 실행할 수 있으며, 수정 버전 10.1.20이 7월 20일 배포된 뒤에도 침해가 탐지됐다고 설명한다.

274대는 단순 미패치 서버가 아니다

274라는 숫자는 오래된 버전을 실행하는 전체 서버 수가 아니라 원격 스캔에서 침해와 연결되는 아티팩트가 식별된 인스턴스 수다. Shadowserver는 해당 대상을 ‘CVE-2026-73570을 통한 침해 가능성이 높은 아티팩트’가 발견된 서버로 분류했다. 제목의 ‘뚫렸다’는 이 탐지 결과를 가리키며, 모든 서버의 피해 내용이 포렌식으로 확정됐다는 뜻은 아니다.

반대로 274대를 전체 피해의 상한으로 볼 수도 없다. 외부에서 접근할 수 없는 서버, 스캔 시점에 응답하지 않은 시스템, 공격 흔적이 제거되거나 변경된 사례는 원격 집계에서 빠질 수 있다. 조직별 침해 여부와 범위는 로컬 로그, 파일 시스템, 실행 프로세스와 네트워크 기록을 조사해야 확정할 수 있다.

공격 주체와 피해 조직의 명단, 국가별 전체 분포는 공개되지 않았다. 탐지된 모든 서버에서 메일이나 자격 증명이 실제로 유출됐다는 증거도 아직 없다. 다만 인증 없이 서버 명령을 실행할 수 있는 취약점이므로 침해가 의심되는 시스템을 단순한 패치 누락 자산으로만 처리해서는 안 된다.

버전만으로는 공격 가능 여부를 판단할 수 없다

CVE-2026-73570의 공격 가능성은 버전과 구성의 조합에 달려 있다. 우선 10.1.20 미만인지 확인한 뒤 zimbra-snmp 설치 여부와 SNMP 알림 설정을 함께 살펴야 한다. 패치되지 않은 서버라도 해당 비기본 구성이 없으면 이 취약점의 공격 조건과 일치하지 않는다.

취약한 구성에서는 SNMP 알림 처리 과정에 외부 입력이 적절히 걸러지지 않아 조작된 SMTP 요청이 명령 주입으로 이어질 수 있다. 인증이 필요하지 않고 인터넷에 노출된 메일 서버가 직접 요청을 받는다는 점 때문에, 조건에 맞는 서버는 우선순위가 높은 조사 대상이다.

운영 문서에 ‘SNMP 미사용’이라고 적혀 있다는 사실만으로 판단해서도 안 된다. 과거 모니터링 구성에서 패키지나 알림 설정이 남았을 수 있으므로 실제 서버의 패키지 상태와 snmp_notify 설정, 관련 서비스 상태를 확인해야 한다. 지원이 종료된 구버전은 공식 수정 대상에서 빠질 수 있으므로 지원되는 최신 릴리스로 이전할 필요가 있다.

패치는 침입 경로를 막지만 침해를 되돌리지 않는다

10.1.20으로 업데이트하면 알려진 명령 주입 경로는 차단할 수 있지만, 패치 전에 공격자가 만든 파일이나 예약 작업, 웹셸과 탈취된 비밀정보까지 사라지는 것은 아니다. 업데이트 완료와 침해 복구 완료는 서로 다른 상태다.

CERT Polska의 8월 17일 경고 는 비정상적인 Zimbra 서비스 상태 변경 기록과 최근 30일 동안 zimbra 사용자가 /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/에 생성한 파일을 점검하도록 권고했다. 이 지표가 모든 공격 흔적을 포괄하는 것은 아니지만, 조사 범위를 정하는 구체적인 출발점이 된다.

업데이트 과정에서 서비스가 재시작되고 로그가 순환될 수 있으므로 침해가 의심된다면 원본 로그와 디스크 자료를 먼저 보존해야 한다. 조사 전에 의심 파일을 삭제하거나 서버를 재설치하면 공격 시점과 실행 명령, 후속 행위를 밝힐 단서가 사라질 수 있다.

의심 서버는 패치와 사고 대응을 병행해야 한다

우선순위는 추가 접근을 제한하면서 조사 가능한 상태를 유지하는 것이다. 다음 순서는 이번 취약점의 조건과 일반적인 침해 대응 원칙을 결합한 편집상 권고이며, 조직의 사고 대응 정책과 증거 보존 의무가 있다면 해당 절차가 우선한다.

1. 대상을 식별한다. 실행 중인 Zimbra 버전, zimbra-snmp 설치 여부, SNMP 알림 설정과 인터넷 노출 경로를 확인한다. 10.1.20 미만이면서 구성 조건을 충족하는 서버는 긴급 조사 대상으로 분류한다.
2. 의심 서버를 격리한다. 외부 접근과 불필요한 내부 통신을 제한하되, 전원을 끄기 전에 메모리와 휘발성 자료를 확보할 필요가 있는지 사고 대응 담당자가 판단한다.
3. 증거를 보존한다. Zimbra·SMTP·인증·시스템·프록시·방화벽 로그와 디스크 이미지를 안전한 위치에 복사한다. 서비스 재시작, 최근 생성된 웹 애플리케이션 파일, 임시 디렉터리의 실행 파일과 평소와 다른 프로세스를 조사한다.
4. 수정 버전으로 업데이트한다. 공식 배포 경로를 이용해 10.1.20 이상인 지원 버전으로 올리고 실제 버전과 서비스 상태를 다시 확인한다. SNMP 알림이 필요하지 않다면 관련 구성의 비활성화나 제거도 검토한다.
5. 자격 증명과 신뢰 관계를 교체한다. 명령 실행 가능성이 확인되면 관리자·서비스 계정 암호, API 키, 활성 세션과 서버가 접근할 수 있던 인증서 개인키의 노출 범위를 평가한다. 교체는 의심 서버가 아닌 신뢰할 수 있는 관리 환경에서 수행한다.
6. 신뢰할 수 있는 상태로 복구한다. 무결성을 보장하기 어렵다면 검증된 이미지로 서버를 재구축하고 필요한 데이터와 설정만 선별적으로 복원한다. 침해 이후 만들어진 백업에는 악성 변경이 포함됐을 가능성도 확인한다.

현재 확인된 핵심은 패치가 7월에 제공됐지만 8월 22일 스캔에서 274대의 침해 아티팩트가 탐지됐다는 점이다. 공격 주체와 개별 조직의 실제 피해 범위는 아직 밝혀지지 않았으므로, 취약 조건에 해당하는 서버는 패치 기록만으로 사건을 종결하지 말고 격리, 증거 보존, 침해 조사와 자격 증명 교체까지 완료했는지 확인해야 한다.