O que aconteceu: o que é a CVE-2026-106109

A CVE-2026-106109 descreve um problema no Quasar Framework, usado para construir interfaces com Vue.js. Conforme o registro público consultado, versões de 1.0.0 até antes da 3.3.0 do pacote @quasar/app-vite podem remover recursivamente o diretório de saída resolvido antes do build sem rejeitar caminhos perigosos. Entre os casos citados estão a raiz do projeto, o diretório do usuário, raízes do sistema e caminhos externos resolvidos por links simbólicos.

O risco não está em uma requisição recebida pela aplicação já publicada. Ele aparece no processo de compilação, quando uma configuração de diretório de saída é interpretada pelo tooling. Se o caminho for apontado para um local amplo ou inesperado, a limpeza preparatória pode apagar arquivos que não deveriam fazer parte do artefato. O impacto real depende da configuração, das permissões do usuário que executa o build e do ambiente onde a compilação acontece.

Como funciona

Ferramentas de build costumam limpar o diretório de saída antes de gerar novos arquivos. Essa etapa evita que artefatos antigos permaneçam no pacote final. O comportamento se torna perigoso quando o caminho de saída é resolvido sem validações suficientes. Um caminho vazio, a raiz do projeto, o diretório pessoal ou uma localização fora do workspace pode fazer a operação recursiva atingir muito mais arquivos do que o esperado.

Links simbólicos acrescentam outra camada de risco. Um diretório aparentemente localizado dentro do projeto pode apontar para uma pasta externa. Se o programa resolve o link e apaga o destino sem verificar se ele permanece dentro do workspace permitido, a limpeza deixa de ser limitada ao build. Esse é um padrão conhecido de segurança: operações destrutivas devem validar o caminho canônico e impedir que ele atravesse limites definidos.

A vulnerabilidade está no fluxo de limpeza do @quasar/app-vite. O registro CVE não afirma que toda execução do Quasar apaga arquivos arbitrários automaticamente. A condição depende de uma configuração insegura ou inesperada. Por isso, a análise deve verificar arquivos de configuração, scripts de CI e valores de build fornecidos por variáveis de ambiente.

Quem foi afetado e para que serve

O público afetado inclui equipes que usam Quasar com Vite, especialmente em projetos em que build.distDir é customizado, recebido de configuração externa ou compartilhado entre vários jobs. Desenvolvedores locais, runners de integração contínua e agentes de publicação podem executar o processo com permissões diferentes e, portanto, apresentar impactos diferentes.

Em um notebook de desenvolvimento, uma configuração errada pode apagar arquivos do workspace ou do diretório do usuário. Em um runner, o dano pode atingir caches, artefatos de outros jobs ou arquivos temporários de um mesmo agente. Em um servidor de build com permissões amplas, o raio de impacto pode ser maior. O caso não transforma automaticamente um artefato de frontend em uma falha remota do site, mas pode comprometer a integridade do processo de entrega.

Como identificar e detectar

Revise o valor de build.distDir em todos os projetos Quasar. Procure configurações que usam variáveis de ambiente, concatenação de caminhos, caminhos absolutos, diretório do usuário, raiz do repositório ou links simbólicos. Verifique também scripts que apagam a pasta de saída antes de chamar o Quasar, pois duas rotinas destrutivas podem esconder a causa do problema.

Nos runners, compare a lista de arquivos antes e depois de uma execução. Sinais importantes incluem desaparecimento de arquivos fora de dist, mudança inesperada no conteúdo do cache, falha de jobs paralelos e alterações no diretório de trabalho. Centralize logs do comando de build e registre a versão efetiva do @quasar/app-vite usada pelo gerenciador de pacotes.

Uma checagem segura pode resolver o caminho de saída e confirmar que ele está dentro de um diretório temporário criado exclusivamente para o build. Faça essa validação sem executar a etapa de limpeza. Se houver um link simbólico, interrompa o pipeline até que a origem e o destino sejam entendidos.

Como se proteger e mitigar

Atualize o Quasar Framework e o pacote @quasar/app-vite para uma versão corrigida indicada pelo projeto e pelo advisory oficial. Antes da atualização, gere uma lista de dependências e teste o build em um workspace descartável. Depois, confira o lockfile, o conteúdo do pacote e a versão efetivamente instalada no CI. Não basta alterar somente uma dependência direta se o runner continuar usando cache antigo.

