CISA inclui `CVE-2025-53521` no KEV após exploração ativa contra F5 BIG-IP APM

Falha crítica no Access Policy Manager foi reclassificada de negação de serviço para execução remota de código após novos dados técnicos e sinais de exploração em versões vulneráveis do BIG-IP.

Componente	F5 BIG-IP Access Policy Manager quando uma política de acesso do APM está configurada em um servidor virtual.
Vetor	Tráfego malicioso específico direcionado ao servidor virtual com política APM, antes da autenticação conforme avaliação técnica citada no contexto.
Impacto	Execução remota de código em versões vulneráveis do BIG-IP, com observação de webshells e alterações em componentes do sistema.
Prioridade	Aplicar as correções da F5, verificar indicadores locais de comprometimento e revisar telemetria do iControl REST, do auditd e do tráfego HTTP/S originado pelo appliance.
Artefatos	Indicadores incluem presença de /run/bigtlog.pipe ou /run/bigstart.ltm, divergências em /usr/bin/umount e /usr/sbin/httpd, e mudanças em arquivos sob /var/sam/www/webtop/renderer/.
Mitigação	Agências federais civis dos EUA receberam prazo até 30 de março de 2026 para aplicar correções; organizações não federais devem tratar a inclusão no KEV como sinal de exploração confirmada.

Resumo técnico

A vulnerabilidade CVE-2025-53521 passou a integrar o catálogo Known Exploited Vulnerabilities da CISA após evidências de exploração ativa contra o F5 BIG-IP Access Policy Manager. A falha recebeu pontuação CVSS v4 9.3 e afeta cenários em que uma política de acesso do APM está configurada em um servidor virtual. Nesse estado, tráfego malicioso específico pode levar à execução remota de código, alterando de forma material o risco operacional associado ao problema.

O ponto crítico da atualização é a mudança de classificação. A falha havia sido tratada inicialmente como negação de serviço, com pontuação CVSS v4 8.7, e depois foi reclassificada como execução remota de código a partir de novas informações obtidas em março de 2026. Essa diferença não é apenas semântica: um problema de indisponibilidade costuma ser priorizado com foco em continuidade, enquanto execução remota de código em um dispositivo de borda exige resposta de comprometimento, verificação de integridade e análise de possíveis ações pós-exploração.

A F5 confirmou que a vulnerabilidade foi explorada em versões vulneráveis do BIG-IP, mas não atribuiu a atividade a um ator específico. Também foram publicados indicadores para avaliar comprometimento, incluindo artefatos de arquivo, alterações em binários e registros de uso local do iControl REST API. O material técnico menciona ainda casos de webshell escrita em disco, com a ressalva de que algumas webshells observadas funcionavam somente em memória, o que reduz a confiabilidade de uma busca baseada exclusivamente em modificação de arquivos.

Fluxo técnico

A condição necessária descrita para exploração é a presença de uma política do BIG-IP APM aplicada a um servidor virtual. Nessa superfície, requisições maliciosas direcionadas ao componente de acesso podem acionar a falha e permitir execução de código no appliance. O contexto não fornece um payload reproduzível nem um caminho completo de exploração, portanto a resposta defensiva deve se concentrar nas precondições, nos sinais de pós-exploração e na aplicação de correções, e não em tentativas de reconstruir a técnica ofensiva.

Os sinais publicados indicam que a atividade observada não se limita a provocar falha de serviço. Há referência a webshells, alterações em componentes de sistema e tentativa de disfarçar atividade por meio de tráfego HTTP/S originado do próprio BIG-IP com códigos de resposta HTTP 201 e tipo de conteúdo CSS. Esse padrão sugere que a investigação deve considerar tanto persistência ou execução em memória quanto manipulação de artefatos em disco, especialmente porque alguns indicadores podem não aparecer caso o implante opere sem modificar os arquivos listados.

