Zero-Day & Exploits
Canva Android: falhas de WebView e sessão em 2026
CVEs de 2026 no Canva Android: origens externas, WebView privilegiada, exposição de headers e testes locais de fronteiras de confiança.
Uma WebView privilegiada pode aproximar dois mundos que deveriam permanecer separados: conteúdo web externo e funcionalidades autenticadas do aplicativo. Duas falhas publicadas em setembro de 2026 descrevem esse problema no Canva para Android. A análise precisa distinguir a origem do documento da autoridade que a aplicação concede ao conteúdo carregado.
CVE-2026-85085 e CVE-2026-85094
Os registros mantidos pelo CNA do Canva identificam versões Android anteriores à 2.376.0. A CVE-2026-85085 envolve carregar uma origem externa em uma WebView privilegiada e permitir comunicação associada à sessão do usuário. A CVE-2026-85094 descreve retorno inadequadamente restrito de headers para uma origem externa nesse contexto. Os registros foram publicados em 4 de setembro de 2026.
Essa descrição não comprova que o Canva no navegador ou no iOS tenha o mesmo problema. Também não revela nomes internos de métodos, endpoints ou headers exploráveis. Um texto técnico responsável pode explicar a fronteira de segurança sem inventar esses detalhes. O portal de confiança do Canva é uma referência oficial para acompanhar informações do fornecedor.
| Identificador | Classe de problema | Produto indicado |
|---|---|---|
| CVE-2026-85085 | Origem externa em contexto privilegiado | Canva Android antes de 2.376.0 |
| CVE-2026-85094 | Exposição de headers ligados à sessão | Canva Android antes de 2.376.0 |
| Fora da evidência | Mesmo efeito em qualquer plataforma | Não demonstrado pelos registros |
Origem web e autoridade nativa
Uma origem web é definida por protocolo, host e porta. Caminho e query não transformam dois documentos do mesmo host em origens diferentes. Um aplicativo que carrega conteúdo web pode acrescentar funcionalidades nativas: acesso a estado de sessão, seleção de arquivos ou chamadas realizadas pelo host.
Essa ponte precisa de uma política própria. Conteúdo que parece uma página comum pode receber mais autoridade do que receberia em um navegador. Quando uma navegação muda de uma origem controlada para outra, o contexto privilegiado precisa ser retirado ou revalidado antes da entrega de qualquer funcionalidade.
A orientação de segurança do Android sobre native bridges descreve riscos associados a interfaces expostas a conteúdo não confiável. A recomendação aplicada aqui é revisar origem e capacidade em cada operação, incluindo frames e transições. Uma checagem feita apenas no endereço inicial pode perder um redirect ou uma navegação posterior.
Headers também carregam segredos e contexto
Um header não é seguro apenas porque está fora do corpo. Dependendo da aplicação, ele pode conter credenciais, identificadores internos ou metadados da sessão. Retornar indiscriminadamente headers de uma operação autenticada a código de outra origem amplia o acesso daquele conteúdo.
Uma política mais verificável usa uma lista de campos estritamente necessários para o recurso. O projeto precisa separar headers recebidos do servidor, headers acrescentados pelo host e campos destinados apenas a diagnóstico. Logs e mensagens de erro devem seguir a mesma regra. Caso contrário, a interface normal pode ser restrita, mas uma falha devolve o conteúdo que se tentou esconder.
Não há, nas descrições citadas, uma lista pública completa dos headers efetivamente expostos. Portanto, o artigo não apresenta cookies ou tokens reais do Canva nem presume um nome de campo específico. O laboratório usa uma aplicação fictícia para ilustrar validação de origem.
Laboratório: comparar a origem completa
Este exemplo não acessa o Canva. Ele permite apenas uma origem inventada em .test e avalia seis URLs locais. O retorno de headers está vazio por escolha do modelo, evitando associar origem aceita a acesso irrestrito.
import json
from urllib.parse import urlsplit
permitidas = {('https', 'editor.aurora.test', 443)}
def origem_aprovada(endereco):
try:
url = urlsplit(endereco)
if url.username is not None or url.password is not None:
return False
if url.scheme != 'https' or not url.hostname:
return False
return (url.scheme, url.hostname.lower(), url.port or 443) in permitidas
except ValueError:
return False
casos = [('https://editor.aurora.test/painel',
True),
('https://editor.aurora.test.evil.test',
False),
('https://[email protected]',
False),
('http://editor.aurora.test',
False),
('https://editor.aurora.test:8443',
False),
('https://evil.test',
False)]
assert all(origem_aprovada(url) == esperado for url, esperado in casos)
print(json.dumps({'casos':len(casos),
'aprovados':sum(origem_aprovada(url) for url,
_ in casos),
'headers_publicados':[]},
ensure_ascii=False))
A URL com o host legítimo seguido de .evil.test é recusada porque o hostname completo muda. A variante com @ também é recusada: o texto antes desse símbolo pode representar credenciais, não o destino. A porta 8443 é diferente da origem aprovada e HTTP não é equivalente a HTTPS.
O resultado esperado contém seis casos e apenas um aprovado. A normalização usada é intencionalmente pequena. Produção exige uma biblioteca adequada para URLs, tratamento coerente de IDNA, redirects, frames e a semântica do motor web. O exemplo mostra por que contains ou uma comparação de sufixo sem fronteiras não deve decidir confiança.
Matriz de auditoria de uma aplicação híbrida
| Situação | Pergunta de segurança |
|---|---|
| Navegação externa | A ponte continua disponível? |
| Redirect | A origem final é reavaliada? |
| Frame inserido | Qual origem é reconhecida como chamadora? |
| Sessão encerrada | Tokens e callbacks antigos são revogados? |
| Falha de rede | A resposta revela headers ou detalhes privados? |
Em um teste autorizado, registre versão instalada, origem inicial e final, recurso chamado e resultado observável. Uma requisição de rede não comprova sozinha leitura de sessão. É necessário demonstrar quais dados ficaram acessíveis e para qual contexto, usando contas e conteúdo de laboratório.
Teste também respostas negativas: uma origem não autorizada deve ser recusada sem emitir a requisição privilegiada. Isso distingue validação anterior à ação de um erro apresentado depois que a operação já aconteceu. Para operações assíncronas, vincule o callback à origem e sessão que ainda estão vigentes.
Correção, acompanhamento e limites
O marco indicado nos registros é a versão 2.376.0. Para uso atual, instale a versão compatível disponibilizada oficialmente e confirme a versão executada no inventário. Não basta atualizar apenas a biblioteca WebView se a política insegura está na aplicação que a utiliza.
As recomendações do Canva para APIs e sua política de conteúdo para apps ajudam a situar controles de integrações. Essas páginas tratam do ecossistema de desenvolvimento e não devem ser confundidas com uma descrição completa do aplicativo Android afetado.
Perguntas frequentes
A falha permite concluir que todas as contas vazaram? Não. Possibilidade técnica, pré-condição e incidência real precisam de evidências diferentes.
Liberar uma URL inicial resolve? Não necessariamente. Mudanças de origem e chamadas posteriores também devem respeitar a política.
O código é um exploit do Canva? Não. É um teste de um contrato de origem em dados inventados.
O caso evidencia que um conteúdo externo deve conservar sua classificação de não confiável mesmo quando aparece dentro da interface de um aplicativo conhecido. A autoridade deve acompanhar a origem validada e a operação autorizada, não a aparência da tela.
