CVE-2026-20230 Cisco Unified Communications Manager SSRF Escrita Arbitrária de Arquivo para RCE - Processo de Derivação e Reflexão do PoC

Âmbito de aplicação: apenas para laboratórios locais, ambientes de reprodução autorizados, validação de vulnerabilidades e análise de regras de proteção. Não utilize em alvos não autorizados. Este artigo analisa principalmente a cadeia de exploração do CVE-2026-20230, fenômenos verificáveis, lógica de julgamento e ideias de proteção, não fornecendo pacotes de ataque diretamente executáveis, conteúdo de WebShell ou cargas de execução de comandos.

1. Contexto da Vulnerabilidade

CVE-2026-20230 é uma vulnerabilidade de falsificação de solicitação do lado do servidor (Server-Side Request Forgery - SSRF) no Cisco Unified Communications Manager (Unified CM / CUCM) e no Cisco Unified Communications Manager Session Management Edition (Unified CM SME). A vulnerabilidade decorre de validação insuficiente de entrada no processamento de solicitações HTTP específicas, permitindo que um invasor, sem autenticação, construa solicitações que façam o dispositivo afetado acessar interfaces internas ou recursos locais em nome do invasor.

O impacto desta vulnerabilidade vai além da simples sondagem SSRF. Análises técnicas públicas mostram que, em versões específicas e quando determinados serviços estão ativados, a SSRF pode ser encadeada para capacidade de escrita arbitrária de arquivos. O invasor pode escrever conteúdo controlável em caminhos do sistema operacional subjacente e, em seguida, usando diretórios acessíveis pelo contêiner web ou mecanismos de carregamento de componentes do lado do servidor, converter a escrita de arquivos em execução de código.

A Cisco atribuiu a esta vulnerabilidade uma pontuação CVSS v3.1 de 8.6, com o vetor:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

Embora a pontuação CVSS indique "High", a Cisco classificou o Security Impact Rating como "Critical". A razão é que, se explorada com sucesso, pode-se escrever em arquivos do sistema operacional subjacente e possivelmente elevar privilégios para root.

É importante notar que a principal condição prévia para essa vulnerabilidade é que o serviço WebDialer esteja ativado. O WebDialer está desativado por padrão, portanto, não se pode julgar a vulnerabilidade apenas por ver um ativo CUCM. O verdadeiro julgamento de risco requer confirmar simultaneamente a versão do produto, o status do patch, o status do serviço WebDialer e se as interfaces relevantes estão acessíveis.

2. Por que não se pode julgar apenas se uma interface retorna 200?

Esta vulnerabilidade não é uma vulnerabilidade web comum do tipo "acessar uma URL fixa que retorna 200 indica existência". Sua cadeia de exploração envolve pelo menos três níveis:

1. Interfaces externamente acessíveis relacionadas ao WebDialer ou cmplatform.
2. Lógica de acesso interno que pode ser afetada pela SSRF.
3. Comportamento de escrita de arquivo ou implantação de serviço que pode ser acionado por solicitações internas subsequentes.

Portanto, obter HTTP 200, 302, 401, 404 ou 500 acessando isoladamente uma interface não prova diretamente que a vulnerabilidade existe ou não.

Por exemplo, uma interface WSDL do WebDialer acessível apenas indica que o alvo expôs funcionalidades relacionadas ao WebDialer, não prova que a SSRF subsequente conseguirá contornar a filtragem. Uma interface installClusterStatusExecute acessível também apenas indica a existência de uma entrada, não prova isoladamente que a escrita arbitrária de arquivo já ocorreu. Por outro lado, se uma etapa retornar algo anômalo, pode ser devido à versão do alvo, patch, resolução de hostname, permissões de caminho, dispositivo proxy ou status do serviço, não significando necessariamente que toda a cadeia de vulnerabilidades não exista.

Um julgamento mais seguro deve usar uma combinação de evidências em múltiplos estágios:

1. Confirmar que o alvo é um Cisco Unified CM / Unified CM SME.
2. Confirmar que o serviço WebDialer está ativado.
3. Confirmar que é possível obter o hostname real do alvo ou identificador interno do serviço.
4. Confirmar que o ponto de entrada SSRF está acessível e há indicações de que o servidor iniciou solicitações internas.
5. Em laboratório autorizado, confirmar se é possível gerar evidências de escrita controlada de arquivos.
6. Combinar logs do servidor, alterações no sistema de arquivos, logs do contêiner web e dados de alerta para julgar se houve acionamento real.

Somente quando "WebDialer ativado + versão afetada + comportamento SSRF confirmado + escrita controlada de arquivo confirmada" ocorrerem simultaneamente, deve-se julgar como explorável com alta confiança.

3. Ideia de Construção do PoC

Atualmente, o núcleo da cadeia de exploração pública não é apenas SSRF, mas uma combinação entre SSRF e mecanismos Axis/Java Web Service, escrita de logs ou lógica de processamento de arquivos de descrição de implantação.

A ideia geral pode ser resumida como:

Obtenção de informações do WebDialer
    ↓
Obter o hostname real do alvo
    ↓
Acionar SSRF através da interface relacionada ao cmplatform
    ↓
Acessar caminhos internos de gerenciamento do WebDialer / Axis
    ↓
Escrever ou implantar conteúdo controlável de descrição de serviço
    ↓
Criar nova capacidade de chamada de serviço ou escrita de arquivo
    ↓
Converter capacidade de escrita de arquivo em script acessível via web
    ↓
Em ambientes específicos, alcançar execução de comandos

A partir do design da cadeia, o hostname é um ponto chave. Algumas lógicas de filtragem podem bloquear endereços locais comuns como 127.0.0.1, localhost, mas o hostname real do alvo pode ser permitido no fluxo de solicitação subsequente. Portanto, o PoC primeiro extrai o nome do host real das informações WSDL do WebDialer e o usa como prefixo de acesso interno na cadeia SSRF.

O segundo ponto chave é a lógica relacionada ao serviço Axis. O PoC não faz upload direto de arquivos para o diretório web, mas através da cadeia de processamento interno do servidor, faz com que componentes do lado do servidor escrevam conteúdo controlável pelo invasor em caminhos específicos. Esse processo é essencialmente uma combinação de "solicitação interna do servidor + comportamento de escrita de configuração/log de componente + path traversal/controle de caminho".

O terceiro ponto chave é a escrita em duas fases. A primeira fase normalmente estabelece um ponto de entrada mais estável para escrita de arquivos. A segunda fase usa essa capacidade para escrever o script de execução de comandos em um diretório acessível via web. A razão para isso é que escrever toda a lógica de execução de comandos em uma única etapa via SSRF pode ser afetado por codificação, comprimento, estrutura XML, permissões de caminho e comportamento de análise do servidor, enquanto a abordagem em duas fases facilita a divisão de cargas complexas.

Este artigo não fornece pacotes de ataque completos ou conteúdo de WebShell. Para proteção e verificação, basta entender as seguintes características principais:

Entrada de solicitação externa: interfaces relacionadas ao status de instalação do cmplatform
Entrada de obtenção de informações: interfaces WSDL/services do WebDialer
Destino de encaminhamento interno: caminhos relacionados a WebDialer / Axis / AdminService
Comportamentos chave: SSRF, solicitação interna do servidor, escrita controlada de arquivo, arquivo acessível via web
Risco final: escrita arbitrária de arquivo, implantação de WebShell, execução de comandos, caminho para elevação de privilégio root

4. Lógica de Obtenção do hostname

O PoC primeiro precisa obter o hostname real do alvo, em vez de apenas usar o endereço IP ou domínio externo.