Resumo para quem decide

A Palo Alto Networks confirmou que a CVE-2026-0322, uma falha de execução remota de código (RCE) na interface de gerenciamento do PAN-OS, já está sendo explorada em ataques. O fabricante classifica a vulnerabilidade como HIGH (CVSS 8.6) mas marca a urgência sugerida de correção como HIGHEST.

A falha afeta firewalls PA-Series, VM-Series e Panorama (virtual e M-Series) rodando versões desatualizadas do PAN-OS. Cloud NGFW e Prisma Access não são afetados. A exploração exige autenticação prévia, mas um atacante com credenciais válidas, mesmo obtidas por vazamento, reuso de senha ou phishing, consegue executar código como root no equipamento. Não há workaround oficial: a correção é atualizar para uma versão corrigida do PAN-OS. Enquanto isso não acontece, restringir o acesso à interface de gerenciamento é a mitigação prática disponível.

Se sua empresa opera firewalls Palo Alto com a interface de gerenciamento exposta à internet ou acessível por qualquer máquina da rede interna, isso precisa ser tratado como prioridade imediata. O impacto de uma RCE com privilégios root em um dispositivo de borda não se limita ao próprio firewall: ele costuma ser o ponto de entrada para prejuízos maiores na rede corporativa.

O que é a CVE-2026-0322

A CVE-2026-0322 é uma vulnerabilidade de execução remota de código autenticada na interface de gerenciamento do PAN-OS, classificada como CWE-94 (Improper Control of Generation of Code / Code Injection). O advisory oficial da Palo Alto Networks está publicado em security.paloaltonetworks.com/CVE-2026-0322, e o alerta também foi noticiado pela BleepingComputer. A falha foi descoberta internamente pela própria Palo Alto, e o advisory saiu em 14 de outubro, com atualização no dia 15.

Classificação, CVSS e por que a urgência é “HIGHEST” mesmo com score 8.6

O vetor CVSS 4.0 divulgado pelo fabricante é CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:A/AU:N/R:U/V:D/RE:M/U:Red, resultando em CVSS-BT e CVSS-B de 8.6. Existe também um vetor alternativo via rede adjacente (AV:A), com nota um pouco menor (8.5), relevante para quem já isolou o acesso de gerenciamento atrás de uma jump box.

O ponto que chama atenção é a combinação entre severidade “apenas” HIGH e urgência marcada como HIGHEST. Isso acontece porque o CVSS isolado não captura todo o contexto de risco: o campo Exploit Maturity está marcado como ATTACKED, ou seja, exploração confirmada em campo, e a Attack Complexity é LOW, sem exigência de interação do usuário e sem necessidade de condições especiais de ataque (Attack Requirements: NONE). O próprio fabricante registra que “nenhuma configuração especial é necessária” para estar exposto. Essa é a lógica que deveria orientar a priorização de qualquer equipe de resposta: o número isolado do CVSS é só um dos sinais, exploração ativa confirmada pesa tanto ou mais na decisão de corrigir agora.

Vetor de ataque: interface de gerenciamento, autenticação exigida e execução como root

A exploração depende de dois elementos: credenciais válidas (Privileges Required: HIGH) e acesso de rede à interface de gerenciamento do PAN-OS. Não há exigência de interação do usuário, e a complexidade de ataque é baixa. Uma vez explorada com sucesso, a falha permite execução de código arbitrário com privilégios root no firewall, ou seja, controle total do dispositivo.

A exigência de autenticação costuma ser lida como um fator que reduz drasticamente o risco, mas na prática isso nem sempre se sustenta. Credenciais administrativas vazadas, reutilizadas entre sistemas ou obtidas via engenharia social continuam sendo um dos vetores mais comuns de comprometimento inicial. Vale o contraste com casos de RCE não autenticada, como o zero-day no BIG-IP APM da F5 (CVE-2026-94127), onde nem sequer uma credencial é necessária. A diferença de pré-requisito existe, mas o resultado final, código arbitrário como root em um dispositivo de borda crítico, é equivalente nos dois casos. Empresas que tratam “exige autenticação” como sinônimo de “risco baixo” estão subestimando o problema.

O risco aumenta proporcionalmente à exposição: o próprio fabricante destaca que o cenário mais crítico é quando a interface de gerenciamento está acessível a partir de endereços IP externos na internet, uma configuração que nunca deveria existir em produção, mas que ainda é comum em ambientes legados ou mal documentados.

