Em resumo: segurança Symfony após o PHP2Shell significa: aplicar o patch ao PHP, reiniciar todos os processos, incluindo os workers do Messenger, e depois verificar secrets, cache e profiler. A vulnerabilidade está no PHP, não no Symfony; uma atualização do Symfony, por si só, não a corrige.
Porque é que o PHP2Shell afeta todos os projetos Symfony
O Symfony é a base de muitas aplicações empresariais, APIs e portais e está, além disso, presente em sistemas como o Shopware 6 e o Contao. Segundo a equipa do PHP, as vulnerabilidades PHP CVE-2026-109618 e CVE-2026-109619 permitem executar código malicioso sem autenticação. Se a aplicação está bem programada é irrelevante para isso.
A equipa do PHP classifica o risco como o mais elevado no mod_php, mas também estão afetados o PHP-FPM, o php-cgi, o FrankenPHP e o LiteSpeed. Os projetos Symfony operados através do Symfony Runtime com FrankenPHP ou outros servidores de execução permanente precisam, depois da atualização, de um reinício completo ou de uma nova imagem.
Segurança Symfony: verificar a versão do PHP e os processos
O php bin/console about mostra a versão do Symfony, o ambiente, o modo de depuração e a versão do PHP da linha de comandos. Os pedidos web, porém, correm pelo PHP-FPM ou por um servidor de aplicações, e pode ser outra versão. Verifique ambos os caminhos ou faça o operador confirmá-los.
As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35; os backports das distribuições têm muitas vezes números mais antigos. Quais as versões do PHP que a sua versão do Symfony suporta, verifique-o nos requisitos de sistema da documentação em symfony.com.
# Mostrar ambiente, modo de depuração e versão do PHP
php bin/console about
# Mandar os workers do Messenger terminarem após a mensagem atual
php bin/console messenger:stop-workers
# Vulnerabilidades conhecidas nas dependências
composer audit
Se várias instâncias correrem atrás de um balanceador de carga ou em contentores, cada uma delas tem de ter o patch aplicado e estar reiniciada. Uma instância esquecida continua a servir parte dos pedidos com o PHP antigo.
Os workers do Messenger, os comandos cron e outros processos em segundo plano carregam o PHP uma só vez, no arranque. Até serem reiniciados, correm com o PHP antigo em memória. Um gestor de processos tem de os voltar a pôr a funcionar depois da paragem.
Onde as aplicações Symfony são vulneráveis
| Local | Conteúdo | Ponto de verificação |
|---|---|---|
.env, .env.local, .env.local.php |
Variáveis de ambiente, muitas vezes base de dados e chaves de API | Não acessíveis na raiz web, renovar valores em caso de suspeita |
config/secrets/prod/ |
Secrets encriptados | A chave privada de desencriptação não pertence ao repositório |
public/ |
Raiz de documentos com index.php |
Ficheiros PHP adicionais |
var/cache/prod/ |
Contentor e templates gerados como PHP | Apagar e regenerar em caso de suspeita |
var/log/ |
Registos | Guardar |
config/packages/security.yaml |
Firewalls, funções, regras de acesso | Alterações inesperadas |
A cache é um esconderijo subestimado. O Symfony gera aí ficheiros PHP que são carregados a cada pedido. Uma alteração a estes ficheiros não se nota no repositório, porque a cache não está sob controlo de versões.
Em produção devem estar APP_ENV=prod e APP_DEBUG=0, e o WebProfilerBundle não pode estar ativo. Um profiler acessível publicamente em /_profiler revela configuração e dados de pedidos.
Áreas de administração, bundles e dependências
Os projetos Symfony têm, consoante a estrutura, áreas de administração próprias, muitas vezes com bundles como o EasyAdmin ou o Sonata. Verifique em security.yaml que caminhos exigem que funções e, na base de dados, quem tem essas funções. Os caminhos de admin que só são necessários internamente devem estar restringidos a redes conhecidas ao nível do servidor web.
Os bundles e os pacotes Composer são código alheio com falhas próprias. O composer audit mostra problemas conhecidos; mais pormenores em Verificar vulnerabilidades nas dependências do Composer. Os pacotes desatualizados são, além disso, a razão mais frequente por que uma atualização do PHP demora mais do que o planeado em projetos Symfony.
O que uma atualização do Symfony faz e o que não faz
Uma atualização dos componentes do Symfony corrige falhas na framework. Não aplica patch ao PHP, não reinicia workers, não renova secrets expostos e não remove uma cache manipulada. Se existem indícios de um ataque, descreve-o Já fui comprometido?. Como não existem indicadores de comprometimento (IoC) confirmados, ajuda sobretudo observar comportamento invulgar, por exemplo processos inesperados ou ligações de saída.
Se o projeto for entregue como contentor, o novo PHP pertence à imagem base. Reconstrua a imagem, mesmo que o código não tenha mudado, e distribua-a por todos os ambientes. Uma vista de olhos ao Dockerfile mostra que imagem base é usada; uma tag antiga fixada impede, de outro modo, que a reconstrução receba sequer o PHP com patch. Os pormenores estão em Aplicar patches ao PHP em contentores Docker.
Como ajuda concretamente a PHP SOS?
- Apuramos que PHP usam o web, a CLI e os workers do seu projeto Symfony e acompanhamos o reinício ordenado.
- Guardamos registos a partir de 20/10/2026 e comparamos o código no servidor com o seu repositório.
- Verificamos ficheiros de ambiente, secrets, cache, definições do profiler e funções de admin.
- Para a observação contínua de processos e ligações, oferecemos monitorização de segurança.
Perguntas frequentes
O Symfony é afetado pelo PHP2Shell?
O Symfony em si não tem uma nova vulnerabilidade. O PHP2Shell está no PHP, ou seja, no ambiente de execução de qualquer aplicação Symfony. A falha é corrigida por uma atualização do PHP ou por um backport confirmado e pelo reinício de todos os processos PHP.
Como paro os workers do Messenger após uma atualização do PHP?
Com php bin/console messenger:stop-workers, os workers em execução são instruídos a terminar após a mensagem atual. Um gestor de processos, como o Supervisor ou o systemd, volta então a iniciá-los com o novo PHP.
Porque é o profiler do Symfony perigoso em produção?
O profiler mostra pedidos, configuração e, muitas vezes, variáveis de ambiente. Se estiver ativo num servidor público, qualquer pessoa pode aceder a essas informações. Pertence apenas ao ambiente de desenvolvimento.
O que acontece à cache depois de um ataque?
A cache em var/cache contém código PHP gerado. Um atacante pode aí depositar código que corre a cada pedido. Perante uma suspeita, a cache deve ser apagada e regenerada a partir do código-fonte verificado.