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
- O “Werkzeug” sem suporte significa que as correções do desenvolvedor original são interrompidas, deixando os aplicativos afetados sem um patch do desenvolvedor original quando surgem novas vulnerabilidades.
- Atualizações realizadas às pressas podem causar bugs na produção, problemas de dependência, dívida técnica e custos não planejados.
- O TuxCare ELS mantém as versões mais antigas do Werkzeug atualizadas com os patches enquanto você planeja o momento certo para fazer a atualização.
Você construiu algo sólido com o Werkzeug. O roteamento funciona. O tratamento de solicitações é bem organizado. A camada WSGI faz exatamente o que deve fazer. Então, seu verificador de dependências aponta um problema, ou alguém da equipe de segurança pergunta qual versão do Werkzeug está em execução no contêiner, e a resposta acaba sendo 2.2.3, uma versão que remonta a 2023.
E agora?
Essa é uma situação mais comum do que parece, principalmente porque quase ninguém escolhe a versão do Werkzeug de propósito. O Flask a carrega, o pip a resolve, e ela fica lá discretamente até que algo force a questão. Então, vamos ver o que realmente acontece quando um branch do Werkzeug para de receber atualizações e o que você pode, de fato, fazer a respeito.
Como funcionam, na verdade, os lançamentos do Werkzeug
O Werkzeug é mantido pelo projeto Pallets, juntamente com o Flask, o Jinja e o Click. O Pallets não publica um calendário de suporte de longo prazo com janelas fixas de manutenção para cada ramificação, como fazem o Python ou o Node.js. Não há nenhuma data anunciada para o fim da vida útil do Werkzeug 2.2 em nenhum roteiro. O suporte deve ser inferido a partir do que os mantenedores realmente lançam.
É bastante fácil acompanhar o panorama geral. O Werkzeug 2.x abandonou o Python 2 e o 3.5 e migrou a base de código para anotações de tipo. O Werkzeug 3.x continuou essa trajetória, removendo APIs obsoletas e elevando a versão mínima exigida do Python, e agora requer o Python 3.9 ou mais recente. A linha ativa atualmente é a 3.1.x, sendo que a 3.1.8, lançada em 2 de abril de 2026, é a versão estável mais recente em agosto de 2026.
É aqui que as pessoas costumam se confundir. O modelo intuitivo, segundo o qual uma nova versão principal substitui imediatamente o ramo anterior, não é confiável. O Werkzeug 3.0.0 foi lançado no final de setembro de 2023, e a versão 2.3.8 ainda foi lançada em 8 de novembro de 2023, trazendo uma correção de segurança. Backports acontecem. Eles são apenas imprevisíveis e não são garantidos.
O que o histórico de lançamentos realmente mostra é para onde se concentra a atenção. A linha 3.0 teve seu último lançamento, a versão 3.0.6, no final de outubro de 2024, dias antes do lançamento da versão 3.1.0, e nada mais desde então. A linha 2.x terminou na versão 2.3.8. Portanto, na prática, a 3.1.x é o único ramo que ainda recebe lançamentos, enquanto os ramos anteriores parecem inativos, sem nunca terem sido formalmente declarados obsoletos. Isso é, sem dúvida, pior do que uma data de fim de vida útil (EOL) publicada, pois não é possível indicar um calendário a um auditor nem planejar com base em uma janela de manutenção que nunca foi oferecida.
Se você não tem certeza de qual é a sua situação, pip show werkzeug responde em cerca de dois segundos. Se a versão não começar com 3.1, não conte com que o desenvolvedor original lance uma correção para o que quer que venha a ser divulgado em seguida.
O que realmente significa um Werkzeug sem suporte em ambiente de produção
O suporte chega ao fim. O aplicativo continua funcionando. Nada parece dar errado. Então, por que isso importa?
Porque a interrupção do fornecimento de patches não faz com que as vulnerabilidades desapareçam. O risco não é que os invasores mantenham uma lista dos que estão atrasados na atualização do Werkzeug. É mais simples e mais enfadonho do que isso. Uma falha é divulgada, ela afeta sua ramificação e não há um caminho de correção no upstream. O Werkzeug está na base do Flask, de modo que essa lacuna é herdada por qualquer coisa que você tenha construído sobre ele.
Duas revelações ilustram bem o problema.
CVE-2024-34069 é uma vulnerabilidade no depurador interativo do Werkzeug, classificada como 7,5 (Alta) tanto pelo NVD quanto pelo comunicado da Pallets. A exploração é restrita. O invasor precisa fazer com que um desenvolvedor interaja com um domínio e um subdomínio sob seu controle, fazer com que ele digite o PIN do depurador e adivinhe uma URL no aplicativo que acione o depurador. Se todas as três condições forem atendidas, o resultado é a execução de código na máquina do desenvolvedor, mesmo com o depurador vinculado ao localhost. A falha foi corrigida na versão 3.0.3.
Essa correção é o ponto principal. O Werkzeug 3.0.3 é a primeira versão que a contém, e todas as versões posteriores da série 3.x a mantêm. O que não existe é uma versão da série 2.x com o patch, incluindo a 2.3.8, a versão final da série 2.x. Se sua pilha de versões estiver na linha 2.x, não há nenhuma versão nesse ramo para a qual você possa migrar a fim de resolver esse problema.
Saiba mais sobre Werkzeug Security e as vulnerabilidades atuais.
CVE-2023-46136 é uma vulnerabilidade de negação de serviço no analisador de formulários multiparte. Se um upload começar com um CR ou LF e for seguido por megabytes sem esses caracteres, o analisador acrescenta os bytes, bloco por bloco, a um bytearray interno e verifica novamente o buffer crescente em busca do limite, consumindo recursos da CPU e impedindo que o worker atenda a qualquer outra solicitação. A vulnerabilidade afeta as versões 2.3.7 e anteriores, bem como a 3.0.0, e foi corrigida nas versões 2.3.8 e 3.0.1. É importante saber antes de discutir o assunto em um ticket: o NVD classifica a vulnerabilidade como 7,5 (Alta), enquanto o aviso da Pallets a classifica como 5,7 (Moderada), pois os dois discordam quanto ao vetor de ataque e aos privilégios necessários. Diferentes scanners podem relatar graus de gravidade diferentes, dependendo da fonte de dados que utilizam. A vulnerabilidade se aplica a aplicativos com um endpoint que realmente analisa dados multipart fornecidos pelo invasor.
Em um branch mantido, ambas as situações representam um aumento de versão. Em um branch sem suporte, uma vulnerabilidade recém-divulgada permanece sem correção no upstream até que você faça a atualização ou obtenha um backport em outro lugar.
Riscos de segurança e conformidade após o término do suporte
A PCI DSS v4.0.1, versão atual da norma, exige, no Requisito 6.3.3, que as correções para vulnerabilidades críticas sejam instaladas no prazo de um mês após o lançamento, enquanto outras correções aplicáveis devem ser tratadas de acordo com o cronograma baseado em risco documentado pela organização. A versão 4.0 havia estendido esse prazo de um mês também para itens de alta gravidade, e a 4.0.1 voltou à redação mais restrita. A orientação dessa revisão importa menos do que a suposição subjacente a ela, que é a de que existe um patch disponível para instalação.
Quando não há uma correção na versão anterior para o seu branch, você não está atrasado na correção. Você está fora do modelo em que o requisito foi definido, e essa é uma conversa mais difícil de se ter com um avaliador.
A norma SOC 2 não contém nenhuma regra contra o uso de software em fim de vida útil; portanto, tenha cuidado ao abordar esse assunto internamente. O que isso faz é suscitar dúvidas sobre o gerenciamento de vulnerabilidades e sobre se você é capaz de demonstrar um plano de correção viável. Uma dependência sem suporte, com falhas identificadas e sem patch disponível, é o tipo de situação que gera solicitações de acompanhamento, atrasa o preenchimento de questionários de segurança e complica as análises de risco dos clientes na hora da renovação.
Suas opções quando o suporte terminar
Existem três, e a escolha correta depende menos do CVE que sinalizou o problema do que da área de exposição do Werkzeug que seu aplicativo realmente possui.
Atualize para a versão mais recente do Werkzeug
Essa é a resposta padrão e, para muitas equipes, a correta. O Werkzeug 3.1.x está maduro, a API está mais limpa e as anotações de tipo são realmente úteis.
O que torna a questão interessante é a suposição de que se trata de uma alteração de apenas uma linha. O Werkzeug não se atualiza sozinho. As versões do Flask geralmente declaram uma versão mínima do Werkzeug, em vez de definir um limite máximo, o que deixa o pip livre para instalar uma versão mais recente do Werkzeug do que aquela com a qual sua versão do Flask já foi testada. Isso não é hipotético. O Werkzeug 3.0 removeu url_quote, que o Flask 2.2.2 importa no início do arquivo app.py, de modo que o emparelhamento falha na importação. O Werkzeug 3.1, então, removeu werkzeug.__version__, que o cliente de teste do Flask 2.2.4 ainda lê ao construir uma string de agente do usuário, gerando um AttributeError na primeira vez que alguém executa o conjunto de testes em um contêiner novo. Esse problema está descrito em Problema 5652 do Flask.
Portanto, atualizar o Werkzeug pode muito bem significar atualizar o Flask, o que implica auditar todas as extensões vinculadas ao Flask, o que, por sua vez, implica uma verificação de compatibilidade em toda a árvore de dependências. Se sua base de código for pequena, sua lista de extensões for curta e sua cobertura de testes for adequada, faça isso agora e pare de ler. Se for um aplicativo maduro, com uma década de middleware acumulado, reserve um orçamento adequado.
Migrar para uma estrutura diferente
Algumas equipes analisam uma dependência sem suporte e concluem que a resposta certa está em outro lugar completamente diferente. Django, se você quer tudo pronto para uso; FastAPI, se você quer um framework de API assíncrona baseado no Starlette; o próprio Starlette, se você quer o kit de ferramentas ASGI sem imposições; Bottle ou Falcon, se você quer algo mais leve. O FastAPI, em particular, está em franca ascensão, possui um design que prioriza a assincronia e gera documentação OpenAPI gratuitamente.
Nenhuma delas é um substituto direto para o Werkzeug. A lógica de rotas, a análise de solicitações, a renderização de modelos, a pilha de middleware, o tratamento de erros e a configuração de implantação — tudo isso precisa ser reformulado. Para um aplicativo com uma área de uso significativa do Werkzeug, uma migração devidamente planejada e testada se torna um projeto que abrange vários sprints ou vários trimestres, e não uma simples tarefa de limpeza. Faça isso porque você já queria adotar a programação assíncrona, e não porque um scanner sinalizou o problema numa terça-feira.
Use o Suporte Estendido e ganhe mais tempo
A terceira opção é manter a versão que você está usando e continuar recebendo correções de segurança para ela. Isso tira o controle do cronograma das mãos de quem quer que seja que divulgue a próxima vulnerabilidade e o coloca de volta no seu plano de ação. Mais adiante, há uma explicação detalhada de como isso funciona.
O verdadeiro custo de apressar uma atualização
Imagine uma equipe de SaaS com trinta pessoas que recebeu a orientação de corrigir uma falha de alta gravidade antes que o prazo do SOC 2 se esgote, daqui a três semanas. A correção em si não é a parte difícil. O problema são as consequências.
Erros que escaparam à suíte de testes começam a surgir na produção, e a equipe de suporte passa a receber uma série de tickets sobre comportamentos que antes funcionavam normalmente. As dependências transitivas trazem seus próprios casos extremos — daqueles que só aparecem sob carga real —, o que gera falhas intermitentes que são difíceis de reproduzir e ainda mais complicadas de explicar durante uma análise de incidentes.
Então começam os atalhos. As refatorações são ignoradas, as soluções provisórias se acumulam e todos concordam em corrigir tudo direito mais tarde. Seis meses depois, esse “mais tarde” ainda não chegou e a base de código está em pior estado do que antes da atualização que deveria tê-la organizado.
Os custos seguem o mesmo padrão. Horas de trabalho de prestadores de serviços que ninguém havia previsto no orçamento, compromissos do roteiro de desenvolvimento que se atrasam em um trimestre e engenheiros sênior passando a semana analisando os resultados do pip resolver em vez de desenvolver o que os clientes solicitaram. Nada disso aparece na estimativa original, porque a estimativa original se referia apenas à atualização de versão.
Como funciona o TuxCare ELS para o Werkzeug
A TuxCare vem há 15 anos fornecendo patches para softwares de código aberto que chegaram ao fim de vida útil, com mais de 420.000 patches disponibilizados e mais de 14.000 vulnerabilidades corrigidas em sistemas operacionais, ambientes de execução, bibliotecas e aplicativos. O Werkzeug está coberto pelo serviço ELS for Libraries da TuxCare.
As versões abrangidas atualmente incluem o Werkzeug 1.0.1, 2.2.3 e 2.3.8, estando outras versões disponíveis mediante solicitação.
O que torna essa abordagem diferente
A superfície de dependências do Werkzeug é excepcionalmente pequena. As versões 2.x declaram exatamente uma dependência de tempo de execução obrigatória, o MarkupSafe, e a versão 1.0.1 não declara nenhuma, o que simplifica a questão da cobertura. O ELS inclui correções de segurança para dependências diretas e transitivas sem custo adicional, o que é mais importante do que parece, pois o risco de fim de vida útil pode estar em uma camada abaixo do pacote que você está realmente monitorando.
O processo de aplicação de patches é automatizado, com equipes verificando o resultado. A TuxCare monitora CVEs 24 horas por dia no NVD, nos alertas dos fornecedores e nos alertas de segurança do GitHub; adapta as correções do upstream por meio de automação algorítmica e assistida por IA, com validação de especialistas; e, em seguida, submete cada compilação a testes de integridade, funcionalidade e regressão antes de assiná-la e publicá-la nos repositórios do ELS. Se você preferir conhecer os detalhes técnicos em vez do resumo, o artigo “Open Source Patching Process” aborda o assunto de forma adequada.
A integração permanece dentro do pip. Você pode apontar o pip para o repositório da TuxCare com index-url, ou você mantém o PyPI público e o adiciona como um extra-index-url, fixando diretamente a compilação corrigida. As versões corrigidas apresentam uma sequência de versão como werkzeug==1.0.1.post1+tuxcare, de modo que a versão corrigida permaneça identificável onde quer que suas versões resolvidas estejam registradas. Trata-se de uma alteração na configuração do repositório com credenciais, e não de uma recompilação do seu pipeline de implantação.
A entrega é garantida por um SLA, em vez de ser baseada no princípio do “melhor esforço”, e os pacotes são assinados e disponibilizados a partir de repositórios hospedados pela TuxCare, com suporte 24 horas por dia, 7 dias por semana, para triagem e solicitações de patches quando for necessária a intervenção humana. Para fins de auditoria, cada versão corrigida vem acompanhada de dados SBOM e de um feed VEX, de modo que as ferramentas compatíveis com o VEX possam distinguir as falhas já corrigidas daquelas que ainda requerem ação.
Quanto ao custo, a verdade é que o suporte prolongado não é barato. O que acontece é que ele transfere a engenharia de migração, os testes de compatibilidade e o trabalho de regressão de um período de emergência para um período planejado, onde o custo é o que deveria ser.
Como começar
Se você quiser saber como é, na prática, a cobertura para a sua versão, o rastreador de CVEs da TuxCare lista as vulnerabilidades do Werkzeug que já foram corrigidas, e a documentação do ELS aborda detalhadamente as versões compatíveis e as opções de instalação.
Para saber quais são as versões compatíveis, os preços e como a implementação funciona na prática, a página “Suporte de Ciclo de Vida Ilimitado para o Werkzeug” é o ponto de partida ideal.
Não deixe que um Werkzeug sem suporte coloque seus sistemas em risco
A posição do Werkzeug como camada WSGI no Flask significa que as decisões relacionadas ao seu ciclo de vida raramente são divulgadas. Quando uma versão sem suporte apresenta uma falha no código que sua aplicação realmente utiliza, sua aplicação também a apresenta, e você descobre isso por meio de um scanner ou de um questionário, em vez de por meio de uma nota de lançamento.
Nada disso justifica pânico. Você pode planejar uma atualização do Werkzeug para um trimestre em que tenha margem de manobra para fazê-la da maneira correta. Você pode migrar para uma estrutura diferente se houver um motivo técnico concreto que vá além do scanner. Ou pode continuar recebendo patches para a versão que já está em uso enquanto decide, o que ajuda a manter sua postura de segurança e fornece evidências concretas de correção para auditorias de conformidade, sem revelar seu plano de ação a quem quer que seja que registre o próximo CVE.
As equipes que conseguem superar bem essa fase raramente são aquelas com os maiores orçamentos. São aquelas que descobriram em qual versão realmente estavam, entenderam o que ainda era mantido e o que não era mais, e agiram de forma deliberada, em vez de reagir.
Se você estiver enfrentando alguma dessas situações no momento, o artigo “Suporte de ciclo de vida ilimitado para software de código aberto ” mostra como o suporte estendido abrange componentes em fim de vida útil em todo o restante da sua pilha de tecnologia, pelo tempo que você precisar deles.