Quem está exposto e como corrigir

Versões afetadas e versões corrigidas por branch do PAN-OS

A tabela de produtos afetados do advisory cobre cinco branches do PAN-OS. Resumo das versões vulneráveis e das correções disponíveis:

• PAN-OS 12.2: afetado abaixo de 12.2.4; corrigir para 12.2.4 ou superior.
• PAN-OS 12.1: afetado abaixo de 12.1.4-h12, 12.1.7-h8 ou 12.1.10-h2, conforme a sublinha; corrigir para a respectiva versão “-h” ou superior.
• PAN-OS 11.2: afetado abaixo de 11.2.4-h22, 11.2.7-h21, 11.2.10-h15, 11.2.13-h3 ou 11.2.16, conforme a sublinha; corrigir para a respectiva versão ou superior.
• PAN-OS 11.1: afetado abaixo de 11.1.4-h37, 11.1.6-h39, 11.1.7-h11, 11.1.10-h35, 11.1.13-h15 ou 11.1.16-h3, conforme a sublinha; corrigir para a respectiva versão ou superior.
• PAN-OS 10.2: afetado abaixo de 10.2.7-h38, 10.2.10-h41, 10.2.13-h26, 10.2.16-h11 ou 10.2.18-h12, conforme a sublinha; corrigir para a respectiva versão ou superior.

O time técnico deve conferir a versão exata em uso (incluindo o sufixo “-h”) contra essa tabela, porque a correção varia conforme o ponto de manutenção específico. A BleepingComputer informou que a 11.2.16 estava prevista para 15 de outubro; o advisory, atualizado nessa data, já lista a 11.2.16 como versão corrigida.

Para versões antigas e sem suporte, fora das linhas acima, a orientação do fabricante é migrar para uma versão suportada e já corrigida.

Produtos fora do escopo: Cloud NGFW e Prisma Access

Tanto o advisory da Palo Alto quanto a cobertura da BleepingComputer confirmam que Cloud NGFW e Prisma Access não são afetados por essa vulnerabilidade. Se sua operação depende exclusivamente desses produtos, a CVE-2026-0322 não se aplica. O risco está concentrado em PAN-OS rodando em firewalls PA-Series, VM-Series e em instâncias Panorama (virtual ou M-Series).

Exploração ativa: o que se sabe e o que ainda está em aberto

O fabricante confirma que “foi observada exploração muito limitada visando a interface de gerenciamento da Palo Alto Networks”, e classifica o Exploit Maturity como ATTACKED. A CISA incluiu a CVE-2026-0322 no catálogo Known Exploited Vulnerabilities (KEV) em 14 de outubro, com prazo até 17 de outubro para que agências federais civis dos Estados Unidos apliquem a correção. A entrada também marca a falha como sujeita a triagem forense: além de corrigir, as agências precisam verificar se o equipamento já foi comprometido. Vale a mesma lógica para qualquer empresa, porque atualizar um firewall já invadido não remove o que o atacante tiver deixado nele.

Três endereços IP foram associados à atividade de exploração ou a tentativas de exploit: 66.42.72[.]14, 208.83.239[.]114 e 149.248.47[.]234. Vale checar logs de acesso à interface de gerenciamento contra esses indicadores, embora o conjunto seja pequeno e não substitua a correção.

Há limites claros no que foi divulgado até agora. A Palo Alto não informou quando a exploração começou, nem quem está por trás dos ataques, nem se algum firewall comprometido foi usado como ponto de entrada para movimento lateral em redes internas. A própria BleepingComputer registra ter levantado essas perguntas ao fabricante sem resposta até a publicação da matéria. Também não há detalhes técnicos sobre a cadeia de exploração, payloads usados ou persistência instalada após o comprometimento.

Firewalls e VPNs seguem entre os alvos preferidos por ficarem na borda da rede, muitas vezes com acesso direto à internet, como mostra a campanha FortiBleed contra equipamentos Fortinet.

Como mitigar enquanto a correção não é aplicada

O advisório da Palo Alto é direto: “não existem workarounds conhecidos para esse problema”. A única correção definitiva é a atualização de versão. Dito isso, há mitigações que reduzem a superfície de ataque até que o patch seja aplicado.

