Kentico Xperience <= 13.0.178 Staging Sync Server None Password Type Authentication Bypass

Falha de bypass de autenticação (CWE-288) no serviço de sincronização (Staging/Sync Service) do Kentico Xperience 13, explorável remotamente e sem autenticação, que permite a um atacante assumir o papel de um usuário administrativo e controlar objetos administrativos do CMS. A gravidade real depende de uma pré-condição que a nota CVSS 9.8 não deixa clara: o Staging Service precisa estar habilitado e configurado com autenticação por usuário/senha — mas pesquisadores da watchTowr afirmam que essa é uma configuração comum entre clientes enterprise, não um caso de borda.

O componente vulnerável é o webservice SOAP CMS.Synchronization.WSE3.SyncServer, exposto em /CMSPages/Staging/SyncServer.asmx, usado para sincronizar conteúdo entre ambientes (staging/produção). Ele foi construído sobre Microsoft.Web.Services3.dll, uma biblioteca WSE3 (Web Services Enhancements 3.0) obsoleta desde ~2012 e superada pelo WCF, que implementa autenticação via cabeçalho WS-Security com um UsernameToken.

O padrão WS-Security define múltiplos 'Password Types' para o UsernameToken: PasswordText (senha em claro), PasswordDigest (hash) e PasswordNone (nenhuma senha, previsto para cenários onde a prova de identidade vem de outro mecanismo). A falha está no tratamento desse terceiro tipo pelo SyncServer: quando o servidor está configurado para autenticação por usuário/senha, a implementação aceita um UsernameToken com Password Type 'None' sem exigir nem validar qualquer credencial, autenticando a requisição mesmo sem senha correta.

Essa mesma superfície já foi palco de uma deserialização insegura via SoapFormatter explorada na CVE-2019-10068 (desde então endurecida), o que indica que o endpoint de staging é historicamente um ponto de fragilidade no produto. O CVE-2025-2747 corresponde ao achado que a watchTowr catalogou como WT-2025-0011, distinto de um bypass anterior (WT-2025-0006, corrigido no Hotfix 173) encontrado na mesma pesquisa.

O comportamento de exploração varia por nível de hotfix: antes do Hotfix 173, o bypass funciona com qualquer nome de usuário informado no token; entre os Hotfixes 173 e 177 (inclusive), passou a ser necessário informar um nome de usuário válido existente no sistema (o padrão observado é 'admin'). O Hotfix 178 corrige definitivamente o tratamento do Password Type 'None'.

O vetor é uma única requisição HTTP POST ao endpoint SOAP do SyncServer, sem necessidade de sessão prévia, cookie ou token — é rede pura contra um serviço exposto na aplicação web. O atacante monta um envelope SOAP com cabeçalho WS-Security contendo um UsernameToken cujo Password Type é 'None', dispensando o envio de qualquer senha; a diferença prática entre versões é apenas se o username pode ser arbitrário ou precisa corresponder a uma conta real (tipicamente 'admin').

A pré-condição decisiva, confirmada pela watchTowr, é que o Staging Service precisa estar habilitado E configurado com autenticação por usuário/senha — a alternativa de autenticação por certificado X.509 não é afetada. Sem o Staging Service ativo nessa configuração, o endpoint sequer aceita a lógica de autenticação vulnerável.

Uma vez autenticado indevidamente, o atacante ganha acesso à API de sincronização de staging, que existe justamente para propagar objetos administrativos (páginas, conteúdo, configurações) entre ambientes — ou seja, o mesmo canal que a CMS usa para replicar mudanças legítimas de admin pode ser abusado para injetar objetos administrativos arbitrários. A pesquisa da watchTowr documenta ainda uma vulnerabilidade separada de RCE pós-autenticação (WT-2025-0007) na mesma plataforma; encadear esse bypass com falhas de execução de código é o cenário de maior impacto, embora a CVE-2025-2747 isoladamente já seja suficiente para comprometer a integridade administrativa do CMS. A CISA confirma exploração ativa em campo (entrada no catálogo KEV desde 20/10/2025, prazo de correção 10/11/2025) e há PoC pública e template Nuclei, o que reduz a barreira técnica para exploração massiva.

A correção definitiva é o Hotfix 13.0.178 (cumulativo, disponível via Kentico Xperience Installation Manager ou download no DevNet). O fornecedor mantém política de hotfix semanal cumulativo para a linha 13.x, então qualquer instalação em versão anterior a 178 deve ser considerada vulnerável até a aplicação do hotfix.

Se a atualização imediata não for viável, os paliativos reais documentados pelos pesquisadores são: (1) desabilitar o Staging/Sync Service inteiramente, se a sincronização entre ambientes não for uma necessidade operacional ativa; ou (2) se o serviço precisar permanecer ativo, migrar o tipo de autenticação de usuário/senha para autenticação por certificado X.509, que não é afetada pela falha. Como controle compensatório de rede, restringir o acesso ao caminho /CMSPages/Staging/SyncServer.asmx apenas aos IPs de servidores de staging legítimos (via proxy reverso, firewall de aplicação ou ACL) reduz a exposição, embora não elimine o problema se um atacante já estiver na rede interna.

O que NÃO mitiga: trocar a senha da conta administrativa não resolve nada, porque a falha está no processamento do Password Type 'None' do WS-Security — em versões vulneráveis a validação de senha simplesmente não ocorre para esse tipo de token, então uma senha forte é irrelevante ao ataque.

Procure no log web/IIS por requisições POST para /CMSPages/Staging/SyncServer.asmx com o SOAPAction ProcessSynchronizationTaskData, especialmente quando acompanhadas de cabeçalho WS-Security (namespace wsse) cujo UsernameToken não traga um valor de senha válido — indício de tentativa de uso do Password Type 'None'. Volume anômalo de requisições a esse endpoint partindo de IPs fora da rede de staging conhecida é outro sinal relevante.

Não há um indicador de comprometimento único e confiável documentado publicamente além do padrão de requisição em si; como existe PoC pública e template Nuclei, scanners automatizados tendem a gerar esse tráfego característico em varreduras massivas, então presença de logs desse endpoint com falhas de campos SOAP incompletos já merece investigação mesmo sem confirmação de sucesso.