Neste artigo
- Direto ao ponto
- O que acontece antes de o Laravel receber a requisição
- Apache e Nginx podem encaminhar o Laravel de formas diferentes
- Como examinar o Octane com Swoole
- RoadRunner e FrankenPHP também exigem conferência própria
- Qual versão do PHP precisa estar no serviço
- O alcance de desativar o progresso de upload
- O que conferir depois da atualização
Você mantém uma aplicação Laravel atrás do Nginx e recebe o aviso de duas falhas críticas no PHP. Para conferir se a instalação foi corrigida, precisa descobrir qual processo executa a aplicação. O Nginx pode encaminhar as requisições ao PHP-FPM ou a um servidor iniciado pelo Octane. Cada combinação exige que você confira o PHP utilizado por esse serviço.
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 envolvem o tratamento de memória e de estado interno do interpretador. O comunicado do PHP informa que elas podem permitir execução remota de código sem autenticação. A correção precisa chegar ao PHP instalado no servidor ou incluído na imagem do container que atende sua aplicação.
Uma demonstração de exploração em Apache com mod_php confirma um caminho específico de ataque nas condições descritas pelo aviso. Para examinar o Laravel com Octane e Swoole, também é necessário entender como esse servidor recebe os uploads e administra o ciclo das requisições.
Direto ao ponto
As versões PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12 corrigem as duas falhas, CVE-2026-109618 e CVE-2026-109619, conforme o aviso oficial de segurança. Aplicações Laravel dependem da atualização do interpretador usado pelo serviço web. Os avisos descrevem exploração em mod_php e condições de exposição em PHP-FPM. Eles não apresentam uma demonstração específica contra Octane com Swoole, o que também não permite declarar essa combinação protegida. Você precisa conferir o ambiente utilizado e a correção carregada pelos processos que continuam atendendo requisições.
O que acontece antes de o Laravel receber a requisição
O servidor recebe o arquivo enviado e prepara as informações que serão entregues ao controller. Nas integrações tradicionais do PHP, o interpretador pode acompanhar o progresso do envio e registrar informações na sessão durante essa preparação. O recurso depende da configuração session.upload_progress.enabled e de um campo específico enviado na requisição. Você pode ter esse processamento habilitado mesmo sem oferecer uma barra de progresso na interface. O manual do PHP situa essa atividade na preparação da requisição, ainda sem execução dos scripts da aplicação.
Por isso, a autenticação feita pelo Laravel não corrige uma falha alcançável durante essa preparação. Um middleware só pode verificar uma requisição depois que a execução chegou ao framework. No Apache com mod_php, o comunicado oficial confirma uma exploração durante a preparação da requisição, ainda sem execução do código da aplicação. Para avaliar seu projeto, você precisa considerar esse processamento anterior às verificações das rotas.
A CVE-2026-109618 envolve uma interrupção por falta de memória. Essa interrupção pode deixar estruturas parcialmente inicializadas, utilizadas depois durante a limpeza da requisição. O uso desse estado inválido permite corrupção de memória e pode levar à execução de código pelo atacante. A falha pertence ao interpretador, portanto atualizar as dependências do Laravel pelo Composer não instala a correção do PHP.
Na CVE-2026-109619, um processo pode conservar referências à memória de uma requisição já encerrada. Outra requisição atendida pelo mesmo processo pode alcançar essas referências antes de sua reinicialização. O aviso confirma caminhos relacionados a sessões e descreve um caso em PHP-FPM que depende de uma ação da aplicação seguida de erro fatal. A configuração e o comportamento do código influenciam quais caminhos ficam acessíveis.
O Octane mantém a aplicação carregada para atender várias requisições. Essa persistência exige uma análise própria: o ciclo de uma requisição HTTP no Swoole não pode ser equiparado automaticamente ao ciclo interno descrito nos exemplos de mod_php. A comparação entre os ambientes precisa indicar o mecanismo confirmado em cada caso e o que ainda não foi demonstrado.
Uma exploração bem-sucedida executa código com as permissões do processo web. Em uma aplicação Laravel, isso poderia permitir a leitura do arquivo .env ou de credenciais disponíveis ao processo, conforme as permissões concedidas. O acesso ao banco e aos arquivos armazenados dependeria dessas credenciais e das restrições do ambiente. Essa é uma consequência possível da execução de código, sem representar um incidente confirmado contra Laravel nesta pesquisa.
Apache e Nginx podem encaminhar o Laravel de formas diferentes
O nome do servidor que recebe a conexão não identifica sozinho o PHP utilizado. No Apache com mod_php, o interpretador funciona como módulo do Apache. Em outra instalação, o mesmo Apache pode encaminhar o processamento a um serviço PHP-FPM. O Nginx também pode encaminhar as requisições ao FPM ou atuar como proxy para o Octane. Você precisa consultar a configuração do domínio para distinguir essas combinações.
O aviso da CVE-2026-109618 explica uma diferença relevante: o mod_php executa a limpeza mesmo quando a preparação da requisição falha. O FPM encerra o processo filho nessa situação. Isso elimina aquela sequência inicial no FPM, mas a análise do PHP identifica exposição após a inicialização normal. O aviso não apresenta uma exploração completa de FPM para essa CVE. Essa ressalva se refere a uma falha específica, não às duas em conjunto.
Para a CVE-2026-109619, há um caminho validado em FPM condicionado ao comportamento da aplicação. Por isso, trocar Apache por Nginx não comprova a correção do Laravel hospedado. Se ambos encaminham o tráfego ao mesmo PHP-FPM desatualizado, o interpretador permanece sem o patch. A escolha do proxy precisa ser separada da verificação do pacote PHP instalado.
Uma comparação útil para localizar a manutenção é esta:
| Ambiente que atende o Laravel | O que você precisa conferir |
|---|---|
| Apache com mod_php | O módulo PHP carregado pelo Apache e a substituição dos processos após a atualização. |
| Apache com PHP-FPM | O serviço FPM indicado na configuração do domínio, com a revisão corrigida em todos os processos. |
| Nginx com PHP-FPM | O destino FastCGI e o PHP carregado por esse serviço. Reiniciar apenas o Nginx não atualiza o FPM. |
| Nginx com Octane | O servidor escolhido pelo Octane e o interpretador utilizado por ele. |
Ao contratar hospedagem, solicite a identificação dessa combinação e do pacote corrigido usado pelo domínio. A expressão “servidor atualizado” pode descrever somente parte dos serviços. A explicação sobre hospedagem e responsabilidades de manutenção desenvolve essa diferença entre contratar recursos e contratar acompanhamento técnico.
Como examinar o Octane com Swoole
O Octane carrega o Laravel e mantém a aplicação disponível para várias requisições. Com Swoole, ele utiliza uma extensão do PHP que fornece o servidor de aplicação. A documentação também prevê Open Swoole como alternativa para fornecer esses recursos ao Octane. A revisão do interpretador continua sendo uma informação necessária para você conferir a correção.
Os avisos consultados em 21 de outubro de 2026 não apresentam uma demonstração específica contra Laravel com Octane e Swoole. Também não oferecem uma declaração de imunidade dessa combinação. A existência de processos persistentes, isoladamente, não prova que o caminho demonstrado em mod_php se repete. Seria necessário confirmar as etapas de inicialização, liberação e reutilização do estado interno naquele servidor.
Para a manutenção, identifique o executável que inicia o Octane e a extensão carregada por ele. A matriz de compatibilidade do Swoole relaciona suas séries às versões do PHP aceitas. Essa compatibilidade orienta a escolha do conjunto, mas não comprova que o interpretador instalado já contém as correções. Uma atualização isolada da extensão não substitui o patch do PHP.
Considere uma aplicação executada dentro de um container, com o Nginx em outro serviço. Atualizar o PHP do sistema hospedeiro não troca o interpretador incluído na imagem da aplicação. Você precisa disponibilizar uma imagem corrigida e substituir os containers que recebem tráfego. Se houver várias réplicas, a conferência deve alcançar todas elas, inclusive as que continuaram ativas durante a implantação.
RoadRunner e FrankenPHP também exigem conferência própria
O RoadRunner executa a aplicação em processos PHP, que recebem trabalho do servidor e devolvem as respostas. Nessa combinação, você precisa conferir o PHP iniciado como worker. Atualizar o binário do RoadRunner não demonstra que esse interpretador foi substituído. Assim como no Swoole, os avisos consultados não fornecem uma reprodução específica contra Laravel com RoadRunner.
O FrankenPHP é citado expressamente no comunicado geral do PHP. A análise da falha por falta de memória aponta uma semelhança com o mod_php no encerramento das requisições e considera provável a exposição. Isso ainda precisa ser distinguido de uma exploração demonstrada contra uma aplicação Laravel específica. O modo worker do FrankenPHP mantém a aplicação carregada, mas não elimina a obrigação de corrigir o PHP que participa dessa execução.
As imagens oficiais do FrankenPHP identificam separadamente as versões do servidor e do PHP. Ao escolher uma imagem, confira a revisão do interpretador incluído nela. Um binário que incorpora o PHP também precisa receber a atualização correspondente. O executável disponível no terminal do sistema pode ser outro e não comprova a correção daquele utilizado pelo serviço.
Essas diferenças permitem comparar o que deve ser atualizado sem atribuir proteção a uma tecnologia apenas pelo seu nome. Nos ambientes citados, a tarefa é relacionar a aplicação ao interpretador realmente utilizado e verificar a presença das duas correções. Uma mudança de arquitetura durante a emergência ainda acrescentaria testes de compatibilidade ao trabalho de atualização.
Qual versão do PHP precisa estar no serviço
O projeto publicou as correções em 21 de outubro de 2026. Você pode procurar a revisão corrigida da série já utilizada pela aplicação, respeitando os requisitos do Laravel e das extensões instaladas. A lista oficial de alterações do PHP registra as correções das duas CVEs.
| Série do PHP | Versões afetadas da série | Primeira versão corrigida para as duas CVEs |
|---|---|---|
| 8.2 | Anteriores à 8.2.35 | 8.2.35 |
| 8.3 | Anteriores à 8.3.36 | 8.3.36 |
| 8.4 | Anteriores à 8.4.27 | 8.4.27 |
| 8.5 | Anteriores à 8.5.12 | 8.5.12 |
Se o projeto utiliza PHP 8.3, por exemplo, a manutenção pode procurar um pacote 8.3.36 compatível com a instalação. Você não precisa transformar essa correção, automaticamente, em uma migração para PHP 8.5. Uma distribuição também pode fornecer um pacote com correções retroativas e outra identificação de versão. Nesse caso, confira o aviso do fornecedor que associa o pacote às duas CVEs.
O PHP disponibilizou excepcionalmente patches em código-fonte para as séries 7.4, 8.0 e 8.1. Isso não retoma o suporte regular dessas séries nem confirma a disponibilidade de um pacote na sua hospedagem. Para um Laravel antigo, você precisa examinar os requisitos do projeto e a atualização oferecida pelo fornecedor, além de planejar a migração para uma série mantida.
A versão exibida no terminal corresponde ao executável chamado naquela sessão. O PHP admite configurações diferentes conforme a interface de execução, inclusive arquivos INI próprios. Relacione o domínio ao serviço, ao executável e à configuração carregada. Faça essa conferência por acesso administrativo restrito, sem deixar uma página pública de diagnóstico expondo a configuração do servidor.
O alcance de desativar o progresso de upload
O PHP orienta desativar session.upload_progress.enabled na configuração aplicada durante a inicialização e reiniciar os workers para reduzir os caminhos conhecidos ligados a sessões. O comunicado rejeita ini_set() e .user.ini no FPM para essa finalidade, pois entram tarde no processamento. A medida não corrige todas as variantes, portanto a atualização permanece necessária.
No Laravel, um service provider executa código da aplicação quando o interpretador já preparou a requisição. A revisão precisa acontecer na configuração do serviço. O recurso nativo de progresso e o armazenamento de sessões escolhido pela aplicação precisam ser examinados separadamente. Usar Redis para as sessões do Laravel não comprova que o recurso nativo do PHP esteja desativado.
A recomendação temporária precisa ser aplicada ao ambiente que você identificou, com conferência do valor carregado após o reinício. Alterar um arquivo no host não modifica automaticamente o INI de um container. Depois da mudança, teste um envio legítimo e observe se a interface dependia daquele acompanhamento de progresso. Esse teste verifica o funcionamento do recurso, sem substituir a comprovação do patch.
Para uma manutenção acompanhada ao vivo, o Desenvolvimento Colaborativo da Dev Side Studio oferece orientação técnica durante a investigação e a execução. Esse formato pode servir à conferência do ambiente e à substituição do serviço que executa o Laravel.
O que conferir depois da atualização
Eu recomendo ensaiar a substituição do pacote ou da imagem em um ambiente isolado, com uma forma de recuperação compreendida. Você pode verificar a compatibilidade das extensões e executar os testes da aplicação nesse ambiente. Essa preparação acompanha a aplicação urgente da correção e permite verificar a compatibilidade sem usar o servidor do cliente como ambiente de teste. Ao concluir o ensaio, minha recomendação é registrar como recuperar o serviço caso a substituição falhe.
No Octane, a documentação diferencia a recarga dos workers do encerramento do servidor. A recarga costuma servir à entrada de mudanças no código da aplicação. Para substituir o interpretador ou uma biblioteca já carregada, confira que o procedimento encerrou os processos antigos e iniciou o serviço com o artefato corrigido. Em Swoole, um processo principal antigo pode originar novos workers sem ter carregado um PHP novo.
Esse cuidado com processos ativos também aparece na manutenção do OpenSSH no Debian. Cada serviço tem seu procedimento próprio de reinício. Para o Laravel, registre qual serviço foi substituído e confira a versão carregada em cada réplica, além do pacote presente no disco.
Depois, teste o login e um envio legítimo de arquivo. Confira também uma rota autenticada e as tarefas em segundo plano que utilizam a mesma imagem PHP. Um job de fila não recebe necessariamente o mesmo tráfego HTTP do serviço web, portanto compartilhar a versão não demonstra um vetor idêntico. Ainda assim, você precisa saber quais serviços receberam a imagem nova e se continuam funcionando.
Ao concluir a manutenção, mantenha registrados a revisão corrigida do PHP, o serviço reiniciado e o resultado dos testes de login e upload. A conferência deve mostrar que todas as réplicas atendem com o interpretador atualizado. Para estudar a relação entre processos, containers e redes utilizada nessa manutenção, você pode continuar pela Formação DevOps.
