Cisco-Unified-Communications-Manager-Server-Side-Forgery-Request-Vulnerability-CVE-2026-20230

Cisco Unified Communications Manager의 CVE-2026-20230 SSRF에서 임의 파일 쓰기 및 RCE를 분석하고, PoC 도출, 탐지 로직, 방어 지침을 제공합니다.

이 취약점은 일반적인 "특정 고정 URL에 접근하여 200이 반환되면 존재한다"는 형태의 Web 취약점이 아니다. 그 악용 체인은 최소한 세 가지 계층을 포함한다:

1. 외부에서 접근 가능한 WebDialer 또는 cmplatform 관련 인터페이스.
2. SSRF의 영향을 받을 수 있는 내부 접근 로직.
3. 내부 요청에 의해 추가로 트리거될 수 있는 파일 쓰기 또는 서비스 배포 동작.

따라서 특정 인터페이스에 단독으로 접근하여 HTTP 200, 302, 401, 404 또는 500을 얻었다고 해서 취약점의 존재 여부를 직접 증명할 수는 없다.

예를 들어, WebDialer WSDL 인터페이스에 접근 가능하다는 것은 대상이 WebDialer 관련 기능을 노출했음을 보여줄 뿐, 이후 SSRF가 반드시 필터링을 통과할 수 있다는 것을 증명하지는 못한다. installClusterStatusExecute 인터페이스에 접근 가능한 것도 관련 진입점이 존재함을 보여줄 뿐, 임의 파일 쓰기가 성립되었음을 단독으로 증명하지는 못한다. 반대로 특정 단계에서 예외가 반환되더라도 이는 대상 버전, 패치, hostname 해석, 경로 권한, 프록시 장비 또는 서비스 상태 때문일 수 있으며, 반드시 전체 취약점 체인이 존재하지 않는다는 것을 의미하지는 않는다.

보다 안정적인 판단은 다단계 증거 조합을 사용해야 한다:

1. 대상이 Cisco Unified CM / Unified CM SME인지 확인.
2. WebDialer 서비스가 활성화 상태인지 확인.
3. 대상의 실제 hostname 또는 내부 서비스 식별자를 획득할 수 있는지 확인.
4. SSRF 진입점에 도달 가능하고, 서버 측에서 내부 요청을 시작하는 징후가 있는지 확인.
5. 승인된 실습 환경에서 통제된 파일 쓰기 증거가 발생하는지 확인.
6. 서버 측 로그, 파일 시스템 변경, Web 컨테이너 로그 및 알람 데이터를 결합하여 실제 트리거 여부 판단.

"WebDialer 활성화 + 영향받는 버전 + SSRF 동작 성립 + 통제된 파일 쓰기 성립"이 동시에 나타나야 비로소 신뢰도 높은 악용 가능으로 판단해야 한다.

3. PoC 구성思路

현재 공개된 악용 체인의 핵심은 단순한 SSRF가 아니라, SSRF와 Axis/Java Web 서비스 메커니즘, 로그 쓰기 또는 배포 설명 파일 처리 로직 간의 조합 악용이다.

전체적인思路는 다음과 같이 요약할 수 있다:

체인 설계 관점에서 hostname은 핵심 요소이다. 일부 필터링 로직은 127.0.0.1, localhost 등 일반적인 로컬 주소를 차단하지만, 대상의 실제 hostname은 이후 요청 흐름에 허용될 수 있다. 따라서 PoC는 먼저 WebDialer의 WSDL 정보에서 실제 호스트 이름을 추출한 다음, 이를 SSRF 체인의 내부 접근 접두어로 사용한다.

두 번째 핵심 요소는 Axis 서비스 관련 로직이다. PoC는 Web 디렉터리에 직접 파일을 업로드하는 것이 아니라, 내부 서비스 처리 체인을 통해 서버 측 컴포넌트가 공격자 통제 내용을 특정 경로에 쓰도록 만든다. 이 과정은 본질적으로 "서버 측 내부 요청 + 컴포넌트 구성/로그 쓰기 동작 + 경로 이동/경로 제어"의 조합이다.

