Resumo para quem decide

A F5 corrigiu uma vulnerabilidade crítica no BIG-IP APM (Access Policy Manager) que já está sendo explorada ativamente. É a CVE-2026-94127, um heap-based buffer overflow que permite execução remota de código sem nenhuma autenticação, com CVSS v3.1 de 9.8 e CVSS v4.0 de 9.3, segundo a The Hacker News.

A falha afeta especificamente instalações onde o APM atua como servidor de autorização OAuth. A CISA já incluiu a vulnerabilidade no catálogo Known Exploited Vulnerabilities (KEV) em 22 de setembro e determinou que agências civis federais dos EUA aplicassem mitigação até 25 de setembro.

O que sua equipe precisa decidir agora:

1. Verificar se algum virtual server do BIG-IP tem uma access policy do APM combinada com um perfil de OAuth authorization server. Se não tiver, o sistema não é afetado por esta falha específica.
2. Se tiver, aplicar o hotfix correspondente à sua branch imediatamente, ou solicitar a iRule de mitigação ao suporte F5 enquanto o patch não é instalado.
3. Não assumir que restringir o acesso à interface de gerenciamento resolve o problema. Não resolve.
4. Rodar as verificações de log e o comando tmctl descritos mais abaixo para identificar sinais de exploração antes de aplicar o patch, preservando evidências.

Times que já aplicaram builds como 17.1.3 ou 17.5.1.3 (corrigindo a CVE-2025-53521 anterior) não estão automaticamente protegidos contra esta nova falha. É preciso o hotfix específico.

A falha no BIG-IP APM: o que é a CVE-2026-94127

A CVE-2026-94127 é um heap-based buffer overflow no BIG-IP APM que resulta em execução remota de código não autenticada. Não é preciso credencial, token válido ou qualquer forma de acesso prévio para explorar a falha. O atacante envia tráfego malicioso diretamente ao virtual server vulnerável.

A F5 confirmou exploração ativa da vulnerabilidade, conforme registrado pelo CERT-EU. Quantos sistemas foram atingidos, quem está por trás e quais organizações foram alvo, nem a F5 nem a CISA divulgaram.

Como funciona o vetor de ataque: APM como servidor de autorização OAuth

O componente vulnerável é o APM configurado como OAuth authorization server, ou seja, emitindo access tokens para aplicações. A condição necessária é ter, no mesmo virtual server, uma access policy do APM e um perfil de servidor de autorização OAuth.

Na prática, esse perfil é criado em Access > Federation > OAuth Authorization Server > OAuth Profile, e depois vinculado a um access profile associado ao virtual server, segundo o guia de configuração do APM nas versões 17.1, 17.5 e 21.0. Se essa combinação existir no seu ambiente, o virtual server que recebe tráfego OAuth está exposto.

Isso conecta diretamente com um problema mais amplo de segurança em fluxos de federação de identidade: componentes que deveriam ser barreira de controle de acesso podem virar o ponto de entrada do atacante quando mal configurados ou vulneráveis. Já tratamos essa dinâmica em Abuso de consentimento OAuth e os impactos no controle de acesso corporativo, que vale revisar se sua organização depende de OAuth para autenticação corporativa.

Vale destacar: sistemas rodando em modo Appliance também são vulneráveis. Não há exceção por modo de implantação.

Por que isolar a interface de gerenciamento não protege contra essa falha

Um erro comum de avaliação de risco em appliances de borda é assumir que, se a management interface está isolada da internet, o sistema está protegido. Essa falha prova o contrário: o ataque ocorre via tráfego de aplicação enviado ao virtual server, não via management plane.

Isso significa que times que seguem a boa prática de isolar a interface de gerenciamento do BIG-IP, mas expõem o virtual server de OAuth normalmente (porque ele precisa receber tráfego de aplicações legítimas), continuam totalmente expostos. O problema está no data plane, não no plano de gerenciamento.

Esse padrão se repete em falhas de appliances como F5, Citrix e Fortinet: a superfície real de ataque é o tráfego processado pela função de negócio, não apenas o acesso administrativo. Para times que avaliam segurança de APIs e serviços expostos, o princípio é o mesmo discutido em API Security: O Elo Crítico na Segurança de Microserviços: a superfície que processa requisições de aplicação precisa de controle e monitoramento tão rigoroso quanto o plano administrativo, senão mais.

Divergência de escopo entre F5, CISA e CERT-EU: o que isso muda na prática

Há um detalhe importante na linha do tempo desta vulnerabilidade. A F5 atualizou o registro CVE às 00:45 UTC de 23 de setembro para especificar que a falha existe apenas quando o APM atua como OAuth authorization server.

O problema é que a entrada da CISA no KEV e o advisory do CERT-EU foram publicados antes dessa atualização, e descrevem a condição de forma mais ampla: apenas “access policy e um perfil OAuth no mesmo virtual server”, sem especificar o papel de authorization server.