Restringir acesso à interface de gerenciamento (IPs internos e jump box)

A recomendação primária do fabricante é restringir o acesso à interface de gerenciamento apenas a endereços IP internos confiáveis, seguindo as diretrizes de implantação best-practice da Palo Alto. Isso elimina o cenário de maior risco citado no próprio advisory: acesso à interface de gerenciamento a partir de IPs externos na internet.

Uma camada adicional de proteção é restringir esse acesso a uma única jump box autorizada, concentrando e auditando todas as conexões administrativas em um ponto controlado. Essa configuração muda o vetor de ataque de rede (AV:N) para rede adjacente (AV:A), reduzindo o CVSS-BT de 8.6 para 8.5. A redução é pequena em termos de nota, mas relevante em termos operacionais: dificulta o acesso de um atacante externo que não tenha presença prévia na rede interna.

Nenhuma dessas medidas substitui a atualização. Elas reduzem a janela de exposição e dificultam a exploração oportunista, mas um atacante com credenciais válidas e acesso à jump box ainda consegue explorar a falha.

Cobertura parcial via Threat Prevention (Threat ID 510046/510047) e suas limitações operacionais

Clientes com assinatura Threat Prevention podem habilitar os Threat IDs 510046 e 510047, disponíveis a partir da versão de conteúdo Applications and Threats 9159-10287. O detalhe importante, e que costuma passar despercebido, é que essa proteção só funciona sob condições específicas de arquitetura:

1. Rotear o tráfego de entrada da porta de gerenciamento (MGT) através de uma porta de dados (DP), por exemplo, habilitando um perfil de gerenciamento em uma interface DP.
2. Substituir o certificado usado para gerenciamento do tráfego de entrada.
3. Decriptar o tráfego de entrada destinado à interface de gerenciamento, para que o firewall consiga inspecioná-lo.
4. Habilitar threat prevention sobre esse tráfego de entrada para serviços de gerenciamento.

Esse conjunto de passos exige SSL Decryption configurado especificamente para o tráfego de gerenciamento. Quando a administração entra pela porta MGT, fora de banda, esse tráfego não passa pela inspeção, e a assinatura não protege nada, mesmo com a licença ativa.

O próprio fabricante é explícito sobre essa limitação: “cobertura limitada no Threat Prevention significa que, embora padrões de ataque conhecidos possam ser identificados usando o Threat ID atual, podem existir variações que não são detectadas atualmente. Se esta CVE e a configuração necessária para exposição impactam seu ambiente, recomendamos atualizar para uma versão não afetada.” Em outras palavras, mesmo para quem tem a decriptação SSL configurada no tráfego de gerenciamento, a proteção via assinatura não é um substituto confiável para o patch.

Perguntas frequentes

A CVE-2026-0322 afeta o Prisma Access ou o Cloud NGFW?
Não. Tanto o advisory da Palo Alto quanto a cobertura da BleepingComputer confirmam que esses dois produtos não são afetados. A exposição está restrita a PAN-OS rodando em PA-Series, VM-Series e Panorama.

É preciso estar sem senha ou sem autenticação para ser explorado?
Não. A exploração exige credenciais válidas (Privileges Required: HIGH) e acesso de rede à interface de gerenciamento. O risco vem do fato de que, uma vez autenticado, o atacante consegue executar código como root com baixa complexidade de ataque e sem interação do usuário.

Existe um workaround oficial além de atualizar?
Não. A Palo Alto declara explicitamente que não há workarounds conhecidos. As medidas disponíveis, restringir acesso por IP, usar jump box e habilitar os Threat IDs 510046/510047, são mitigações parciais, não substitutos da atualização.

Como saber se meu ambiente já foi alvo de tentativa de exploração?
Verifique logs de acesso à interface de gerenciamento contra os três IPs divulgados: 66.42.72[.]14, 208.83.239[.]114 e 149.248.47[.]234. Essa lista é pequena e reflete apenas a atividade observada até a publicação do advisory, não é garantia de cobertura completa.

A Palo Alto confirmou se os firewalls comprometidos foram usados para acessar outras partes da rede?
Não. Essa informação não foi divulgada pelo fabricante até a publicação do alerta, e a própria BleepingComputer registra ter perguntado isso sem obter resposta.