세 번째 핵심 요소는 2단계 쓰기이다. 첫 번째 단계는 일반적으로 더 안정적인 파일 쓰기 진입점을 구축하는 데 사용되고, 두 번째 단계에서 명령 실행 스크립트를 Web 접근 가능 디렉터리에 쓴다. 이렇게 하는 이유는 SSRF를 통해 한 번에 완전한 명령 실행 로직을 쓰려고 하면 인코딩, 길이, XML 구조, 경로 권한 및 서버 측 파싱 동작의 영향을 받을 수 있기 때문이며, 2단계 방식은 복잡한 페이로드를 분리하기 easier 때문이다.

본 문서는 완전한 악용 패킷과 WebShell 내용을 제공하지 않는다. 방어와 검증 시 다음 핵심 특징만 이해하면 된다:

4. hostname 획득 로직

PoC는 먼저 대상의 실제 hostname을 획득해야 하며, IP 주소나 외부 도메인만 사용해서는 안 된다.

그 이유는 SSRF 필터링 로직이 반드시 최종 연결 대상만 판단하는 것이 아니라, hostname 필드, URL 문자열, 로컬 주소 키워드 등을 함께 검증할 수 있기 때문이다. 일반적인 127.0.0.1, localhost 같은 로컬 주소는 차단될 수 있지만, 장비의 실제 hostname은 특정 시나리오에서 합법적인 노드 이름으로 간주될 수 있다.

판단에 도움이 될 수 있는 인터페이스는 일반적으로 WebDialer WSDL 정보와 관련이 있다. 해당 WSDL에 접근하면 응답에 서비스 주소, location 필드 또는 기타 파싱 가능한 호스트 식별자가 포함될 수 있다. PoC는 응답 텍스트에서 URL의 hostname을 추출하여 다음 단계 SSRF의 내부 접근 대상으로 사용한다.

이 단계의 판단 기준은 다음과 같아야 한다:

1. WSDL 인터페이스에 접근 가능한지.
2. 응답 내용이 WebDialer / Axis 서비스 특징과 일치하는지.
3. 응답에서 실제 hostname을 파싱할 수 있는지.
4. 파싱된 hostname이 외부 접근 IP 또는 도메인과 다른지.
5. 해당 hostname이 이후 SSRF 진입점에 수용될 수 있는지.

hostname 파싱에 실패하면 PoC는 대상 IP로 폴백할 수 있지만, 이는 성공률을 현저히 낮춘다. 실제 환경에서 hostname 파싱 실패의 일반적인 원인은 WebDialer 미활성화, 인터페이스 접근 제어 제한, 응답이 리버스 프록시에 의해 변조됨, 인증서 또는 서비스 구성 불완전 등이다.

5. SSRF 트리거 단계

SSRF 트리거 지점은 cmplatform 관련 설치 상태 조회 로직에 있다. 이 기능은 원래 클러스터 노드 설치 상태를 조회하는 데 사용되며, 서버는 사용자가 제출한 노드 식별자 또는 hostname을 기반으로 내부 요청을 구성한다.

취약점의 핵심 문제는 공격자가 통제할 수 있는 hostname 매개변수가 합법적인 노드 이름이나 신뢰된 호스트로 엄격히 제한되지 않아, 이 매개변수가 더 복잡한 내부 접근 경로로 구성될 수 있다는 점이다. 이후 서버는 공격자를 대신해 내부 인터페이스에 요청을 보낸다.

이 단계의 핵심은 "외부 URL에 접근할 수 있는가"가 아니라 "CUCM 장비 자체가 내부에서만 접근 가능한 WebDialer / Axis 관리 인터페이스에 접근하게 만드는가"이다. 따라서 SSRF의 가치는 두 가지 측면에서 나온다:

1. 외부 네트워크 접근 제한을 우회하여 본인 또는 내부 컴포넌트만 접근할 수 있는 서비스 경로에 도달.
2. 내부 서비스 신뢰 경계를 활용하여 일반 HTTP 매개변수를 내부 컴포넌트 동작으로 전환.

승인된 검증에서 HTTP 상태 코드만으로 SSRF 성공을 판단해서는 안 된다. 더 신뢰할 수 있는 증거는 다음과 같다:

1. 서버 측 로그에 내부 경로에 대한 접근 기록이 나타남.
2. 요청 응답 내용에 내부 인터페이스 특징이 나타남.
3. 이후 WebDialer services 페이지에 새로 추가되거나 비정상적인 서비스 흔적이 나타남.
4. 파일 시스템에 서버 측 프로세스가 생성한 비정상적인 파일이 나타남.
5. 보안 장비가 hostname 매개변수에 비정상적인 경로, 인코딩 내용 또는 내부 서비스 경로가 포함된 것을 기록함.

6. Axis 서비스 쓰기와 임의 파일 쓰기思路

공개 체인에서 SSRF는 Axis 관련 서비스 인터페이스에 접근하고 서비스 배포 설명 내용을 쓰는 데进一步 사용된다. 공격자는 특수한 XML/WSDD 구조를 구성하여 서버 측 컴포넌트가 처리 과정에서 통제 가능한 내용을 지정된 경로에 쓰도록 만든다.

이 단계의 본질은 전통적인 파일 업로드가 아니라 서버 측 컴포넌트의 처리 로직을 남용하는 것이다:

보안 분석 관점에서 몇 가지 핵심 요소가 있다:

1. 쓰기 대상 경로는 일반적으로 Web 컨테이너 접근 가능 디렉터리로 이동해야 한다.
2. 쓰기 내용은 서버 측 컴포넌트 처리 형식을 충족해야 하며, 그렇지 않으면 유효하지 않은 파일만 생성될 수 있다.
3. 쓰기 파일의 소유자와 권한은 Tomcat / CUCM 서비스 프로세스에 따라 결정된다.
4. 쓰기 위치가 Web에서 접근 가능하면 파일 쓰기는 스크립트 실행으로进一步 전환될 수 있다.
5. 쓰기 위치가 실행 가능하지 않더라도 구성 오염, 지속성 또는 이후 권한 상승 조건을 초래할 수 있다.

따라서 CVE-2026-20230의 고위험 지점은 단순히 SSRF가 아니라, SSRF가 신뢰 경계를 넘어 내부 관리/서비스 배포 체인에 진입하고 최종적으로 통제 가능한 파일 쓰기를 트리거할 수 있다는 점이다.

7. 2단계 WebShell 쓰기 로직

PoC 설계에서는 일반적으로 한 번에 명령 실행을 완료하는 대신 2단계 쓰기를 채택한다.

첫 번째 단계는 간단한 파일 쓰기 능력을 생성하는 데 사용된다. 이 단계의 목표는 공격자가 Web 접근 가능 경로를 통해 서버의 지정된 위치에 내용을 쓸 수 있게 하는 것이다.

두 번째 단계에서는 첫 번째 단계의 쓰기 능력을 활용하여 명령 실행 스크립트를 Web 접근 가능 디렉터리에 쓴다. 이후 공격자는 HTTP 매개변수를 통해 시스템 명령 실행을 트리거할 수 있다.

2단계 설계의 장점은:

1. 단일 SSRF 요청에서 페이로드 복잡도를 낮춘다.
2. XML, URL 인코딩, 특수 문자 이스케이프로 인한 페이로드 손상을 방지한다.
3. "서비스 배포"와 "최종 실행 파일 쓰기"를 분리하여 디버깅이 용이하다.
4. 다양한 대상 경로에서 착점을 조정하기 쉽다.
5. 이후 명령 실행 단계를 SSRF 단계와 분리한다.

그러나 방어 관점에서 2단계 쓰기는 더 명확한 탐지 표면을 제공한다:

1. 첫 번째 비정상 요청은 일반적으로 새 서비스를 생성하거나 중간 JSP를 쓰려고 시도한다.
2. 두 번째 비정상 요청은 일반적으로 중간 JSP에 접근하며 파일 이름, 파일 내용 등의 매개변수를携带한다.
3. 세 번째 단계는 최종 명령 실행 JSP에 접근하며 인증 암호 또는 명령 매개변수를携带한다.
4. Web 접근 로그에는 짧은 시간 내에 WebDialer, services, axis2-web, platform-services 등의 경로를 연속적으로 접근하는 동작이 나타난다.
5. 파일 시스템에 비정상적인 JSP, 비정상적인 서비스 이름, 비정상적인 로그 파일 또는 새로 추가된 Web 리소스가 나타날 수 있다.