Na prática, isso importa porque, seguindo a descrição mais recente e específica da F5, sistemas que usam APM apenas como OAuth client ou resource server, sem perfis de authorization server, não são afetados por esta CVE. Times que leram apenas o advisory da CISA ou do CERT-EU antes da correção podem ter classificado erroneamente seus ambientes, seja marcando como vulnerável um sistema que na verdade não atende à condição real, seja o contrário.

A lição operacional aqui é simples: descrições de CVE em zero-days frequentemente são refinadas nas primeiras 24 a 48 horas após a divulgação inicial. Vale revisitar a página oficial do CVE do fabricante antes de fechar a triagem, principalmente quando o registro inicial veio de terceiros como CISA ou CERT-EU, e não diretamente do vendor.

Versões afetadas, hotfixes e a armadilha da CVE-2025-53521

Branches e hotfixes disponíveis por versão

A F5 confirmou as seguintes versões afetadas e seus respectivos hotfixes:

• Branch 21.1: afetada a versão 21.1.0 antes do hotfix. Corrigida em Hotfix-BIGIP-21.1.0.2.0.30.22-ENG.
• Branch 17.5: afetadas as versões 17.5.0 a 17.5.1 antes do hotfix. Corrigida em Hotfix-BIGIP-17.5.1.9.0.160.12-ENG.
• Branch 17.1: afetadas as versões 17.1.0 a 17.1.3 antes do hotfix. Corrigida em Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.

O CERT-EU lista os mesmos intervalos de versões, mas com a descrição de condição pré-atualização (access policy mais perfil OAuth genérico, sem especificar authorization server).

Um ponto crítico: a F5 não avaliou versões que já atingiram o End of Technical Support (EoTS). Isso significa que o status de segurança dessas versões é desconhecido, não confirmado como seguro. Se sua organização roda uma versão fora de suporte técnico, não há garantia de que ela esteja livre da falha, apenas ausência de avaliação.

Por que builds já corrigidos para a CVE-2025-53521 ainda podem estar vulneráveis

Existe uma sobreposição relevante entre esta falha e uma vulnerabilidade anterior do APM, a CVE-2025-53521, que foi adicionada ao KEV da CISA em março. Os builds 17.1.3 e 17.5.1.3, que corrigiram aquela falha anterior, caem dentro dos intervalos de versão afetados pela CVE-2026-94127.

Na prática: um sistema que já foi atualizado para 17.1.3 ou 17.5.1.3 pensando estar protegido contra a CVE-2025-53521 ainda precisa do novo hotfix se o APM estiver configurado como OAuth authorization server. Ter aplicado o patch anterior não cobre esta nova falha.

Esse tipo de situação é uma armadilha comum em gestão de patches de appliances de borda: acumular atualizações de segurança cria uma falsa sensação de que o sistema está “em dia”, mas cada CVE tem seu próprio hotfix e sua própria condição de exposição, muitas vezes ligada a uma função específica habilitada, e não à versão do software isoladamente. O mesmo padrão de falsa segurança por patch acumulado aparece em outros contextos de cadeia de fornecimento de software, como discutimos em Supply Chain Attack: Vulnerabilidades Ocultas na Cadeia Digital de Fornecedores.

O recomendado é conferir a versão exata do hotfix aplicado (o identificador completo, como Hotfix-BIGIP-17.1.3.5.0.41.14-ENG), não apenas a versão base do BIG-IP.

Como identificar sinais de comprometimento (IoCs e threat hunting)

Antes de aplicar o patch, vale rodar uma checagem rápida de indicadores de comprometimento, para preservar evidências caso o sistema já tenha sido explorado.

Padrões suspeitos nos logs do APM e de auditoria

O sinal mais indicativo é uma combinação de três eventos em sequência: falhas repetidas de autenticação OAuth, seguidas de comandos suspeitos no log de auditoria, seguidas de um TMM SIGABRT logo depois.

No log do APM (/var/log/apm), procure por requisições UserInfo falhas repetidas com a descrição de erro “The access token is invalid.” Preste atenção especial a 10 ou mais requisições vindas de um único IP em curto período. O CERT-EU forneceu um exemplo de linha de log com esse padrão:

<DATE> <HOST> err tmm1[30975]: 01990004:3: <PROFILE_NAME>: Request UserInfo from Source ID (null) IP <IP> failed. Error Code (invalid_token) Error Description (The access token is invalid.)

No log de auditoria (/var/log/audit), revise comandos suspeitos executados ao redor dos horários em que essas falhas OAuth foram registradas.

Arquivos core do TMM não são um indicador isolado de comprometimento, mas merecem investigação quando aparecem junto aos outros sinais. A F5 observou o processo TMM entrando em loop, levando o daemon SOD a enviar um SIGABRT.

