PHP2Shell e o risco para NAS, firewall e containers

Pense em quem tem um NAS QNAP no escritório de casa, com acesso remoto aberto para buscar arquivos quando está na rua. Em 23 de outubro de 2026, esse dono precisa saber de três coisas: o aparelho tem PHP em alguma parte do sistema, existe uma falha crítica de execução de código sem login e a QNAP ainda não tem correção pronta.

É esse o cenário do PHP2Shell. E ele vale para bem mais gente do que quem mantém um site.

O que é o PHP2Shell

PHP2Shell é o nome dado a duas falhas no PHP, a linguagem que roda boa parte dos sites e painéis web: CVE-2026-109618 e CVE-2026-109619. Ambas receberam nota 9.2 no CVSS 4.0, o sistema usado para medir a gravidade de vulnerabilidades.

As duas permitem execução remota de código sem autenticação. Traduzindo: alguém de fora consegue mandar o equipamento rodar comandos dele, sem usuário nem senha. Como não exige login, a falha pode ser explorada antes de qualquer tela de acesso aparecer, e é por isso que serviços abertos para a internet são os mais expostos.

Por que atinge mais do que sites

O PHP costuma morar onde ninguém pensa nele como "aplicativo PHP". A interface web de um NAS, o painel de um firewall, um container Nextcloud rodando em Docker, um Pi-hole antigo: todos podem ter PHP lá dentro.

O risco cresce porque muita gente deixa esses serviços acessíveis pela internet, com redirecionamento de portas no roteador para alcançar os arquivos de fora. Quem está exposto fica na linha de tiro.

Quem já está protegido e quem não está

As correções estão nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 do PHP. O PHP 8.1 e as anteriores não recebem correção do projeto.

QNAP: ainda sem correção. O status é "Fixing" e não há prazo. Entre os afetados estão QTS 5.2.11 e anteriores, QTS 6.1.0, QuTS hero, QuTScloud e Note Station 3. Download Station e PHP Extensions não terão correção porque o suporte acabou em 30 de setembro; a recomendação é fazer backup das tarefas de download e desinstalar os dois. A atualização futura também não cobre o PHP dentro de containers do Container Station.

Synology: já há atualizações no Centro de Pacotes para os pacotes PHP, o Mail Station e o Synology Calendar, exceto o PHP 7.3, que chegou ao fim da vida. Se o Web Station ainda usa um perfil com PHP 7.3, troque por uma versão suportada ou remova o pacote. A Synology afirma que o PHP embutido no DSM não fica exposto a ataques externos e considera o risco ali muito baixo.

OPNsense e pfSense: já protegidos. O OPNsense recebeu hotfix na noite de quarta-feira (21). No pfSense, a atualização precisa ser instalada por SSH ou console, porque a interface web não consegue aplicá-la. Se a interface estiver exposta à internet, atualize já. Se você manteve o padrão (acesso só pela rede local), dá para atualizar com calma.

Containers: as imagens oficiais de PHP, Nextcloud, WordPress, phpMyAdmin, Joomla e Matomo já foram refeitas no Docker Hub. Mas imagem nova não protege container antigo: é preciso recriá-lo. Com Docker Compose, isso é docker compose pull seguido de docker compose up -d. Para conferir a versão em uso, rode php -v dentro do container.

Pi-hole: os desenvolvedores dizem que a versão 6 não precisa mais de PHP. Se você ainda está na 5, é um bom motivo para atualizar.

Qual é o risco real hoje

Há tentativas de exploração desde a quarta-feira (21), mas sem comprometimentos confirmados até agora. Também não há relatos de ataques a aparelhos QNAP.

Isso não é motivo para relaxar. O volume de tentativas saiu de algumas centenas para milhões, e a expectativa da comunidade de segurança é que invadir seja questão de tempo. Por que quase todas falharam ainda está em análise. Alguns pesquisadores levantam a hipótese de que a execução do código precise driblar uma proteção de memória chamada ASLR, difícil de contornar à distância, mas isso não está confirmado.

O que fazer na prática

1. Atualize o que já tem correção: pacotes da Synology, firewall, containers e o PHP do seu sistema. Depois, reinicie os serviços que usam PHP.
2. Tire o NAS da exposição pública: desligue o redirecionamento de portas no roteador e o UPnP.
3. Use VPN para acesso remoto, em vez de abrir as portas de gerenciamento.
4. Se tem QNAP afetado, desconecte o aparelho da internet até sair a correção. No QuFirewall, limite as portas 8080 e 443 à rede local. Se não usa o servidor web embutido, desligue-o no Painel de Controle.
5. Aparelhos sem suporte devem ficar acessíveis só localmente.

Circulam ajustes no php.ini como paliativo. O próprio projeto PHP diz que nenhum deles é correção completa: um deles reduz o risco de apenas uma das duas falhas, e para a CVE-2026-109619 não há ajuste genérico de configuração. Não conte com isso no lugar da atualização.

Por que o calendário apertou

As correções estavam planejadas para uma divulgação coordenada, com tempo para sites e fabricantes se prepararem. A informação vazou antes: um usuário do Hacker News publicou os números das falhas e depois pediu desculpas, dizendo que não sabia do embargo. Ele não foi o único. Outros vazamentos circularam em redes sociais, e a Chainguard liberou sua correção mais de seis horas antes do combinado. O PHP acabou antecipando o anúncio em um dia.

O resultado é que muita gente teve menos tempo de preparo, e fabricantes como a QNAP ainda não têm o conserto pronto.

De volta ao escritório

O NAS do escritório continua ligado na tomada, guardando seus arquivos. Só que agora está fora do alcance da internet, com o acesso remoto trocado por VPN, esperando a atualização da QNAP chegar.