8. 현재 PoC의 전체 실행 흐름

현재 PoC의 흐름은 다음과 같이 요약할 수 있다:

1. 대상 주소를 파싱한다.
2. WebDialer WSDL에 접근하여 실제 hostname 추출을 시도한다.
3. 내부 WebDialer / Axis 관리 경로를 대상으로 SSRF 요청을 구성한다.
4. 내부 요청을 통해 Axis 서비스 관련 내용을 쓴다.
5. services 페이지에 접근하여 비정상 서비스 배포 성공 여부를 확인한다.
6. 새 서비스를 호출하여 첫 번째 단계 파일 쓰기 스크립트를 쓴다.
7. 첫 번째 단계 스크립트에 접근하여 두 번째 단계 명령 실행 스크립트를 쓴다.
8. 두 번째 단계 스크립트에 접근하여 테스트 명령을 실행한다.
9. HTTP 응답, 파일 생성 결과 및 명령 출력을 기반으로 악용 성공 여부를 판단한다.

악용 성공률 관점에서 가장 중요한 실패 지점은 일반적으로 다음에集中된다:

1. WebDialer가 활성화되지 않음.
2. hostname 파싱 실패 또는 필터링됨.
3. SSRF 요청이 실제로 내부 서비스에 진입하지 못함.
4. Axis 서비스 배포 실패.
5. 경로 이동 착점이 대상 버전에 맞지 않음.
6. Web 디렉터리를 쓸 수 없거나 스크립트가 실행되지 않음.
7. 대상이 이미 패치되었거나 Cisco 임시 수정 패키지를 적용함.
8. 프록시, WAF, EDR 또는 파일 무결성 모니터링이 중간 단계를 차단함.

따라서 이 PoC는 특정 영향받는 버전과 기본 경로가 일치할 때 악용 가능성이 높지만, 모든 CUCM 자산에 대해 안정적으로 통과되는 것은 아니다.

9. 성공 판단 로직

CVE-2026-20230의 성공 판단은 스크립트가 끝까지 실행되었는지만 볼 수 없다. 더 합리적인 판단은 4단계로 나누어야 한다.

첫 번째 단계: 대상 의심 노출

조건:

이는 대상에 관련 공격 표면이 존재함을 보여줄 뿐, 취약점 악용 가능성을 증명하지는 못한다.

두 번째 단계: 취약점 의심 존재

조건:

이 경우 서버 측 로그 또는 승인된 실습 환경을 결합하여 계속 검증해야 한다.

세 번째 단계: 파일 쓰기 확인

조건:

이 단계에 도달하면 취약점 체인이 일반 SSRF 단계를 돌파하여 임의 파일 쓰기 위험에 진입했음을 확인할 수 있다.

네 번째 단계: RCE 확인

조건:

오직 이 단계에서만 원격 명령 실행이 성립되었다고 판단할 수 있다. 파일 쓰기 성공이 반드시 RCE 성공을 의미하지는 않지만, CUCM과 같은 고권한 서비스 환경에서 파일 쓰기만으로도 심각한 위험을 구성하기에 충분하다.

10. 사용 예시

본 문서는 공격에 직접 사용할 수 있는 exploit 실행 예시를 제공하지 않는다.

승인된 환경에서는 "읽기 전용 검사" 또는 "비파괴적 검증" 방식을 우선 사용하는 것을 권장한다. 예:

권장 검사 항목:

1. 대상이 Cisco Unified CM / Unified CM SME인지.
2. WebDialer 서비스가 활성화되어 있는지.
3. WSDL에 접근 가능한지.
4. services 페이지가 노출되어 있는지.
5. 대상 버전이 수정 버전보다 낮은지.
6. 비정상적으로 새로 추가된 JSP, 비정상 Axis 서비스 또는 비정상 로그 쓰기 흔적이 있는지.

운영 시스템에서 전체 파일 쓰기 또는 명령 실행 검증을 수행하는 것은 권장하지 않는다. 승인된 테스트라도 격리된 실습 환경, 스냅샷 환경 또는 벤더가 권장하는 검증 절차에서 우선 수행해야 한다.

11. PoC 설계에서의 보안 경계

이러한 PoC의 보안 경계는 명확해야 한다.