Comando tmctl e verificação do contador OAuth

Rode o seguinte comando para verificar o contador de requisições OAuth falhas:

tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

Um aumento inexplicado no valor de total_failed é um sinal que justifica investigação mais profunda, cruzando com os logs de APM e auditoria descritos acima.

Se a combinação dos três sinais (falhas OAuth repetidas, comandos suspeitos no log de auditoria, e SIGABRT do TMM) aparecer no seu ambiente, trate como possível comprometimento e escale para resposta a incidentes antes de simplesmente aplicar o patch e seguir em frente. O CERT-EU recomenda essa ordem: preservar evidências forenses primeiro, aplicar o hotfix, checar sinais de comprometimento, e iniciar resposta a incidentes se algo for encontrado.

Vale notar que nem o registro CVE da F5, nem os advisories da CISA e do CERT-EU, informam se a instalação do hotfix remove um acesso que o atacante já tenha obtido no sistema antes do patch. Por isso a ordem de preservar evidências antes de corrigir é importante.

Mitigação, patch e prioridades de resposta

Aplicar a iRule antes do hotfix: a ordem que a CISA recomenda

Quando o hotfix não pode ser instalado imediatamente, a F5 oferece uma mitigação via iRule para o virtual server afetado. Essa iRule é obtida abrindo um ticket com o suporte da F5, não está disponível como download público.

A CISA orientou agências federais a aplicar primeiro a iRule, nas palavras dela, “para permitir triagem forense proativa”, e só então instalar o patch definitivo o quanto antes.

A sequência vale além do contexto federal americano, e é a mesma que o CERT-EU recomenda a qualquer organização: preservar evidências, aplicar a correção, checar sinais de comprometimento e abrir resposta a incidentes se algum aparecer.

Checklist de mitigação e prazo regulatório

Resumo prático de ação:

1. Identifique exposição real: confirme se algum virtual server tem access policy do APM combinada com perfil de OAuth authorization server. Sistemas usando APM apenas como client ou resource server não são afetados por esta CVE específica.
2. Preserve evidências: rode as checagens de log, auditoria e o comando tmctl antes de aplicar qualquer correção.
3. Aplique mitigação temporária se necessário: solicite a iRule ao suporte F5 se o hotfix não puder ser instalado de imediato.
4. Aplique o hotfix correto para sua branch: confira o identificador exato do hotfix, não apenas o número de versão do BIG-IP.
5. Não confie em builds anteriores: se sua versão é 17.1.3 ou 17.5.1.3, corrigida para a CVE-2025-53521, você ainda precisa do novo hotfix se o APM atuar como OAuth authorization server.
6. Trate versões fora de suporte com cautela: a F5 não avaliou versões em EoTS, então o status delas permanece desconhecido.

A CISA determinou que agências civis federais dos EUA aplicassem as mitigações da F5 até 25 de setembro, sob uma diretiva emitida em junho. Embora esse prazo seja específico do governo americano, ele reflete a gravidade que a própria F5 e a CISA atribuem à falha, dado que já há exploração ativa confirmada.

Perguntas frequentes

Minha instalação do BIG-IP APM está vulnerável se eu uso OAuth apenas como client, não como servidor de autorização?
Segundo a descrição mais recente e específica publicada pela F5, não. A condição necessária é ter uma access policy do APM combinada com um perfil de OAuth authorization server no mesmo virtual server. Sistemas usando APM apenas como OAuth client ou resource server, sem perfis de authorization server, não são afetados por esta CVE.

Isolar a interface de gerenciamento do BIG-IP me protege dessa falha?
Não. O ataque ocorre via tráfego enviado ao virtual server que processa requisições OAuth, não via interface de gerenciamento. Isolar a management interface não reduz esse risco.

Já apliquei o patch da CVE-2025-53521. Ainda preciso me preocupar com essa nova falha?
Sim, se seu APM atuar como OAuth authorization server. Os builds 17.1.3 e 17.5.1.3, que corrigiram a CVE-2025-53521, caem dentro dos intervalos afetados pela CVE-2026-94127. É preciso o hotfix específico desta nova falha.

Existe prova de conceito pública para essa vulnerabilidade?
Não há informação disponível sobre isso nas divulgações da F5, CISA ou CERT-EU.

Quantos sistemas foram atacados e quem são os atacantes?
Não. Nem o registro CVE da F5, nem a entrada no KEV da CISA, trazem esse tipo de detalhe.

O que fazer se eu não puder aplicar o hotfix imediatamente?
Abra um ticket com o suporte da F5 para obter a iRule de mitigação temporária para o virtual server afetado, e priorize preservar evidências de log antes de aplicar qualquer correção definitiva.

Fonte: F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE on OAuth Servers, The Hacker News e advisory do CERT-EU.