Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- As ferramentas de compilação representam um risco para a produção, mesmo quando nunca são distribuídas como código de tempo de execução do aplicativo.
- O webpack não publica ramos LTS, e as correções são incorporadas à linha 5.x ativa, em vez de às versões secundárias mais antigas.
- O código de compilação é executado com quaisquer fontes, credenciais e tokens aos quais o processo de compilação tenha acesso.
- Recompilar com o mesmo webpack vulnerável não muda nada, pois a falha é reemitida a cada vez.
A maioria dos programas de vulnerabilidade isenta discretamente a cadeia de compilação. Ela fica em `devDependencies`, nunca é executada em um servidor de produção e, quando aparece em um relatório de varredura, recebe apenas um encolher de ombros e fica no fim da fila. Essa lógica parece razoável quando uma dependência nunca chega à produção. No caso do webpack, porém, ela não se sustenta de duas maneiras específicas.
Este post aborda o que realmente é o modelo de suporte do Webpack, por que uma versão secundária 5.x fixada é, na prática, um código sem suporte e como tratar a cadeia de compilação como uma superfície de ataque sem atrasar cada lançamento.
A compilação ainda está funcionando, então ninguém mexe nela
A configuração do webpack em um repositório legado é tratada como intocável porque continua funcionando, e ninguém quer ser aquele que vai estragar tudo. Sistemas de compilação estáveis têm a tendência de se tornarem o software mais antigo da empresa — nada obriga ninguém a voltar atrás e dar uma olhada neles.
Então, acontece uma reunião de triagem. Um scanner sinaliza um CVE no Webpack, alguém dá uma olhada, diz “isso afeta apenas o tempo de compilação” e o ticket vai para o fim da fila, atrás de tudo o que parece representar um risco real para a produção. O raciocínio parece correto. Mas está duplamente errado.
O primeiro erro é tratar a saída do webpack como algo separado do próprio empacotador. O webpack injeta seu próprio código de tempo de execução no pacote; portanto, uma falha nesse código de tempo de execução se torna uma falha no aplicativo que você distribui.
A segunda é partir do pressuposto de que uma ferramenta de compilação só está acessível no momento da compilação. O servidor de desenvolvimento apresenta um tipo específico de vulnerabilidades que visam diretamente os engenheiros que o operam. E o problema mais profundo é tratar as `devDependencies` como uma classificação de risco. Trata-se de um rótulo de empacotamento, não de um limite de segurança. Um empacotador apenas torna isso excepcionalmente óbvio, pois parte do que ele gera acaba indo para a produção.
O webpack 4 já foi lançado e o webpack 5 não tem versão LTS
O webpack não divulga um calendário de LTS, uma matriz de suporte nem um cronograma de descontinuação. As correções são incorporadas à linha 5.x, que está em desenvolvimento ativo, e não aos ramos mais antigos que ainda recebem manutenção; portanto, uma versão secundária à qual você permaneça fixado pode ficar desatualizada no momento em que alguma correção for implementada no código-fonte original.
O webpack 4 foi lançado em fevereiro de 2018, o webpack 5 chegou em outubro de 2020 e a linha 4.x chegou ao fim com a versão 4.47.0, em setembro de 2023. A migração da versão 4 para a 5 levou anos para o ecossistema, e muitas equipes nunca a concluíram. Se você ainda está na versão 4, está executando um código que não recebe absolutamente nenhuma correção do desenvolvedor original.
O webpack 5 está mais estável, mas apenas na versão mais recente. A versão atual é a 5.110.3, lançada em setembro de 2026, e as duas correções abaixo ilustram o problema prático, pois cada uma delas foi incluída em uma versão mais recente da série 5.x, em vez de ser implementada retroativamente nas versões menores anteriores afetadas. O projeto’s Plano de ação para 2026 apresentou o tratamento nativo de CSS, um destino de compilação universal, TypeScript sem carregadores e as bases para o webpack 6, e o ciclo de lançamentos tem avançado rapidamente em todos esses aspectos. O suporte experimental ao TypeScript chegou na versão 5.107, e a versão 5.110 marcou como obsoleto css-loader, style-loader, e mini-css-extract-plugin em favor do suporte a CSS integrado ao webpack. A versão corrigida do projeto original, em outras palavras, é também aquela que está em constante mudança.
Você sabia? O fato de estar “no Webpack 5” não diz quase nada sobre o status das atualizações do seu projeto. Um repositório bloqueado na versão 5.76.1 está mais de trinta versões secundárias atrás da linha atual de atualizações, mesmo que o Webpack 5 ainda seja a versão principal atual do projeto.
É nessa lacuna entre a “versão principal suportada” e a “versão corrigida” que as auditorias se tornam complicadas. Imagine um front-end bancário fixado em uma versão secundária 5.x porque o pipeline está certificado e qualquer mudança na cadeia de ferramentas obriga todo o sistema a passar por um novo processo de recertificação. Mudar o gerenciador de pacotes significa repetir esse processo, então a fixação permanece, e o código sem suporte permanece com ela. Essa é exatamente a situação para a qual o suporte estendido foi criado, permitindo que uma equipe mantenha os patches em um ramo do qual não pode sair facilmente.
Alguns erros do empacotador acabam aparecendo no navegador
Algumas vulnerabilidades do Webpack nem sequer estão presentes na etapa de compilação. Elas estão no código que o Webpack insere no seu pacote, e é por isso que o empacotador deve ser considerado parte da sua superfície de ataque em produção, e não apenas da sua lista de verificação na fase de compilação.
CVE-2024-43788 este é o exemplo simples. Trata-se de um gadget que altera o DOM no webpack’s AutoPublicPathRuntimeModule, e isso se aplica quando output.publicPath não está definido ou está definido como auto. O comunicado do desenvolvedor indica que as versões anteriores à 5.93.0 estão afetadas, enquanto a 5.94.0 e versões posteriores já foram corrigidas; o NVD classifica o risco como “Médio”, com pontuação de 6,4. Vale a pena saber que auto é o padrão efetivo para os alvos “web” e “web-worker” quando ninguém define publicPath, portanto, essa não é uma configuração incomum.
A classificação “Média” subestima a gravidade da situação operacional. O alerta relata explorações reais no Canvas LMS, e o código vulnerável é gerado no pacote, em vez de ficar restrito a um executador de CI. No entanto, a exploração não é automática. É necessária uma página que inclua arquivos gerados pelo webpack e permita que um invasor injete HTML sem scripts com sanitização insuficiente name ou id atributos. Quando essas condições se alinham, o gadget pode influenciar de onde seus scripts são carregados, e isso representa uma vulnerabilidade de cross-site scripting executada nos navegadores dos seus usuários, originada pela sua ferramenta de compilação.
CVE-2023-28154 esse é o contraste relevante, pois nunca sai da compilação. Trata-se de um problema de acesso a objetos entre reinos em ImportParserPlugin manipulação indevida de comentários, afetando o Webpack 5 em versões anteriores à 5.76.0. Durante a compilação, um invasor capaz de influenciar o objeto não confiável em questão poderia fazer com que o Webpack acessasse o objeto global do domínio do host. O NVD classifica essa vulnerabilidade como Crítica, com pontuação de 9,8, enquanto a Red Hat atribui à mesma falha uma pontuação de 9,1.
Recompilar com o mesmo webpack vulnerável não ajuda em nenhum dos dois casos, por motivos diferentes. O código de tempo de execução por trás da vulnerabilidade CVE-2024-43788 é reemitido em todos os pacotes até que o próprio webpack seja corrigido, e a vulnerabilidade CVE-2023-28154 está presente na análise de comentários do próprio webpack, de modo que persiste enquanto essa versão estiver realizando a compilação. Ambas as correções já estão disponíveis no código-fonte há anos.
Cuidado: Antes que alguém discuta sobre os níveis de gravidade, verifique a versão e a configuração. O comunicado indica que as versões do webpack anteriores à 5.93.0 estão afetadas, enquanto a 5.94.0 e versões posteriores já foram corrigidas; portanto, qualquer versão anterior à 5.94.0 precisa ser verificada, e output.publicPath não definido ou ativado auto é o que coloca o runtime afetado no seu pacote. Em seguida, verifique se o seu aplicativo permite que os usuários insiram HTML sem sanitização name ou id atributos, pois essas condições são fundamentais para a explorabilidade.
A dependência do desenvolvimento não significa baixo risco
Mesmo as vulnerabilidades que permanecem na fase de compilação não representam um risco baixo, devido ao que o código dessa fase pode acessar. Um empacotador é executado com tudo o que o processo de compilação tem disponível, o que geralmente significa seu código-fonte, suas variáveis de ambiente, suas credenciais e, em muitos pipelines, seus tokens de publicação. Esse é um alvo bastante vulnerável.
CVE-2025-30359 e os relacionados CVE-2025-30360 Ambas resultam no roubo de código-fonte do webpack-dev-server e ambas foram corrigidas na versão 5.2.1, mas chegam a esse resultado de maneiras diferentes. A primeira se aproveita do fato de que uma solicitação clássica de script proveniente de um <script> A tag não está sujeita à política de mesma origem; portanto, uma página maliciosa pode extrair um pacote de um servidor de desenvolvimento em execução e, com um pouco de contaminação de protótipos, ler o código-fonte de volta a partir de __webpack_modules__ usando Function::toString. A segunda é o sequestro de WebSocket entre sites, em que a verificação de origem permitia o acesso a endereços IP de origem, expondo desenvolvedores que utilizam navegadores que não são baseados no Chromium; essa vulnerabilidade afeta versões até a 5.2.0.
O que importa mais agora é que a versão 5.2.1 não foi o fim da história. Essa correção se baseou no Sec-Fetch-Mode e Sec-Fetch-Site cabeçalhos, que os navegadores só enviam para origens potencialmente confiáveis; portanto, em HTTP simples, esses cabeçalhos estão ausentes e a verificação é totalmente ignorada. A vulnerabilidade, CVE-2026-6402, afeta o webpack-dev-server até a versão 5.2.3, e a versão 5.2.4 corrige o problema definindo Cross-Origin-Resource-Policy: same-origin. Servir o servidor de desenvolvimento por HTTPS é uma solução alternativa documentada, e não um substituto para a atualização. A versão 5.2.5 corrigiu a vulnerabilidade CVE-2026-9595, na qual um proxy de usuário de escopo amplo com ws: true capturaria o próprio WebSocket HMR do servidor de desenvolvimento e o encaminharia para o destino do proxy, incluindo os cookies e o cabeçalho Origin. Depois disso, a versão 5.2.6 corrigiu uma vulnerabilidade de falsificação de solicitação entre sites (CSRF) por meio do editor aberto interno e dos endpoints de invalidação, além de uma negação de serviço desencadeada por um cabeçalho `Host` ou `Origin` malformado; desde então, o próprio pacote já avançou para a versão 6.0.0. Essa série de correções é um argumento convincente para não descartar as descobertas no servidor de desenvolvimento como mero ruído de fundo.
Pense em quem fica vulnerável a isso. O ataque divulgado para o CVE-2025-30359 envolve uma página maliciosa que solicita um pacote de um servidor de desenvolvimento no localhost; portanto, basta que um desenvolvedor esteja navegando na internet com um servidor de desenvolvimento em execução. O invasor precisa da porta e do caminho do ponto de entrada de saída, e ambos costumam permanecer nos valores padrão. Isso abrange prestadores de serviços em máquinas que você não controla e qualquer pessoa que deixe um servidor de desenvolvimento ligado o dia inteiro enquanto navega, e nada disso aparece em uma varredura voltada para a produção.
Das trincheiras: Alguém define host para 0.0.0.0 para testar em um celular e depois se esquece de voltar à configuração original. Essa única alteração transforma uma ferramenta que funciona apenas no localhost em uma que escuta a rede, o que é relevante para os bugs que exigem acesso à rede, como a negação de serviço por cabeçalho malformado. No entanto, não é isso que causa o roubo de código entre origens. Esse funciona perfeitamente contra o localhost.
Portanto, a questão da triagem nunca foi “localhost” versus “todo o resto”. Trata-se da versão exata que você está usando, se os desenvolvedores mantêm um servidor de desenvolvimento em execução enquanto navegam, se ele está servindo conteúdo por HTTP simples e quão fáceis de adivinhar são a porta e o caminho de saída.
Uma equipe que utilize a versão 5.2.3 com configurações padrão apresenta uma vulnerabilidade real, independentemente do que o endereço de ligação indique. O HTTPS atenua a exposição da origem na vulnerabilidade CVE-2026-6402, mas não retira de circulação os alertas que surgiram posteriormente; portanto, a versão 5.2.4 não constitui uma garantia geral de segurança. As correções da série 5.x se estendem até a versão 5.2.6, e cada aviso aplicável deve ser analisado individualmente, em vez de se aplicar uma regra geral.
A migração oculta é maior do que o Webpack
A razão pela qual esses problemas persistem não é preguiça. Migrar uma configuração madura do Webpack é um projeto de verdade, e as equipes mantêm o status quo por motivos válidos, a começar por carregadores e plug-ins personalizados, sistemas de compilação específicos de frameworks sobrepostos, configurações acumuladas ao longo de anos de correções, cache sensível à saída, versões do Node sem suporte que ainda estão em uso na integração contínua (CI) e o simples medo de alterar um pipeline que ninguém entende completamente.
Uma grande alteração também não deixa as coisas como estão. Ela pode afetar a divisão em blocos, a resolução de módulos, o comportamento dos polyfills, o gerenciamento de recursos e a estrutura do resultado final. Isso significa dois planos de teste em vez de um, pois tanto o processo de compilação quanto o aplicativo resultante precisam ser validados.
O passo mais útil é deixar de tratar o “webpack” como um único item e dividi-lo de acordo com o local onde cada parte é efetivamente executada. Esse é o tipo de contexto de explorabilidade que um documento do Vulnerability Exploitability eXchange (VEX) se destina a apresentar, registrando que um carregador em um executador de CI e o código de tempo de execução dentro de um pacote distribuído não representam o mesmo risco.
| Componente | Onde é executado | Atinge a capacidade de produção | Prioridade de triagem |
|---|---|---|---|
| código de tempo de execução gerado pelo webpack | Tempo de compilação e, em seguida, no navegador | Sim, quando o módulo de tempo de execução afetado estiver no pacote | Alto |
| webpack-dev-server | Máquinas dos desenvolvedores, além da rede local quando exposta | Não | Depende da versão e da configuração; o nível mais alto é observado nas versões que incluem os alertas aplicáveis |
| Carregadores e plug-ins | Tempo de compilação, na CI ou no ambiente de desenvolvimento | Às vezes, depende do carregador | Caso a caso |
| Utilitários de compilação transitivos | Tempo de compilação | Raramente | Baixo, a menos que seja acessível |
Um quadro de decisão para uma compilação de código legado
Avançar na versão 5.x
Se a configuração estiver documentada e as dependências relacionadas estiverem em dia, atualize para a versão 5.x atual. É a opção mais econômica e restaura seu fluxo de patches. Faça isso neste sprint, em vez de deixar para o próximo trimestre.
Reconstruir o pipeline
Se a complexidade histórica já ultrapassou seu valor, o Rspack, o Vite e o esbuild merecem, todos, uma análise cuidadosa. Mas seja honesto quanto ao custo. Eles são mais rápidos, mas reescrever uma configuração madura com carregadores personalizados, Module Federation ou divisão cuidadosa de código é um projeto de verdade que acaba sem nada visível para o usuário.
Aplique o patch na versão fixada e mantenha a migração mínima
Se o pipeline for certificado, a remoção do empacotador não ocorrerá este ano. É aqui que o suporte estendido mostra seu valor, mantendo o branch fixado em um estado atualizado com patches enquanto você planeja a mudança mais ampla de acordo com seu próprio cronograma, em vez de uma mudança de emergência. O Suporte de Ciclo de Vida Ilimitado da TuxCare abrange o webpack 5.50.0, 5.55.0, 5.76.1, 5.88.2 e 5.94.0, além das versões do webpack-dev-server de 2.7.1 a 5.2.2, disponibilizadas via npm.
No entanto, é preciso ter clareza sobre o que um backport preserva. Ele mantém intactas a versão do Webpack, a configuração e a superfície da API, o que pode reduzir significativamente o escopo da recertificação em comparação com uma migração completa da cadeia de ferramentas. O que ele não consegue fazer é manter o pacote emitido byte a byte idêntico, pois corrigir o código de tempo de execução gerado implica alterá-lo.
Como a TuxCare aborda o suporte estendido ao webpack
O suporte prolongado a uma ferramenta de compilação significa mais do que simplesmente manter uma versão antiga funcionando. O verdadeiro trabalho está nos detalhes, e a maior parte dele é do tipo que uma equipe interna não consegue repetir mês após mês.
O processo começa com o monitoramento do webpack e de suas dependências transitivas abrangidas, para, em seguida, avaliar se uma vulnerabilidade divulgada realmente afeta o ramo legado, em vez de se basear apenas no intervalo de versões publicado. Essa visão contextualizada, que leva em conta o status de fim de vida útil (EOL) e o risco das dependências transitivas, é o que permite que uma equipe priorize as vulnerabilidades reais, em vez de se dedicar a cada linha de um relatório de varredura.
A partir daí, as correções são retroportadas sem trazer as mudanças arquitetônicas presentes nas versões posteriores. Cada versão corrigida é validada quanto à compatibilidade e regressões, para que os pipelines de compilação estabelecidos continuem funcionando — o que geralmente é o verdadeiro obstáculo à aplicação de correções em uma pilha certificada. A TuxCare não está tentando substituir o webpack upstream. O trabalho consiste na gestão de longo prazo das versões que o projeto já deixou para trás, com os testes de regressão e o trabalho de compatibilidade de que os sistemas de produção realmente precisam. Cada versão corrigida é fornecida com uma Lista de Materiais de Software (SBOM) e um documento VEX, e os artefatos contêm assinaturas GPG independentes do próprio registro da TuxCare.
O OpenJS e a longa vida útil das ferramentas essenciais
O webpack é um projeto do OpenJS Impact, e o Programa de Sustentabilidade do Ecossistema OpenJS ( ESP) existe para que versões arquivadas, em fim de vida útil (EOL) e mais antigas possam contar com cobertura de segurança comercial, com uma parte da receita revertida para os projetos e para a Fundação. A TuxCare é membro Gold e parceira do ESP, e o programa é não exclusivo, de modo que os mantenedores têm liberdade para oferecer suporte a qualquer versão que desejarem.
Seu pipeline de compilação faz parte do produto, mesmo que os clientes nunca o vejam. Um pipeline de compilação legado merece o mesmo plano de ciclo de vida que o aplicativo que ele produz, e não uma isenção permanente daquele que você já aplica em todos os outros lugares.