첫째, 기본적으로 명령을 실행해서는 안 된다. 명령 실행 단계는 고위험 검증으로, 시스템 상태 변경, 로그 오염, 서비스 이상 또는 보안 장비 연동 대응을 쉽게 초래할 수 있다.

둘째, 기본적으로 WebShell을 써서는 안 된다. 테스트 파일이라도 EDR, WebShell 탐지, 파일 무결성 모니터링 또는 규정 준수 감사 시스템이 실제 침입 행위로 판단할 수 있다.

셋째, 공개 인터넷 대상을 대상으로 대량 탐지를 수행해서는 안 된다. 이 취약점은 인증이 필요 없으며 대상이 대부분 기업 통신 인프라스트럭처이므로, 승인되지 않은 스캔과 악용의 위험이 매우 높다.

넷째, 검사 모드와 악용 모드를 분리해야 한다. PoC를 두 개의 스크립트로 분리할 것을 권장한다. 하나는 자산 식별과 서비스 상태 판단에만 사용하고, 다른 하나는 로컬 실습 환경 또는 명시적으로 승인된 환경에서만 파일 쓰기를 검증한다.

다섯째, 대상 범위를 제한해야 한다. PoC에 로컬 주소, 사설 네트워크 대역, 화이트리스트 도메인, 승인 확인 매개변수 등의 보호 메커니즘을 추가하여 제3자 시스템을 오탐하지 않도록 해야 한다.

여섯째, RCE 단계를 기본적으로 비활성화해야 한다. 연구 코드를 유지하더라도 사용자가 명시적으로 승인 확인 매개변수를 전달해야만 파일 쓰기 또는 명령 실행 검증에 진입할 수 있도록 해야 한다.

12. 보호 규칙 작성에 대한 시사점

트래픽 탐지 관점에서 특정 고정 파일 이름, 고정 서비스 이름 또는 고정 JSP 이름만 매칭해서는 안 된다. 공개 PoC의 서비스 이름, 파일 이름 및 경로는 모두 수정될 수 있으므로 단일 문자열 규칙은 누락되기 쉽다.

더 합리적인 탐지思路는 공격 체인 단계를 중심으로 특징을 추출하는 것이다.

첫 번째 유형: 정보 획득 단계

중점 관찰:

짧은 시간 내에 외부 클라이언트가 WSDL에 접근한 후 cmplatform 설치 상태 인터페이스에 접근하면 위험 등급을 높여야 한다.

두 번째 유형: SSRF 트리거 단계

중점 관찰:

이 단계의 핵심은 hostname 매개변수가 더 이상 일반적인 호스트 이름처럼 보이지 않고 경로화, URL화, 인코딩화, XML화된 특징이 나타난다는 것이다.

세 번째 유형: Axis / WSDD 주입 단계

중점 관찰:

이러한 필드가 동시에 나타나면 공격자가 Axis 서비스 배포 설명 파일을 통해 통제 가능한 내용을 쓰려고 시도하고 있음을 높은 의심으로 판단해야 한다.

네 번째 유형: 파일 쓰기 단계

중점 관찰:

공격 트래픽에 대량의 ../, URL 인코딩된 경로 이동, JSP 확장자 및 Tomcat WebApp 경로가 나타나면 고위험으로 판단해야 한다.

다섯 번째 유형: 명령 실행 단계

중점 관찰:

규칙 설계 관점에서 단계별 탐지를 권장한다:

1. WebDialer 정보 획득: 저위험 또는 중위험 알람.
2. cmplatform SSRF 비정상 hostname: 고위험 알람.
3. Axis/WSDD/LogHandler 조합 특징: 심각 알람.
4. JSP 파일 쓰기 또는 명령 실행 매개변수: 심각 알람.
5. 다단계 연관 히트: 직접 침입 이벤트로 승격.

13. 조사 및 포렌식 권장 사항

응급 조사 시 다음 위치와 현상을 중점적으로 확인할 것을 권장한다:

