Em resumo: a vulnerabilidade do Laravel que muitos programadores procuram neste momento é o PHP2Shell e está no próprio PHP. Uma atualização do Laravel não a corrige. Importam um PHP com patch, o reinício de todos os processos, incluindo queue workers e Octane, e uma verificação de .env, storage e public.
O que o PHP2Shell significa para as aplicações Laravel
O Laravel é a base de muitos desenvolvimentos próprios: portais de clientes, ferramentas internas, sistemas de reservas, APIs para apps. Segundo a equipa do PHP, as vulnerabilidades PHP CVE-2026-109618 e CVE-2026-109619 permitem executar código malicioso remotamente sem autenticação. A qualidade do código Laravel é irrelevante para isso.
Estão afetados os modos de operação PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O Laravel Octane pode usar o FrankenPHP como servidor; nesse caso, o PHP está no programa FrankenPHP ou na imagem do contentor e é atualizado com ele. Como isso se passa com o FrankenPHP, descreve-o Proteger o FrankenPHP.
Vulnerabilidade Laravel: verificar a versão do PHP e os processos
Na linha de comandos, php artisan about mostra a versão do PHP, a versão do Laravel e definições importantes, como o ambiente e o modo de depuração. É, no entanto, a versão do PHP da CLI. Os pedidos web são processados pelo PHP-FPM ou pelo Octane, e pode ser outra versão. Em caso de dúvida, faça o operador confirmar que estado do pacote corre em todos os caminhos.
As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35; os backports podem ter números mais antigos. Quais as versões do PHP que a sua versão do Laravel suporta, verifique-o nos requisitos de sistema da documentação em laravel.com.
Depois da atualização vem a parte que no Laravel mais se esquece: os processos de longa duração.
# Mostrar versões e configuração
php artisan about
# Mandar os queue workers terminarem após o trabalho atual
php artisan queue:restart
# Terminar o Horizon, para que o gestor de processos o reinicie
php artisan horizon:terminate
Os workers só voltam a arrancar depois disso se um gestor de processos, como o Supervisor ou o systemd, os supervisionar. Os servidores Octane e os contentores têm de ser reiniciados por completo ou publicados com uma nova imagem. Para configurações com contentores aplica-se Aplicar patches ao PHP em contentores Docker.
Onde as aplicações Laravel são vulneráveis
| Local | Conteúdo | Ponto de verificação |
|---|---|---|
.env |
APP_KEY, base de dados, correio, chaves de API |
Nunca pode ser acessível pela web |
bootstrap/cache/config.php |
Configuração em cache com segredos | Direitos, data de alteração |
public/ |
Raiz de documentos com index.php |
Ficheiros PHP adicionais |
storage/app/public |
Uploads, acessíveis através de public/storage |
Sem ficheiros PHP |
storage/logs/ |
laravel.log, muitas vezes com dados de pedidos |
Guardar, não público |
vendor/ |
Pacotes Composer | composer audit, comparação com composer.lock |
A pasta storage/app/public é acessível através de uma ligação simbólica em public/storage. Um ficheiro PHP aí colocado pode, consoante a configuração do servidor, ser executado diretamente. Bloqueie isso ao nível do servidor web.
O APP_DEBUG tem de estar em false em produção. Uma página de erro com saída de depuração pode mostrar variáveis de ambiente, caminhos e partes do código e facilita o trabalho a qualquer atacante.
Interfaces de administração e pacotes como risco
As aplicações Laravel não têm uma interface de administração uniforme. Muitas vezes são áreas próprias ou pacotes como Filament ou Nova. Verifique quem tem direitos de admin, se o início de sessão tem um segundo fator e se as rotas de admin precisam de ser acessíveis do exterior. Também os tokens de API, por exemplo do Sanctum ou do Passport, devem ser revogados e emitidos de novo perante uma suspeita.
Verifique ainda se ferramentas de desenvolvimento estão acessíveis em produção, como barras de depuração, o Telescope ou rotas de teste. Mostram muitas vezes pedidos, consultas e configuração e devem ficar atrás de um início de sessão ou ser totalmente removidas do ambiente de produção.
Os pacotes Composer são o segundo grande bloco. Cada dependência traz código próprio, e os pacotes sem manutenção bloqueiam mais tarde as atualizações do PHP. O composer audit mostra vulnerabilidades conhecidas, mas não substitui uma verificação do código próprio.
O que uma atualização do Laravel consegue e o que não consegue
Uma atualização do Laravel ou de pacotes individuais corrige falhas conhecidas nesse código. Não aplica patch ao PHP, não reinicia workers, não renova um APP_KEY exposto e não remove ficheiros de storage ou public. Se algo aconteceu antes do patch, só se esclarece verificando registos, ficheiros e base de dados.
Para equipas com pipeline de deployment aplica-se: a atualização do PHP também tem de estar no ambiente de build e nas imagens base; caso contrário, o próximo deployment traz de novo uma versão antiga. Verifique também se os ambientes de staging ou de revisão são acessíveis publicamente. Correm muitas vezes com APP_DEBUG=true e com dados reais e são facilmente esquecidos nas atualizações de segurança.
Como ajuda concretamente a PHP SOS?
- Verificamos o PHP web, CLI e de workers da sua aplicação Laravel e acompanhamos o reinício ordenado de todos os processos.
- Guardamos registos a partir de 20/10/2026, a base de dados e o estado do código e comparamo-lo com o seu repositório.
- Verificamos
.env, a cache de configuração,storage,public, contas de admin e tokens de API. - Para uma verificação mais profunda do código próprio, intermediamos uma auditoria de segurança ou um teste de intrusão através de parceiros especializados.
Perguntas frequentes
Tenho de atualizar o Laravel por causa do PHP2Shell?
Uma atualização do Laravel não corrige o PHP2Shell, porque a falha está no interpretador PHP. Mantenha, ainda assim, o Laravel atualizado. Para o PHP2Shell precisa de um PHP com patch e do reinício de todos os processos PHP, também dos workers.
Porque é que, no Laravel, o reinício do PHP-FPM muitas vezes não chega?
Os queue workers, o Horizon, o Octane e o scheduler correm como processos PHP próprios através da linha de comandos. Carregam o PHP uma só vez, no arranque, e depois continuam a trabalhar com a versão antiga em memória até serem reiniciados.
O que fazer se o ficheiro .env puder ter sido exposto?
Nesse caso, deve renovar o APP_KEY, a palavra-passe da base de dados e todas as chaves de serviços externos. Tenha em conta que um novo APP_KEY termina as sessões existentes e torna ilegíveis os dados cifrados com a chave antiga; planeie isso com os seus programadores.