# Segurança Symfony após o PHP2Shell: proteger projetos e workers > Proteger projetos Symfony após o PHP2Shell: verificar o PHP com bin/console about, reiniciar workers do Messenger e controlar secrets, cache e profiler. Fonte: https://phpsos.de/pt/plattformen/symfony/ Atualizado em: 25/10/2026 Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6 **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. ```bash # 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. > **Importante:** > 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](https://phpsos.de/pt/ratgeber/composer-abhaengigkeiten-pruefen/). 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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/). 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](https://phpsos.de/pt/php2shell/docker-container-patchen/). ## 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](https://phpsos.de/pt/leistungen/security-monitoring/). ## 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. ## Fontes - [php.net: avisos de segurança](https://www.php.net/) - [Symfony](https://symfony.com/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [Versões do PHP suportadas](https://www.php.net/supported-versions.php)