Um ponto relevante para caçada é a sondagem do endpoint /mgmt/shared/identified-devices/config/device-info, usado pela API REST do BIG-IP para recuperar informações de sistema, como hostname, identificador de máquina e endereço MAC base. O contexto descreve atividade intensa de varredura contra dispositivos vulneráveis após a inclusão da falha no KEV. Esse tipo de acesso pode ser usado por operadores para identificar appliances, validar exposição e selecionar alvos antes de ações mais invasivas.

A exploração também foi associada a registros em que um usuário local acessa a API iControl REST a partir de localhost. Em outro indicador, logs do auditd mostram acesso local ao iControl REST para desativar SELinux. Esses eventos são relevantes porque deslocam a investigação para além do tráfego externo inicial: mesmo quando o vetor começa pela rede, os rastros úteis podem aparecer como ações locais executadas pelo próprio dispositivo ou por processos comprometidos no appliance.

Superfície afetada

A superfície exposta é composta por instâncias F5 BIG-IP com o Access Policy Manager em versões vulneráveis e com política de acesso configurada em servidor virtual. O contexto não informa números específicos de versão, ramos de suporte ou builds corrigidos, portanto a confirmação de exposição deve ser feita contra o inventário interno e os avisos técnicos da F5 usados pela equipe responsável pelo appliance. O fato de a falha ter sido reclassificada aumenta a importância de revisar sistemas que podem ter sido deixados em fila de atualização quando o problema ainda parecia restrito a negação de serviço.

Dispositivos BIG-IP costumam ocupar posições sensíveis na borda de rede, intermediando acesso remoto, autenticação, publicação de aplicações e fluxos HTTP/S. Quando um componente desse tipo passa a ter execução remota de código confirmada, o risco não se limita ao serviço publicado: o appliance pode ter visibilidade de tráfego, integrações de identidade e conectividade com redes internas. O contexto não confirma exfiltração, movimentação lateral ou roubo de dados, mas sustenta a necessidade de avaliar integridade do sistema e sinais de atividade pós-exploração.

A investigação deve considerar que a presença de determinados arquivos, sozinha, não confirma incidente. O próprio conjunto de indicadores diferencia artefatos que podem ser suspeitos de itens cuja presença isolada não sinaliza necessariamente um problema. Por isso, a análise deve combinar comparação de hashes, tamanhos e timestamps com logs de auditoria, registros REST e comportamento de rede originado pelo BIG-IP.

• BIG-IP APM com política de acesso aplicada a servidor virtual.
• Versões vulneráveis do BIG-IP, sem numeração específica fornecida no material analisado.
• API iControl REST acessada localmente a partir de localhost em registros de auditoria.
• Arquivos e binários sensíveis como /usr/bin/umount, /usr/sbin/httpd, /run/bigtlog.pipe e /run/bigstart.ltm.

Hunting e telemetria

A primeira linha de hunting deve comparar o estado do appliance com uma base íntegra conhecida. O contexto cita divergências de hash, tamanho ou timestamp em /usr/bin/umount e /usr/sbin/httpd, além de modificações em componentes usados pelo verificador de integridade sys-eicheck. Se o próprio mecanismo de verificação depender de arquivos alterados, uma falha da ferramenta ou resultados inconsistentes devem ser tratados como sinal investigativo, não como simples erro operacional.

Em logs, a busca deve priorizar entradas em /var/log/restjavad-audit.*.log que mostrem usuário local acessando a API iControl REST a partir de localhost. Também devem ser avaliadas entradas em /var/log/auditd/audit.log.* relacionadas ao acesso local ao iControl REST para desativar SELinux, bem como mensagens em /var/log/audit que registrem resultados de comandos executados. O objetivo defensivo é identificar execução anômala e mudanças de controle de segurança, sem depender de payloads ou comandos específicos.

