Falha no IBM Test Management pode derrubar o serviço — não há mitigação
Em 27 de agosto de 2026, a IBM publicou um alerta para o IBM Engineering Test Management 7.0.3, 7.1 e 7.2 por uma falha capaz de provocar negação de serviço quando o produto usa versões vulneráveis do WebSphere Application Server Liberty. O boletim do Engineering Test Management declara que não há mitigação ou solução de contorno e orienta a instalação da correção provisória do APAR DT497316 ou de um fix pack que a incorpore.
A exposição depende do Liberty vulnerável com o recurso restConnector-2.0 habilitado. Em 30 de agosto, a opção imediatamente disponível era o interim fix: o Liberty 26.0.0.9, primeiro fix pack indicado como corrigido, continuava previsto para uma data posterior.
Quais instalações do Test Management estão no alcance
O alerta abrange três versões do IBM Engineering Test Management e identifica o nível de Liberty associado a cada uma: Test Management 7.2 com Liberty 25.0.0.9, Test Management 7.1 com Liberty 25.0.0.3 e Test Management 7.0.3 com Liberty 23.0.0.6. As plataformas listadas no documento são Linux e Windows.
Esses números servem para localizar as instalações que precisam de análise, mas a versão do produto não encerra o diagnóstico. A condição descrita exige também que o restConnector-2.0 esteja ativo, por isso o inventário deve refletir o runtime e a configuração realmente carregados pela instância.
Mesmo quando o recurso não aparece na configuração ativa, a conclusão deve ser registrada por ambiente, sem ser generalizada para outras instâncias. Quando ele está habilitado em um dos níveis vulneráveis, a IBM não oferece uma configuração alternativa como mitigação oficial: monitoramento ou restrições operacionais não substituem a instalação do código corrigido.
Por que a falha pode interromper o serviço
A CVE decorre de desserialização insegura no WebSphere Liberty. O registro da National Vulnerability Database informa que um usuário administrativo com poucos privilégios pode explorar a condição para consumir recursos do sistema quando o restConnector-2.0 está habilitado; o intervalo afetado vai do Liberty 17.0.0.3 ao 26.0.0.8.
O consumo de recursos pode deixar o runtime sem capacidade para atender solicitações, concretizando a negação de serviço mencionada no alerta. No Engineering Test Management, isso pode tornar indisponíveis as operações hospedadas naquela instância, o que sustenta o risco de “derrubar o serviço” indicado no título.
A IBM atribuiu CVSS 3.1 de 5,7, com severidade média e impacto alto sobre disponibilidade. A NVD exibe também uma avaliação própria de 5,3 porque utiliza um vetor de acesso diferente; os dois valores tratam da mesma falha, mas resultam de métricas atribuídas por fontes distintas. Essa diferença não altera o intervalo vulnerável nem a necessidade de correção.
Como escolher entre interim fix e fix pack
A decisão é temporal e técnica. Para corrigir antes da publicação do próximo fix pack, a equipe deve elevar o Liberty ao nível mínimo exigido pelo pacote provisório e instalar o interim fix que resolve o APAR DT497316. Os requisitos exatos do pacote precisam ser conferidos para a plataforma e para o nível atualmente instalado.
O Liberty 26.0.0.9 ou posterior é a alternativa cumulativa, mas ainda não estava disponível na data desta notícia. A página de atualizações recomendadas do WebSphere marcava 8 de setembro de 2026 como data futura estimada para o 26.0.0.9, enquanto o boletim de segurança adotava a previsão mais ampla do terceiro trimestre.
Assim, o fluxo de decisão fica restrito a dois caminhos:
- Identificar a versão ativa do Engineering Test Management e o nível do Liberty usado por aquela instância.
- Confirmar na configuração efetiva se o restConnector-2.0 está habilitado.
- Se a combinação estiver exposta e a correção não puder esperar, instalar o interim fix do APAR DT497316 sobre um nível compatível.
- Depois que o Liberty 26.0.0.9 estiver efetivamente publicado e homologado para o ambiente, usar esse fix pack ou uma versão posterior como alternativa cumulativa.
A data estimada não deve ser tratada como garantia de disponibilidade. Até que o pacote apareça no canal de distribuição aplicável, esperar por ele significa manter a instalação vulnerável; para uma correção imediata, resta o interim fix.
Como validar a correção aplicada
A validação deve provar qual código está em execução, e não apenas que o instalador terminou. No caminho provisório, o inventário de manutenção precisa mostrar o interim fix correspondente ao APAR DT497316 no runtime usado pelo Test Management. No caminho cumulativo, quando disponível, a instância deve iniciar com Liberty 26.0.0.9 ou posterior.
Depois da reinicialização prevista no procedimento de mudança, convém confirmar autenticação, abertura de projetos, leitura e atualização de artefatos de teste e integrações essenciais daquela implantação. Os logs de inicialização também devem ser examinados para detectar falhas no carregamento de recursos, incompatibilidades ou retorno involuntário a binários de um diretório anterior.
CPU, memória e disponibilidade ajudam a identificar regressões após a intervenção, mas não demonstram sozinhas que a vulnerabilidade foi removida. A evidência principal é a presença do APAR no runtime ativo ou, após seu lançamento, de um fix pack corrigido.
O estado confirmado em 30 de agosto era, portanto, limitado: as versões 7.0.3, 7.1 e 7.2 estavam incluídas no alerta de 27 de agosto, não havia mitigação documentada e o fix pack permanecia futuro. Até a publicação efetiva do Liberty 26.0.0.9, o interim fix compatível era a única rota imediata indicada para eliminar a exposição.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.