w5m1n9/cisco-unified-communications-manager-server-side-forgery-request-vulnerability-cve-2026-20230Analisa a SSRF CVE-2026-20230 para escrita arbitrária de arquivos e RCE no Cisco Unified Communications Manager, fornecendo derivação de PoC, lógica de detecção e orientação defensiva.
Â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.
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.
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:
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:
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.
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
O PoC primeiro precisa obter o hostname real do alvo, em vez de apenas usar o endereço IP ou domínio externo.
A razão é que a lógica de filtragem SSRF pode não apenas verificar o destino final da conexão, mas também validar o campo hostname, a string da URL, palavras-chave de endereço local, etc. Endereços locais comuns como 127.0.0.1, localhost podem ser bloqueados, enquanto o hostname real do dispositivo pode ser considerado um nome de nó válido em alguns cenários.
As interfaces que podem ser usadas para auxiliar na determinação geralmente estão relacionadas às informações WSDL do WebDialer. Após acessar esse tipo de WSDL, a resposta pode conter o endereço do serviço, campo location ou outros identificadores de host analisáveis. O PoC extrai o hostname da URL do texto da resposta e o usa como alvo de acesso interno para o próximo estágio SSRF.
Os critérios de julgamento nesta fase devem ser:
Se a análise do hostname falhar, o PoC pode reverter para o IP alvo, mas isso reduz significativamente a taxa de sucesso. Em ambientes reais, as causas comuns de falha na análise do hostname incluem WebDialer não ativado, interface restrita por controle de acesso, resposta reescrita por proxy reverso, certificado ou configuração de serviço incompleta.
O ponto de acionamento SSRF está na lógica de consulta de status de instalação relacionada ao cmplatform. Essa funcionalidade é originalmente usada para consultar o status de instalação de nós do cluster. O servidor monta uma solicitação interna com base no identificador de nó ou hostname enviado pelo usuário.
O problema central da vulnerabilidade é que o parâmetro hostname controlável pelo invasor não é estritamente limitado a nomes de nó válidos ou hosts confiáveis, permitindo que o parâmetro seja construído em caminhos de acesso interno mais complexos. O servidor então faz solicitações em nome do invasor para interfaces internas.
Nesta fase, o ponto chave não é "conseguir acessar uma URL externa", mas "fazer com que o próprio dispositivo CUCM acesse as interfaces de gerenciamento internas do WebDialer / Axis que são acessíveis apenas localmente ou por componentes internos". Portanto, o valor da SSRF vem de dois aspectos:
Na verificação autorizada, não se deve julgar o sucesso da SSRF apenas pelo código de status HTTP. Evidências mais confiáveis incluem:
Na cadeia pública, a SSRF é usada para acessar interfaces de serviço relacionadas ao Axis e tentar escrever conteúdo de descrição de implantação de serviço. O invasor, ao construir estruturas XML/WSDD especiais, faz com que componentes do servidor escrevam conteúdo controlável em caminhos especificados durante o processamento.
A essência desta fase não é upload tradicional de arquivo, mas abuso da lógica de processamento de componentes do servidor:
Parâmetros controláveis pelo usuário
↓
Solicitação interna SSRF
↓
Processamento de serviço Axis / Web
↓
Escrita de descrição de implantação controlável ou log
↓
Geração de arquivo em caminho especificado
Do ponto de vista da análise de segurança, aqui estão alguns pontos chave:
Portanto, o ponto de alto risco do CVE-2026-20230 não é apenas a SSRF, mas o fato de que a SSRF pode cruzar limites de confiança, entrar na cadeia de gerenciamento/implantação de serviços internos e, finalmente, acionar a escrita controlável de arquivos.
O design do PoC geralmente adota escrita em duas fases, em vez de concluir a execução de comandos em uma única etapa.
A primeira fase é usada para criar uma capacidade simples de escrita de arquivo. O objetivo desta fase é permitir que o invasor, através de um caminho acessível via web, escreva conteúdo em locais especificados no servidor.
A segunda fase utiliza a capacidade de escrita da primeira fase para escrever o script de execução de comandos em um diretório acessível via web. Em seguida, o invasor pode acionar a execução de comandos do sistema através de parâmetros HTTP.
As vantagens do design em duas fases são:
No entanto, do ponto de vista da proteção, a escrita em duas fases também cria uma superfície de detecção mais clara:
O fluxo do PoC atual pode ser resumido como:
Em termos de taxa de sucesso da exploração, os pontos de falha mais críticos geralmente se concentram em:
Portanto, este PoC tem alta explorabilidade em versões afetadas específicas e caminhos padrão correspondentes, mas não é estável para todos os ativos CUCM.
O julgamento de sucesso do CVE-2026-20230 não pode ser baseado apenas na execução completa do script. Um julgamento mais razoável deve ser dividido em quatro níveis.
Condições são:
WSDL do WebDialer acessível
ou página services acessível
ou interface relacionada ao cmplatform acessível
Isso apenas indica que o alvo possui uma superfície de ataque relacionada, não prova que a vulnerabilidade é explorável.
Condições são:
Versão alvo está na faixa afetada
WebDialer ativado
hostname pode ser analisado
Retorno do ponto de entrada SSRF é resposta anômala, mas razoável do servidor
Nesse caso, deve-se continuar a verificação com logs do servidor ou laboratório autorizado.
Condições são:
Arquivo controlado pelo servidor aparece após SSRF
ou Arquivo anômalo criado por processo do servidor aparece no diretório web
ou Serviço novo e anômalo aparece na página services
ou Conteúdo controlável de descrição de implantação aparece nos logs
Neste nível, pode-se confirmar que a cadeia de vulnerabilidade ultrapassou o estágio SSRF comum e entrou no risco de escrita arbitrária de arquivo.
Condições são:
O script acessível via web escrito é analisado e executado com sucesso
E é possível observar o resultado da execução do servidor através de comando de teste autorizado
Apenas neste nível pode-se julgar que a execução remota de comandos foi estabelecida. Escrita de arquivo bem-sucedida não equivale necessariamente a RCE bem-sucedido, mas em ambientes de serviço de alta privilégio como CUCM, a escrita de arquivo já constitui risco grave.
Este artigo não fornece exemplos de execução de exploit diretamente utilizáveis para ataque.
Em ambientes autorizados, recomenda-se priorizar o uso de "verificação somente leitura" ou "validação não destrutiva", por exemplo:
python3 CVE-2026-20230-check.py https://127.0.0.1 --check
Os itens de verificação recomendados incluem:
Não é recomendado executar validação completa de escrita de arquivo ou execução de comandos em sistemas de produção. Mesmo em testes autorizados, deve-se priorizar a realização em laboratórios isolados, ambientes com snapshots ou conforme o fluxo de verificação sugerido pelo fabricante.
Os limites de segurança desse tipo de PoC devem ser claros.
Primeiro, não executar comandos por padrão. A fase de execução de comandos é uma verificação de alto risco, que pode facilmente causar alteração de estado do sistema, poluição de logs, anomalias de serviço ou resposta coordenada de dispositivos de segurança.
Segundo, não escrever WebShell por padrão. Mesmo que seja um arquivo de teste, pode ser considerado como atividade de invasão real por EDR, mecanismos de detecção de WebShell, monitoramento de integridade de arquivos ou sistemas de auditoria de conformidade.
Terceiro, não fazer varredura em lote contra alvos na internet pública. Esta vulnerabilidade não requer autenticação e os alvos são principalmente infraestruturas de comunicação empresarial; a varredura e exploração não autorizadas apresentam riscos extremamente altos.
Quarto, separar o modo de verificação do modo de exploração. Recomenda-se dividir o PoC em dois scripts: um apenas para identificação de ativos e julgamento de estado do serviço, e outro apenas para verificação de escrita de arquivo em laboratório local ou ambientes explicitamente autorizados.
Quinto, limitar o escopo do alvo. O PoC pode incluir mecanismos de proteção como endereço local, segmento de rede privada, domínio de lista branca, parâmetros de confirmação de autorização, para evitar atingir sistemas de terceiros por engano.
Sexto, desabilitar a fase RCE por padrão. Mesmo que o código de pesquisa seja mantido, deve-se exigir que o usuário informe explicitamente um parâmetro de confirmação de autorização antes de permitir a entrada na validação de escrita de arquivo ou execução de comandos.
Do ponto de vista da detecção de tráfego, não se pode combinar apenas um nome de arquivo fixo, nome de serviço fixo ou nome JSP fixo. Os nomes de serviço, nomes de arquivo e caminhos nos PoCs públicos podem ser modificados, e regras de string única são fáceis de gerar falsos negativos.
Uma abordagem de detecção mais razoável é extrair características com base nas fases da cadeia de ataque.
Foco principal:
/webdialer/Version.jws?wsdl
/webdialer/services
WebDialer WSDL
Axis services listing
Se um cliente externo acessar o WSDL e depois a interface de status de instalação do cmplatform em um curto período, o nível de risco deve ser aumentado.
Foco principal:
/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
parâmetro hostname com crescimento anômalo
parâmetro hostname contendo separadores de caminho codificados em URL
parâmetro hostname contendo características de caminho interno como webdialer, services, AdminService, platformcom, installstages
O ponto chave nesta fase é que o parâmetro hostname não se parece mais com um nome de host normal, mas apresenta características de caminho, URL, codificação e XML.
Foco principal:
deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole
Quando esses campos aparecem simultaneamente, deve-se suspeitar fortemente que o invasor está tentando escrever conteúdo controlável através de arquivos de descrição de implantação de serviço Axis.
Foco principal:
axis2-web
platform-services
Escrita de arquivo JSP
Parâmetros que contêm combinação de nome de arquivo e conteúdo do arquivo
Path traversal de diretório web
common/log/taos-log-a
tomcat/webapps
Se o tráfego de ataque contiver muitos ../, path traversal codificado em URL, extensão JSP e caminho Tomcat WebApp, deve ser julgado como alto risco.
Foco principal:
Novo JSP acessado
Parâmetros de solicitação contendo parâmetros de comando como pwd, cmd, command, exec, i
Resposta contendo formato de saída de comando do sistema
Mesmo IP de origem concluindo ações consecutivas de obtenção de WSDL, SSRF, escrita e execução em curto período
Do ponto de vista do design de regras, recomenda-se a detecção em fases:
1. Obtenção de informações do WebDialer: alerta baixo ou médio.
2. SSRF cmplatform com hostname anômalo: alerta alto.
3. Características combinadas de Axis/WSDD/LogHandler: alerta grave.
4. Escrita de arquivo JSP ou parâmetros de execução de comandos: alerta grave.
5. Correspondência multi-fase: atualizado diretamente para evento de invasão.
Durante a investigação de emergência, recomenda-se verificar os seguintes locais e fenômenos:
installClusterStatusExecute?/tmp, diretório WebApp, diretório de logs, existem arquivos de teste ou arquivos desconhecidos?Se houver suspeita de exploração, deve-se isolar o acesso à interface de gerenciamento, preservar logs e evidências do sistema de arquivos e, em seguida, realizar atualização de patch, limpeza de WebShell, limpeza de serviços anômalos e rotação de contas/credenciais.
A correção fundamental é atualizar para a versão corrigida oficial da Cisco ou aplicar o pacote de correção temporário fornecido pela Cisco.
Recomendações gerais de tratamento:
O ponto chave do CVE-2026-20230 não está na exposição de uma única interface, mas na falha do limite de confiança que pode ser encadeada entre o WebDialer do CUCM, a lógica de consulta de status de instalação do cmplatform, o processamento interno do serviço Axis e a capacidade de escrita de arquivo.
Esta cadeia pode ser resumida como:
Solicitação externa não autenticada
↓
Confirmação da superfície de exposição do WebDialer
↓
Obtenção do hostname real
↓
SSRF cmplatform
↓
Acesso ao serviço interno Axis
↓
Escrita de descrição de serviço controlável ou log
↓
Arquivo acessível via web no local
↓
Risco de execução de comandos e elevação de privilégio root
A explorabilidade real depende de: WebDialer ativado ou não, versão alvo afetada ou não, se a filtragem de hostname pode ser contornada, se o ponto de destino corresponde, se o contêiner web executa o arquivo escrito e se o alvo já aplicou o patch.
Do ponto de vista defensivo, não se pode confiar apenas em "existência de um arquivo JSP específico" para julgar o ataque. Uma abordagem mais segura é realizar detecção correlacionada em torno da cadeia multi-fase: obtenção de informações WSDL, hostname anômalo do cmplatform, características Axis/WSDD, escrita com path traversal, acesso a JSPs e parâmetros de comando. Se várias dessas fases aparecerem consecutivamente da mesma origem em curto período, deve-se tratar como evento de invasão de alto risco.