Na rede, a telemetria deve observar tráfego HTTP/S originado pelo sistema BIG-IP com respostas HTTP 201 e tipo de conteúdo CSS quando esse padrão não corresponde ao comportamento esperado do ambiente. O contexto indica que esse formato foi usado para disfarçar atividades do atacante. Também é recomendável procurar requisições para /mgmt/shared/identified-devices/config/device-info, principalmente quando vindas de origens não administrativas, em horários incomuns ou em sequência compatível com varredura.

A detecção não deve se limitar a webshells gravadas em disco. A ressalva de que webshells podem operar apenas em memória significa que a ausência dos arquivos listados não encerra a investigação. Em ambientes com suspeita, é necessário correlacionar integridade de arquivos, eventos de auditoria, conexões originadas pelo appliance e mudanças recentes em componentes do APM.

• Presença de /run/bigtlog.pipe ou /run/bigstart.ltm.
• Hash, tamanho ou timestamp divergente em /usr/bin/umount ou /usr/sbin/httpd quando comparado a versões íntegras conhecidas.
• Acesso local ao iControl REST API a partir de localhost em logs restjavad-audit.
• Registro no auditd associado à desativação de SELinux por acesso local ao iControl REST.
• Tráfego HTTP/S originado do BIG-IP com HTTP 201 e tipo de conteúdo CSS fora do padrão esperado.
• Requisições ao endpoint /mgmt/shared/identified-devices/config/device-info em contexto de varredura ou acesso não administrativo.

Mitigação

A medida principal é aplicar as correções disponibilizadas pela F5 para as versões vulneráveis do BIG-IP. A inclusão da CVE-2025-53521 no KEV estabelece exploração ativa como fato operacional e eleva a prioridade de atualização. Para agências federais civis dos Estados Unidos, o prazo estabelecido foi 30 de março de 2026; para outras organizações, a mesma data funciona como referência de urgência para tratar appliances expostos, especialmente quando o APM está publicado em borda.

Antes ou imediatamente após a correção, a equipe deve coletar evidências suficientes para identificar comprometimento. Isso inclui preservar logs relevantes, registrar hashes e metadados de arquivos sensíveis, revisar alterações em componentes do sistema e verificar tráfego anômalo originado pelo appliance. Em sistemas com sinais de webshell, alteração de binários ou desativação de controles, a resposta deve considerar isolamento controlado, revisão de contas administrativas e validação completa da configuração do BIG-IP.

A mitigação também deve reduzir a exposição administrativa. Endpoints de gerenciamento e API REST não devem ficar acessíveis a redes não confiáveis, e acessos administrativos precisam estar restritos por origem, identidade e monitoramento. O contexto não detalha um bypass de autenticação específico para interface de gerenciamento, mas a observação de varredura contra endpoint REST reforça a necessidade de segmentação e registro detalhado desse plano de controle.

Depois da atualização, a validação deve confirmar que a política APM em servidores virtuais continua funcional, que o sistema de integridade não apresenta falhas inesperadas e que os arquivos citados não divergiram de uma base confiável. Como parte do encerramento, a organização deve revisar janelas anteriores à correção, pois a reclassificação de negação de serviço para execução remota de código indica que sistemas antes considerados de menor prioridade podem ter permanecido vulneráveis durante atividade exploratória real.

• Aplicar as correções da F5 para a CVE-2025-53521 nos BIG-IP vulneráveis.
• Inventariar servidores virtuais com políticas APM configuradas e priorizar os expostos à internet ou a redes não confiáveis.
• Preservar e revisar logs restjavad-audit, auditd e /var/log/audit antes de limpar ou reiniciar sistemas suspeitos.
• Comparar hashes, tamanhos e timestamps dos binários citados com uma base íntegra conhecida.
• Restringir acesso a interfaces e endpoints de gerenciamento, incluindo iControl REST, a redes administrativas controladas.
• Investigar sinais de webshell em disco e em memória quando houver indícios de execução remota de código.
• Revalidar controles como SELinux e o funcionamento do sys-eicheck após correção e contenção.