CVE-2020-13965

O Roundcube Webmail permitia que anexos do tipo text/xml fossem renderizados em janela de pré-visualização (preview) dentro do webmail. Como navegadores modernos interpretam namespaces XHTML dentro de XML, um atacante podia embutir um elemento via namespace e executar JavaScript arbitrário no contexto da sessão da vítima só com o clique/preview do anexo. A falha está no catálogo KEV da CISA, ou seja, há exploração confirmada em ambiente real, o que eleva a prioridade de correção mesmo com CVSS moderado (6.3).

A causa raiz (CWE-79, XSS refletido/armazenado via conteúdo controlado pelo atacante) está na lista de mimetypes que o Roundcube considera seguros para abrir em preview inline. Em versões vulneráveis, 'text/xml' fazia parte da lista padrão de 'client_mimetypes' (config/defaults.inc.php e o fallback hardcoded em rcube_config.php). Quando o usuário abre/pré-visualiza um anexo desse tipo, o Roundcube renderiza o conteúdo diretamente no iframe/preview do webmail, delegando a interpretação ao motor XML do próprio navegador.

O problema é que o parser XML do navegador reconhece o namespace 'http://www.w3.org/1999/xhtml'. Um atacante pode declarar esse namespace em um elemento arbitrário (ex.: ) e o navegador trata o conteúdo como HTML/XHTML válido, executando o embutido — efetivamente contornando qualquer sanitização de HTML que o Roundcube aplicaria a anexos text/html, porque o código nunca esperava que text/xml carregasse markup executável.

A correção do fornecedor (commit 884eb61) atacou o problema em duas camadas: removeu 'text/xml' da lista padrão de mimetypes permitidos para preview em rcube_config.php, e — mais importante — adicionou um filtro explícito em rcmail_supported_mimetypes() (program/steps/mail/func.inc) que remove 'text/xml' do conjunto de tipos suportados independentemente de como o administrador tenha configurado 'client_mimetypes', com o comentário do próprio time: 'We cannot securely preview XML files as we do not have a proper parser'. Ou seja, o fornecedor reconhece que não dava para sanitizar XML de forma confiável e optou por bloquear a categoria inteira.

O vetor é um e-mail com anexo MIME do tipo 'text/xml' contendo um elemento com o namespace XHTML citado, disfarçado como conteúdo inócuo (ex.: alert.xml). O atacante não precisa de credenciais no Roundcube nem de configuração não padrão do servidor — só precisa conseguir entregar o e-mail à caixa da vítima (qualquer remetente externo, sem necessidade de bypass de filtro de spam sofisticado nos relatos públicos). A pré-condição real é interação do usuário (UI:R no vetor CVSS): a vítima precisa abrir a mensagem e clicar no anexo para acionar o preview — não há execução automática ao simplesmente abrir o e-mail.

A prova de conceito pública (DrunkenShells) demonstra a criação do e-mail com ferramentas de montagem MIME (mpack), ajustando manualmente o Content-Type para 'text/xml' já que essas ferramentas não geram esse tipo nativamente. Ao clicar no anexo, o JavaScript do atacante executa no contexto da sessão do webmail da vítima.

Uma vez executado, o payload roda com os mesmos privilégios da sessão web do usuário dentro do Roundcube, permitindo ações como leitura, exfiltração ou exclusão de e-mails, manipulação da interface e potencialmente encadeamento com outras falhas de sessão — o disclosure público remete à mesma classe de impacto documentada em CVE-2020-12625, outra XSS via preview no Roundcube. Não há elevação a acesso de sistema operacional ou ao servidor; o impacto fica confinado à sessão do webmail da vítima (C/I/A todos 'Low' no vetor CVSS).

A correção definitiva é atualizar para Roundcube 1.4.5 (ramo 1.4.x) ou 1.3.12 (ramo LTS 1.3.x), que removem 'text/xml' da lista de tipos permitidos para preview e bloqueiam esse tipo mesmo que um administrador o reintroduza manualmente na configuração 'client_mimetypes'.

Se a atualização não for possível de imediato, o paliativo real é editar a configuração 'client_mimetypes' no config.inc.php da instalação e garantir que 'text/xml' não esteja na lista de tipos habilitados para preview — isso reduz a superfície de ataque nas versões vulneráveis, já que o comportamento inseguro depende justamente desse tipo estar na lista permitida. Vale lembrar que esse ajuste manual só funciona nas versões pré-patch; nas versões corrigidas o bloqueio é forçado no código independente da configuração.

O que não funciona como mitigação: confiar em filtros de anexo do lado do cliente de e-mail (a exploração ocorre dentro do preview do próprio Roundcube, não no cliente de e-mail da vítima) ou assumir que renomear a extensão do arquivo (.xml para outra coisa) impede o ataque — o que importa é o Content-Type MIME declarado no anexo, não a extensão exibida.

Em nível de gateway de e-mail ou análise de anexos, o indicador é um anexo com Content-Type/Content-Disposition indicando 'text/xml' (ou nome de arquivo com extensão .xml) cujo conteúdo declara o namespace 'xmlns:*="http://www.w3.org/1999/xhtml"' associado a elementos como 'script' — esse padrão é atípico para XML legítimo de troca de dados e é o artefato central da prova de conceito pública.

No lado do servidor Roundcube não há um log nativo que registre 'anexo pré-visualizado como XML'; a exploração ocorre no navegador da vítima após interação, então não existe um sinal de rede ou de aplicação confiável e específico para essa CVE além da inspeção do conteúdo do anexo em trânsito (gateway de e-mail/antivírus) ou da revisão manual de e-mails suspeitos recebidos antes da atualização.