Vulnerabilidade crítica no PHP (php2shell): se você expõe PHP por túnel, atualize

O que foi divulgado

Em 21 de outubro de 2026 o projeto PHP publicou um aviso de segurança sobre duas vulnerabilidades no núcleo da linguagem: CVE-2026-109618 e CVE-2026-109619, ambas com nota 9,2 (CVSS v4.0). Os fornecedores apelidaram a dupla de php2shell.

As duas permitem execução remota de código sem autenticação, com os privilégios do processo do servidor web. Em outras palavras: o atacante não precisa de login, senha nem sessão válida — alcançar o seu PHP já basta.

Toda versão de 5.4 até 8.5.11 está afetada. As correções são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. PHP 8.1 e anteriores não recebem correção do projeto.

Por que isso importa para quem usa o SuperDMZ

Vamos ser diretos nisso, porque é a parte que nos diz respeito. O túnel não cria a vulnerabilidade — ela já estava no seu PHP. O que o túnel faz é acabar com a obscuridade que protegia aquela máquina. Uma aplicação que antes só respondia na sua rede local passa a responder num endereço público, e varredura automatizada encontra endereço público em questão de minutos.

Hoje 141 dos 165 túneis ativos da plataforma estão em modo público — 55 de 67 túneis HTTP e 86 de 98 TCP. É uma escolha legítima, e muita gente quer exatamente isso. É também o motivo de este aviso existir.

Como conferir o que você roda

php -v

Uma ressalva importante que a maioria dos avisos deixa de fora: em Debian, Ubuntu e derivados, o número da versão não muda quando a distribuição aplica o patch. O nosso próprio servidor web informa PHP 8.5.4 e já está corrigido, porque a correção veio na revisão do pacote (8.5.4-0ubuntu1.5), não numa versão nova do PHP. Então nesses sistemas não julgue pelo php -v. Pergunte ao gerenciador de pacotes:

apt list --upgradable | grep php
apt-get changelog php8.3-common | head

Se o changelog citar CVE-2026-109618, aquele pacote é a correção. No Windows, no macOS, em imagem Docker ou PHP compilado do código-fonte, aí o número da versão é o sinal certo — compare com as quatro versões corrigidas acima.

Se você não puder atualizar hoje

Aqui vai algo que podemos oferecer e um aviso genérico não: mude seu túnel para o modo autenticado. No painel, no túnel, troque o modo de acesso de público para autenticado. O endereço passa a exigir uma chave antes de qualquer tráfego chegar à sua máquina, o que tira o seu PHP do alcance da varredura não direcionada enquanto você agenda a atualização.

É medida temporária, não é correção. A falha continua na sua máquina, e quem tiver a chave continua alcançando. Mas ela te dá a janela.

O que fizemos do nosso lado

A nossa própria infraestrutura estava afetada e já foi atualizada:

• Painel do SuperDMZ — PHP atualizado e serviço reiniciado em 21 de outubro.
• Servidor web (sites e ferramentas) — atualizado no mesmo dia.
• Nodes dos túneis — não afetados: rodam Go, sem PHP.
• Servidor de e-mail — imagem do contêiner trocada pela versão com o PHP corrigido.

Também criamos um check diário no nosso monitoramento de operação que lê o registro oficial de vulnerabilidades e o canal de segurança de cada distribuição que usamos, para que o próximo caso não dependa de alguém notar um e-mail. Esse aprendemos na prática: soubemos do php2shell porque um fornecedor nos escreveu.

Fontes oficiais

Não acredite em nós quanto aos detalhes técnicos — e não clique em links de e-mail sobre segurança. Digite o endereço você mesmo:

• php.net/archive/2026.php — o aviso do próprio projeto e os anúncios das versões.
• nvd.nist.gov — busque por CVE-2026-109618 e CVE-2026-109619.

Se tiver dúvida sobre o seu caso específico, responda pelo canal de suporte do painel. Nós não pedimos senha nem mandamos link para você clicar.