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 dependências aumentam sua superfície de vulnerabilidade: O risco decorrente do Velocity em fim de vida útil pode se estender além dos JARs do Engine e das Ferramentas, atingindo dependências de tempo de execução vulneráveis, como o commons-collections 3.2.1 e, quando utilizado, o Log4j 1.x.
- Migrações apressadas são caras e arriscadas: Apressar a migração do Engine 1.7 para a linha 2.x sob a pressão de prazos de conformidade troca o risco de segurança pelo risco de novas regressões.
- O fim do ciclo de vida (EOL) do Apache Velocity não precisa significar o fim da segurança: O TuxCare ELS oferece cobertura contínua de patches de segurança para versões do Velocity que chegaram ao fim da vida útil, enquanto você planeja uma migração controlada de acordo com seu próprio cronograma.
Se o Apache Velocity aparecer em algum ponto do gráfico de dependências da sua aplicação Java — o que ainda é comum em ambientes Java corporativos mais antigos —, vale a pena entender sua situação de fim de vida útil (EOL) antes que um verificador de segurança ou uma auditoria de conformidade force essa discussão.
O Velocity Engine 1.7, a versão final da linha 1.x, não recebe uma nova versão do projeto original desde novembro de 2010. Da mesma forma, o Velocity Tools 2.0 também não recebe novas versões desde maio de 2010, enquanto o desenvolvimento do Apache continua nas linhas Engine 2.x e Tools 3.x. O registro CVE para ambos os componentes mais antigos torna a vulnerabilidade concreta, e executá-los em produção sem a cobertura de patches acarreta implicações reais em termos de conformidade.
Este artigo explica o que significa, na prática, o fim da vida útil (EOL) do Apache Velocity, como é o histórico de segurança e como o TuxCare ELS para Apache Velocity oferece à sua organização um caminho para se manter segura sem forçar uma migração para a qual suas equipes ainda não estejam preparadas.
O que é o Apache Velocity e por que ele ainda é tão amplamente utilizado?
O Apache Velocity é um mecanismo de modelos baseado em Java que utiliza a Linguagem de Modelos Velocity (VTL), permitindo que os desenvolvedores incorporem diretivas dinâmicas em modelos de texto simples. Em tempo de execução, o mecanismo Velocity combina os modelos com modelos de dados Java para produzir a saída renderizada. Sua separação entre a apresentação e a lógica de aplicação contribuiu para que o Velocity se tornasse uma opção de modelagem amplamente adotada em aplicações Java corporativas ao longo da década de 2000 e até a década de 2010.
O projeto Apache Velocity inclui dois componentes principais, com linhas de versão e históricos de lançamento distintos:
- Mecanismo Velocity: O núcleo de execução de modelos, responsável pela análise de VTL, execução de diretivas, expansão de macros e resolução de variáveis de contexto.
- Ferramentas do Velocity: Integrações de frameworks web desenvolvidas com base no Engine, incluindo o VelocityViewServlet para aplicativos baseados em servlets, além de conjuntos de ferramentas para formatação de datas, geração de URLs e utilitários comuns para a camada de visualização.
O Velocity estava profundamente integrado ao Apache Struts, a configurações mais antigas do Spring MVC, ao Apache Turbine e às plataformas Java CMS, muitas vezes entrando nas aplicações como uma dependência transitiva em vários níveis de profundidade. Ele também se tornou uma escolha comum para sistemas de modelos de e-mail e geradores de relatórios que raramente são modernizados. Essa confiabilidade pode criar um ponto cego em relação ao fim da vida útil (EOL): o Velocity muitas vezes permanece integrado em aplicações de longa duração justamente porque continua funcionando, o que faz com que seja fácil ignorá-lo até que um verificador de vulnerabilidades o identifique.
Fim da vida útil do Apache Velocity: o ciclo de vida das versões
O Apache Velocity publica correções por meio de novas versões, enquanto as versões mais antigas são transferidas para os arquivos do Apache. Compreender a linha do tempo do componente é, portanto, essencial para avaliar os riscos em toda a sua pilha de tecnologia.
| Componente | Última versão | Status atual da versão |
| Velocity Engine 1.x | v1.7 – 29 de novembro de 2010 | Substituído; a versão mais recente da série 1.x está arquivada |
| Velocity Tools 2.x | v2.0 – 10 de maio de 2010 | Substituída; a versão mais recente da série 2.x está arquivada |
| Velocity Engine 2.x | v2.4.1 – 14 de outubro de 2024 | Linha de produção atual |
| Velocity Tools 3.x | v3.1 – fevereiro de 2021 | Linha de produção atual |
O Velocity Engine 1.7 foi a versão final da série 1.x e se tornou a versão padrão do Velocity incorporada a uma geração de frameworks Java. A linha Engine 2.x introduziu mudanças significativas na API em relação à versão 1.x, e muitos frameworks de origem não atualizaram sua dependência fixa do Velocity por anos, mantendo a versão 1.7 em uso generalizado até bem entrados os anos 2020. O Velocity Tools 2.0 também não teve nenhuma nova versão lançada desde 2010; ambos os componentes foram substituídos por versões principais mais recentes e não recebem mais lançamentos em suas respectivas linhas de versão.
O Apache direciona os usuários para suas versões atuais e arquiva as versões mais antigas, sem nenhum programa publicado de manutenção de segurança ou retroportagem de patches para as linhas Engine 1.x ou Tools 2.x. Isso deixa as organizações que utilizam essas versões sem uma fonte oficial documentada de novas correções de segurança — exatamente a lacuna que o TuxCare ELS para Apache Velocity foi criado para preencher.
O histórico de vulnerabilidades (CVE) que define o risco de fim de vida útil (EOL) do Apache Velocity
O fim do ciclo de vida (EOL) do Apache Velocity não significa que não sejam mais descobertas vulnerabilidades nas versões em fim de vida; significa que essas versões não recebem mais correções do desenvolvedor original. Os mecanismos de modelos podem ser alvos de alto valor, pois frequentemente processam modelos ou dados influenciados pelos usuários dentro do contexto de execução de um aplicativo. Em configurações vulneráveis, falhas na fronteira entre a lógica do modelo e o ambiente de execução do aplicativo podem levar a consequências tão graves quanto a execução remota de código — e o status de fim de vida útil remove a rede de segurança das correções do desenvolvedor original contra exatamente esse tipo de ataque.
| ID do CVE | NVD CVSS 3.1 | Componente afetado | Impacto |
| CVE-2020-13936 | 8,8 Alto | Motor 1.x e 2.0–2.2 | Contornamento da sandbox → execução remota de código |
| CVE-2015-7501 | 9,8 Crítico | commons-collections 3.2.1 | Cadeia de vulnerabilidades de deserialização em Java → RCE (em configurações vulneráveis) |
| CVE-2019-17571 | 9,8 Crítico | Log4j 1.x (backend opcional) | Execução remota de código no SocketServer (quando ativada) |
CVE-2020-13936: Contornamento da sandbox e execução remota de código
A vulnerabilidade CVE-2020-13936 (NVD CVSS 3.1: 8,8 – Alta) afeta as versões do Velocity Engine até a 2.2, inclusive, o que coloca toda a linha 1.x no escopo da vulnerabilidade. Um invasor capaz de modificar modelos do Velocity pode ser capaz de executar código Java arbitrário ou comandos do sistema com os privilégios da conta que executa o contêiner de servlets. Essa vulnerabilidade de injeção de modelo no lado do servidor foi relatada pelo GitHub Security Lab como GHSL-2020-048 e, posteriormente, abordada em alertas de vários fornecedores e distribuições.
A vulnerabilidade CVE-2020-13936 foi corrigida no Velocity Engine 2.3, lançado em fevereiro de 2021 — mais de uma década após o lançamento da versão final da linha 1.x, em novembro de 2010. Quando essa vulnerabilidade foi divulgada publicamente, em março de 2021, o Engine 1.7 já estava há mais de dez anos sem uma versão oficial, e nenhuma correção havia sido lançada para a linha 1.x.
Para organizações que utilizam o Engine 1.7, cujo ciclo de vida já chegou ao fim, as opções mais diretas de correção são a atualização para uma versão corrigida e com suporte ou a aplicação de um patch retroativo fornecido pelo fornecedor, por meio de um provedor como a TuxCare. Restringir quem pode enviar ou modificar modelos do Velocity pode reduzir a exposição, mas tais controles não substituem a aplicação de patches nos casos em que a funcionalidade vulnerável permanece acessível.
O risco oculto: a pegada de dependência do Velocity
O Velocity Engine 1.7 depende do commons-collections 3.2.1 e do commons-lang 2.4 para funcionalidades gerais de tempo de execução; o Jakarta ORO 2.0.8 é necessário apenas para determinados recursos, como o escapamento automático de referências. O Log4j 1.x é um backend de registro opcional, utilizado apenas quando as aplicações configuram o Velocity para registrar eventos por meio do Log4j. Dois componentes desse ecossistema apresentam CVEs com classificação CVSS 9,8 (Crítica):
commons-collections 3.2.1: CVE-2015-7501 (CVSS 9,8 – Crítico). Esta versão pode ser envolvida em cadeias de exploits de deserialização Java quando um aplicativo deserializa dados não confiáveis por meio de um caminho de código vulnerável – a mesma classe de exploit que afetou o WebSphere, o JBoss, o WebLogic e o Jenkins quando foi divulgada em 2015. O Velocity Engine 1.7 utiliza a versão afetada, embora a possibilidade real de exploração dependa de como o aplicativo em questão lida com objetos serializados.
Log4j 1.x: CVE-2019-17571 (CVSS 9,8 – Crítico). O Log4j 1.x chegou ao fim de vida útil em agosto de 2015, e todo o ramo 1.x não recebe mais correções para CVEs divulgados posteriormente. Aplicativos que utilizam o Log4j 1.x com o Velocity podem estar expostos à vulnerabilidade CVE-2019-17571, uma vulnerabilidade de execução remota de código, caso habilitem e exponham o componente SocketServer vulnerável.
Os scanners de vulnerabilidades geram resultados em toda essa árvore de dependências que não possuem correção oficial do desenvolvedor original. O TuxCare ELS para Apache Velocity amplia a cobertura além dos artefatos de nível superior do Velocity, abrangendo os componentes suportados na árvore de dependências transitivas.
Conformidade e Risco Regulatório
De acordo com a norma PCI DSS v4.0, o Requisito 6.3.3 exige que os patches e atualizações para vulnerabilidades classificadas como críticas no ambiente de uma organização sejam instalados no prazo de um mês a partir do lançamento; outras atualizações de segurança aplicáveis devem ser instaladas dentro dos prazos estabelecidos por meio da avaliação de riscos da organização (conforme o Requisito 6.3.1).
Como o PCI DSS não classifica automaticamente todas as vulnerabilidades com pontuação CVSS 7.0 ou superior como críticas, o impacto da CVE-2020-13936 — divulgada publicamente desde março de 2021 — na conformidade depende da classificação de risco, da exposição e dos controles documentados pela organização. Outras estruturas e programas de garantia, incluindo HIPAA, SOC 2 Tipo II e FedRAMP, também podem exigir que as organizações identifiquem, avaliem e corrijam as vulnerabilidades aplicáveis, embora seus requisitos devam ser avaliados separadamente.
O ELS para Apache Velocity ajuda as organizações a corrigir as vulnerabilidades relevantes em prazos previsíveis, sem exigir uma migração imediata.
Os riscos de apressar uma migração para o Apache Velocity
A pressão para responder às constatações relacionadas ao fim da vida útil (EOL) do Apache Velocity é real. As ferramentas de SCA geram constatações, os auditores fazem perguntas diretas e os prazos de conformidade não são adiados devido a restrições de capacidade de engenharia. As equipes que lidam bem com o fim da vida útil do Apache Velocity tratam a migração como um projeto de engenharia planejado, com um inventário completo de modelos, testes de regressão e um plano de reversão definido.
O que acontece quando você faz tudo com pressa
Quando as equipes tentam encaixar a migração em um cronograma irrealista, as coisas dão errado de maneiras previsíveis:
- Aumento da carga de suporte: Bugs não detectados durante os testes condensados aparecem imediatamente na produção. As equipes de suporte ficam sobrecarregadas com tickets sobre erros na renderização de modelos e mudanças no comportamento dos fluxos de e-mail ou relatórios, a maioria dos quais decorre de diferenças no VTL ou na API entre o Engine 1.x e o 2.x, que nunca foram totalmente validadas devido ao cronograma apertado.
- Instabilidade do sistema: Algumas alterações na API de dependências só se manifestam sob carga de produção. Falhas intermitentes na renderização de modelos, diferenças na formatação de saída decorrentes das atualizações nas caixas de ferramentas do Tools e mudanças no comportamento de tratamento de erros do VelocityViewServlet geram falhas difíceis de reproduzir e dispendiosas de diagnosticar.
- Acúmulo de dívida técnica: As diferenças de configuração são incorporadas ao código de inicialização do aplicativo, em vez de serem corrigidas na camada da biblioteca. As mudanças no comportamento do VTL entre as versões 1.x e 2.x são contornadas localmente de maneiras não documentadas. O problema do fim de vida útil (EOL) é adiado, não resolvido, e a dívida acumulada torna uma migração adequada mais onerosa posteriormente.
- Custos não planejados: Horas extras de engenharia para emergências, atrasos no lançamento de recursos e o custo de oportunidade de seus melhores engenheiros dedicarem-se à depuração de problemas de compatibilidade de dependências, em vez de desenvolver novos recursos, geralmente excedem o que o suporte de ciclo de vida estendido teria custado durante todo o período de planejamento da migração.
Opções para manter a segurança e a conformidade
As organizações que utilizam versões do Apache Velocity em fim de vida útil têm três opções à disposição. As duas primeiras exigem um trabalho substancial de engenharia e prazos mais longos. A terceira resolve rapidamente a falha de segurança enquanto suas equipes planejam a migração de forma adequada.
Opção 1: Migrar para o Velocity Engine 2.4.1 e o Tools 3.1
A solução a longo prazo é migrar para as versões atuais do upstream — Velocity Engine 2.4.1 e Velocity Tools 3.1, no momento da redação deste artigo. Isso elimina o risco de fim de vida útil (EOL), pois permite a migração para um software que recebe manutenção ativa.
A migração tem um alcance significativo: todas as versões do Engine lançadas desde a 2.1 (março de 2019) exigem o Java 8 como ambiente de execução mínimo, incluindo a versão 2.4.1; portanto, as organizações que executam o Velocity 1.7 em ambientes JVM mais antigos podem precisar realizar uma atualização do Java antes de migrar para qualquer versão moderna da série 2.x. As alterações na API entre o Engine 1.7 e o 2.x — classes removidas, configuração revisada do ResourceLoader e interfaces de introspecção e registro alteradas — podem exigir alterações no código de aplicativos que estendem ou configuram o Velocity por meio de suas APIs Java. O Tools 3.1 amplia ainda mais o escopo com a reestruturação de pacotes e a integração revisada com servlets.
Para aplicativos corporativos com vários pontos de integração com o Velocity, a migração pode exigir meses de inventário, alterações no código e testes de regressão.
Opção 2: Substituir o Velocity por um mecanismo de modelos alternativo
Algumas organizações utilizam o marco de fim de vida útil (EOL) do Apache Velocity como gatilho para avaliar alternativas: Thymeleaf, FreeMarker, Pebble e Mustache são todos mantidos ativamente. A substituição do mecanismo de modelos é mais disruptiva do que uma atualização dentro da mesma versão; os modelos geralmente precisam ser reescritos ou adaptados à sintaxe do novo mecanismo, e todos os caminhos de saída afetados devem ser testados novamente. Trata-se de uma meta viável a longo prazo, não de uma solução para uma constatação imediata de não conformidade com o fim da vida útil do Apache Velocity.
Opção 3: Utilizar o suporte contínuo ao ciclo de vida durante a migração
O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para o Apache Velocity permite que você mantenha a segurança sem precisar realizar uma migração para a qual sua equipe ainda não esteja preparada. Você continua utilizando sua versão atual do Velocity com cobertura contínua de patches de segurança. É exatamente para preencher essa lacuna que o ELS para o Apache Velocity foi projetado: o período entre o fim do suporte oficial e o momento em que sua organização tiver realmente concluído uma migração planejada e controlada.
A solução fácil: TuxCare ELS para Apache Velocity
A TuxCare oferece suporte de ciclo de vida ilimitado para versões do Apache Velocity que chegaram ao fim da vida útil, garantindo que sua implantação atual continue protegida com patches de segurança fornecidos como substitutos JAR prontos para uso por meio de sua cadeia de ferramentas Maven ou Gradle existente. A TuxCare já distribuiu mais de 220.000 patches de segurança em todo o ecossistema de código aberto.
Cobertura completa da árvore de dependências
O TuxCare ELS para Apache Velocity vai além dos JARs do Engine e das Ferramentas, abrangendo componentes suportados na rede de dependências transitivas, incluindo o commons-collections 3.2.1 (CVE-2015-7501, CVSS 9,8 – Crítico) e, para aplicativos que o utilizam, o Log4j 1.x (CVE-2019-17571, CVSS 9,8 – Crítico).
Processo de aplicação de patches otimizado e automatizado
A TuxCare monitora o NVD, os alertas de segurança do Apache, os feeds de segurança do GitHub e os canais de divulgação dos fornecedores 24 horas por dia. Quando um CVE relevante é identificado, a TuxCare aplica a correção às versões suportadas por meio de automação algorítmica e assistida por IA, com especialistas em segurança validando cada patch antes de sua distribuição. Todas as atualizações passam por testes de integridade, funcionalidade e regressão antes de chegarem aos seus repositórios. Para obter detalhes técnicos completos, consulte o white paper “Processo de Aplicação de Patches em Código Aberto da TuxCare”.
Integração perfeita
Quer você utilize o Velocity por meio do Maven Central ou de um espelho de repositório privado, é possível mudar sua fonte de atualização para o repositório seguro da TuxCare com alterações mínimas na configuração do seu repositório. Os JARs corrigidos foram projetados para serem substitutos diretos, preservando a API e a configuração existentes ao mesmo tempo em que incorporam correções de segurança retroativas; assim, a maioria das equipes pode utilizá-los por meio de seus fluxos de trabalho existentes do Maven ou Gradle e de seus pipelines de CI/CD.
Resposta Rápida Apoiada pelo SLA
Quando são divulgadas novas vulnerabilidades que afetam versões do Velocity em fim de vida útil e que contam com suporte — no Engine, nas Ferramentas ou nas dependências cobertas —, a TuxCare fornece patches respaldados por acordos de nível de serviço, com o objetivo de corrigir vulnerabilidades de gravidade alta e crítica (CVSS 7.0 e superior) no prazo de 14 dias a partir da divulgação pública.
Continuidade da segurança com boa relação custo-benefício
O custo do TuxCare ELS é uma fração do que custaria uma migração de emergência sob a pressão de prazos de conformidade. Você planeja uma migração metódica para o Velocity Engine 2.4.1 e o Tools 3.1 quando isso se encaixar na capacidade da sua equipe, incluindo tempo para avaliar o impacto total das dependências transitivas e validar cada caminho de saída dos modelos. Ou você usa o ELS para manter a cobertura de patches de segurança e apoiar seus esforços de conformidade, enquanto toma essas decisões de acordo com o seu próprio cronograma.
Não deixe que o fim da vida útil do Apache Velocity coloque suas aplicações Java em risco
O fim da vida útil (EOL) do Apache Velocity não significa que sua aplicação fique comprometida imediatamente. Significa, porém, que componentes com vulnerabilidades conhecidas podem permanecer na sua árvore de dependências de produção — incluindo uma vulnerabilidade do Velocity classificada como “Alta” (CVSS 8,8) e vulnerabilidades de dependências classificadas como “Crítica” (CVSS 9,8) — e que o projeto de origem não irá corrigi-las.
A possibilidade de cada vulnerabilidade ser explorada depende da configuração do seu aplicativo, dos fluxos de dados e dos controles de segurança; no entanto, cada mês que se passa após a divulgação de um CVE referente a uma versão fora de suporte é um mês durante o qual a janela de exposição permanece aberta.
A resposta adequada ao fim do ciclo de vida do Apache Velocity depende do cronograma e da capacidade de engenharia da sua organização. Se você puder migrar para o Engine 2.4.1 e o Tools 3.1 agora, esse é o caminho certo a seguir. Se a complexidade da sua integração com o Velocity tornar uma atualização imediata impraticável, o TuxCare ELS para Apache Velocity oferece cobertura contínua de patches de segurança enquanto você planeja e conclui a migração de forma adequada.
Se o fim do ciclo de vida do Apache Velocity está em sua agenda de segurança no momento, acesse Suporte de Ciclo de Vida Ilimitado da TuxCare para Software de Código Aberto para ver como o suporte estendido pode proteger toda a sua pilha de código aberto.
