Desenvolvedor armazena site inteiro dentro de um favicon, e o navegador consegue executá-lo

O favicon deixou de ser só um ícone: virou um vetor de execução. Tim Wehrle não usou compressão, não recorreu a chunks PNG ou metadados, ele escreveu bytes brutos de HTML diretamente nos canais RGB de uma imagem 9×9, pixel a pixel. Cada pixel carrega três bytes (R-G-B), e o payload de 208 bytes + cabeçalho de 4 bytes ocupa exatamente 71 pixels. Isso é menos de 1 KB, mas é código-fonte vivo, não apenas dados armazenados, mas reconstruído em tempo real via TextEncoder, getImageData() e DOMParser. A técnica depende de duas APIs estáveis há anos (Canvas 2D e Typed Arrays), mas exige que o navegador interprete uma imagem como fonte de bytes, não como recurso visual. É um exercício de DX radical: zero requisições, zero rede, zero cache externo, só o DOM, o canvas e o favicon já carregado.

O que torna isso tecnicamente distinto de outros experimentos com esteganografia web é a ausência de camadas intermediárias. Não há base64, não há WebAssembly, não há fallback para SVG ou ICO. É pura manipulação de buffer: os mesmos pixels que o navegador renderiza como cor são lidos como sequência de bytes UTF-8 e injetados como HTML válido. Isso colide com o que o CEVIU já reportou sobre o HTML-in-canvas, não é renderização dentro do canvas, mas *recuperação de HTML a partir dele*. Aqui, o canvas é um leitor de disco, não um display.

A cobertura anterior do CEVIU sobre HTML-in-canvas (08/06/2026) tratava de uma API experimental do Chrome para *renderizar* HTML dentro de um contexto canvas, preservando eventos, estilo e acessibilidade. Já esta técnica não renderiza nada no canvas: usa o canvas apenas como interface de leitura de pixels. É um deslocamento conceitual: do canvas como saída para o canvas como entrada. Também difere dos Favicon Trojans descritos em estudo de julho/2025, que exploram o canal alfa de arquivos ICO. Wehrle usa PNG puro, sem transparência, e não esconde código, ele *declara* o favicon como conteúdo executável. Nada foi anunciado antes; agora é demonstrável, funcional e publicado com código aberto.

Isso importa porque expõe uma brecha de mentalidade na segurança frontend: navegadores validam formato de arquivo (PNG), mas não conteúdo semântico. Um favicon pode carregar e executar código sem disparar CSP, sem tocar o network tab, sem acionar scanners de conteúdo. Já sabemos que hashes de favicon são usados para rastrear painéis maliciosos, agora sabemos que o próprio favicon pode *ser* o painel. Para devs, é um lembrete prático: otimização extrema (como reduzir Docker para 80 MB ou usar AVIF) tem limites físicos, mas também limites conceituais. Quando você começa a tratar cada byte de uma imagem como potencialmente executável, sua noção de 'recurso estático' desaba. E isso afeta decisões reais: como você valida imagens de terceiros? Como testa CSP com payloads embutidos? Como audita uma página que não faz requisições, mas ainda assim carrega HTML completo?