1. WebDialer 접근 로그에 비정상적인 WSDL 및 services 열거가 있는지.
2. cmplatform 접근 로그에 installClusterStatusExecute 비정상 요청이 있는지.
3. hostname 매개변수에 URL 인코딩, 경로 이동, Axis, WSDD, LogHandler 등의 내용이 포함되어 있는지.
4. Web 디렉터리에 비정상적인 JSP 파일이 나타났는지.
5. Axis services 페이지 또는 구성에 비정상적인 서비스 이름이 나타났는지.
6. Tomcat 로그, 플랫폼 서비스 로그에 비정상적인 배포 설명, XML 파싱 오류 또는 경로 쓰기 기록이 나타났는지.
7. /tmp, WebApp 디렉터리, 로그 디렉터리에 테스트 파일 또는 알 수 없는 파일이 나타났는지.
8. 짧은 시간 내에 동일한 소스 IP가 발신한 다단계 연속 접근이 있는지.
9. 비정상적인 시스템 명령 실행 흔적, 프로세스 생성 기록 또는 shell 관련 동작이 나타났는지.
10. root 권한 관련 비정상 파일, 예약 작업, 시작 항목 또는 지속성 흔적이 있는지.

이미 악용되었다고 의심되면 관리면 접근을 우선 격리하고, 로그와 파일 시스템 증거를 보존한 다음 패치 업그레이드, WebShell 정리, 비정상 서비스 정리 및 계정/자격 증명 교체를 수행해야 한다.

14. 수정 및 완화 권장 사항

근본적인 수정 방법은 Cisco 공식 수정 버전으로 업그레이드하거나 공식 임시 수정 패키지를 적용하는 것이다.

일반적인 처리 권장 사항:

1. 즉시 Unified CM / Unified CM SME 버전을 확인한다.
2. WebDialer 서비스가 활성화되어 있는지 확인한다.
3. 업무에 WebDialer가 필요하지 않으면 즉시 해당 서비스를 비활성화한다.
4. Cisco 공식 수정 버전으로 업그레이드한다.
5. Release 15 환경에서 당분간 업그레이드가 불가능하면 Cisco 지침에 따라 해당 COP 파일을 적용한다.
6. 관리면 및 WebDialer 관련 서비스의 접근 출처를 제한한다.
7. 경계 장비, WAF, IDS/IPS에 cmplatform, WebDialer, Axis/WSDD 비정상 요청에 대한 탐지를 추가한다.
8. 이미 비정상 JSP, 비정상 Axis 서비스 또는 알 수 없는 파일이 나타났는지 확인한다.
9. 노출된 시스템에 대해 로그 역추적을 수행하고, 2026년 6월 3일 이후의 접근 기록을 중점적으로覆盖한다.
10. 파일 쓰기 또는 명령 실행 증거가 발견되면 단순 패치 업그레이드가 아니라 호스트 침해로 처리해야 한다.

15. 요약

CVE-2026-20230의 핵심은 단일 인터페이스 노출이 아니라, CUCM WebDialer, cmplatform 설치 상태 조회 로직, 내부 Axis 서비스 처리 및 파일 쓰기 능력 사이에 직렬화 가능한 신뢰 경계 실패가 형성되었다는 점이다.

이 체인은 다음과 같이 요약할 수 있다:

실제 악용 가능성은 WebDialer 활성화 여부, 대상 버전의 영향 여부, hostname 필터링 우회 가능 여부, 경로 착점 일치 여부, Web 컨테이너가 쓴 파일을 실행하는지 여부, 그리고 대상이 이미 패치를 적용했는지 여부에 달려 있다.

방어 관점에서 "특정 JSP 파일이 존재하는지"만으로 공격을 판단해서는 안 된다. 더 안정적인 방법은 다단계 체인을 중심으로 연관 탐지를 수행하는 것이다: WSDL 정보 획득, cmplatform 비정상 hostname, Axis/WSDD 특징, 경로 이동 쓰기, JSP 생성 접근 및 명령 매개변수 접근. 이 중 여러 단계가 짧은 시간 내에 동일한 출처에서 연속적으로 나타나면 고위험 침입 이벤트로 처리해야 한다.

References

• Cisco Security Advisory: Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability
• NVD: CVE-2026-20230
• SSD Secure Disclosure: Cisco Unified Communications Manager Arbitrary File Write to RCE
• Cisco Unified CM / Unified CM SME 공식 업그레이드 및 COP 수정 설명