Defina o diretório de saída como uma subpasta dedicada dentro do workspace ou de um diretório temporário. Não use a raiz do projeto, o diretório pessoal, a raiz do sistema ou um caminho compartilhado entre projetos. Evite links simbólicos no caminho de saída e valide o caminho canônico antes de qualquer operação recursiva.

Use uma conta de build com o menor conjunto de permissões necessário. Em CI, isole jobs por workspace e descarte o runner após uma execução de risco. Faça backup dos arquivos necessários, mas não conceda privilégios administrativos ao processo apenas para contornar erros de permissão. A menor permissão possível reduz o alcance de uma configuração defeituosa.

Comparação com casos e alternativas anteriores

Esse problema é diferente de uma vulnerabilidade no código JavaScript entregue ao navegador. O código da aplicação pode estar correto e ainda assim o pipeline gerar um artefato incompleto ou apagar arquivos do ambiente durante a compilação. Também é diferente de um ataque de path traversal em um servidor HTTP, embora os dois casos compartilhem a necessidade de validar limites de caminho.

Uma alternativa operacional é criar um diretório temporário novo para cada build e publicar somente os arquivos gerados depois da validação. Outra é usar containers ou runners efêmeros com um workspace mínimo. Essas práticas não substituem a atualização do pacote, mas reduzem o efeito de uma configuração destrutiva.

Análise técnica

O identificador é CVE-2026-106109. O registro descreve o produto como Quasar Framework e o componente envolvido como @quasar/app-vite. A condição informada ocorre quando a ferramenta remove recursivamente o build.distDir resolvido sem rejeitar destinos perigosos, incluindo o projeto, o diretório do usuário, raízes do sistema e destinos externos resolvidos por links simbólicos. O intervalo citado é de 1.0.0 até antes de 3.3.0.

O dado mais importante para a triagem é o caminho efetivamente resolvido, não apenas o texto presente no arquivo de configuração. Em sistemas Unix, compare o resultado de realpath com o workspace permitido. Em ambientes Windows, considere junções, links simbólicos e letras de unidade diferentes. A validação precisa acontecer antes de remover qualquer arquivo.

O registro oficial da vulnerabilidade é a fonte para identificação e atualização: CVE-2026-106109. Este artigo não atribui pontuação CVSS nem declara exploração ativa porque esses dados não foram confirmados no material usado para a publicação.

Impacto e consequências

O impacto primário é a perda de arquivos ou a adulteração do ambiente de build. Isso pode interromper uma publicação, remover artefatos que seriam usados por outro job ou produzir um pacote aparentemente válido, porém incompleto. Um pipeline que não verifica a lista final de arquivos pode promover o problema para ambientes posteriores.

Em um projeto com código versionado, parte da recuperação pode ser feita a partir do Git. Ainda assim, arquivos não versionados, segredos carregados no workspace, caches e artefatos de outros processos podem não ser recuperáveis. O risco de exposição de segredos depende das permissões e dos diretórios alcançados; a CVE, isoladamente, não prova que dados foram lidos ou enviados para fora do ambiente.

Dicas práticas e boas práticas

Adote um contrato simples para todo build: entrada em um workspace conhecido, saída em um diretório novo e exclusivo, caminho canônico dentro do limite permitido e validação do resultado antes da publicação. Registre a versão do Node.js, do Quasar, do Vite e do gerenciador de pacotes. Faça o mesmo no computador do desenvolvedor e no runner para evitar diagnósticos divergentes.

Inclua verificações que falhem se a saída estiver vazia, se o caminho sair do workspace, se for igual ao projeto ou se resolver para um link externo. Mantenha uma lista esperada de arquivos e faça uma auditoria de diferenças após o build. Não use comandos recursivos com variáveis sem validar o destino primeiro.

Checklist: localizar a versão do @quasar/app-vite; revisar build.distDir; resolver links; limitar permissões; atualizar dependências; recriar o cache; executar em workspace descartável; validar a lista de arquivos; revisar logs; registrar o resultado.

Conclusão: o que fazer agora

Trate a CVE-2026-106109 como um risco de integridade e disponibilidade do pipeline de frontend. A primeira ação é descobrir se o projeto usa uma versão afetada e se o diretório de saída é customizado. Em seguida, atualize o pacote, elimine caminhos perigosos e execute o build em um workspace isolado.

Segurança de supply chain não termina no lockfile. Permissões, links simbólicos, caches e comandos de limpeza também fazem parte da superfície de risco. Ao combinar atualização, validação canônica do caminho e runners efêmeros, a equipe reduz a chance de um erro de configuração apagar arquivos fora do artefato esperado.