Neste artigo
- Direto ao ponto
- O acesso ao PHP pode ocorrer sem login
- O que acontece nas duas falhas do PHP
- Quais versões do PHP corrigem as falhas
- Mautic 4 exige conferir a compatibilidade antes de atualizar
- Laravel com Swoole está vulnerável?
- Como verificar a exposição sem executar um ataque
- Atualização dos processos e teste da aplicação
Um atacante pode executar código no seu servidor sem conhecer a senha da aplicação. Os avisos de segurança do PHP descrevem esse tipo de exploração nas duas falhas corrigidas em 21 de outubro de 2026. Parte dos caminhos conhecidos começa enquanto o PHP processa a requisição, antes de executar o código que verifica o login. Por isso, manter o painel protegido por senha não basta para considerar a instalação segura. Comunicado oficial do PHP.
Você pode ser a única pessoa com acesso ao painel do Mautic e ainda receber conexões externas pelos formulários das campanhas. Uma aplicação Laravel sem cadastro público também pode atender requisições de visitantes anônimos. Para conferir a exposição, comece pelo serviço que recebe essas conexões e pela versão do PHP que ele executa. Os avisos descrevem condições diferentes conforme o servidor, então o nome da aplicação, sozinho, não permite concluir se a instalação está protegida.
Direto ao ponto
As correções estão no PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. A atualização precisa alcançar o interpretador utilizado pelo serviço web. Pacotes de distribuições podem incorporar as mesmas correções por backport, por isso a revisão completa do fornecedor também precisa ser conferida. Releases oficiais do PHP.
Uma aplicação acessível apenas por rede privada tem exposição diferente de um painel com login público. O isolamento reduz os acessos que chegam ao serviço, mas mantém a necessidade de corrigir o PHP. Para aplicações antigas, como Mautic 4, a manutenção também precisa respeitar a compatibilidade da aplicação com a versão escolhida.
O acesso ao PHP pode ocorrer sem login
O Mautic distingue os acessos ao painel das interações dos contatos. Um formulário incorporado no seu site pode enviar cadastros ao Mautic sem que o visitante tenha acesso administrativo. O pixel de rastreamento também recebe requisições externas. Essas funções estão documentadas para o Mautic 4 e explicam por que uma instalação de uso administrativo privado pode continuar atendendo a internet.
A autenticação feita no próprio sistema ocorre durante a execução da aplicação. Alguns caminhos das falhas do PHP envolvem o processamento anterior a essa execução. Por essa razão, apresentar uma tela de login não comprova que a requisição foi recusada a tempo. A análise do estado global do PHP descreve condições diferentes conforme o servidor. Uma rota pública permite alcançar o serviço, mas não comprova, isoladamente, que aquela rota seja explorável.
Uma restrição aplicada na rede ou no proxy pode recusar a conexão sem encaminhá-la ao PHP. Para essa separação funcionar, o servidor de origem também precisa recusar acessos diretos. Uma exceção para formulários mantém essas rotas acessíveis. A aplicação dessa proteção no domínio inteiro pode interromper formulários e rastreamento, então a manutenção precisa considerar as campanhas que utilizam esses recursos. O Nginx documenta a restrição por endereço e a autenticação no servidor.
Num serviço realmente disponível apenas pela rede privada, um atacante externo sem caminho até essa rede não consegue enviar diretamente as requisições descritas. O PHP vulnerável continua instalado e pode ser alcançado por clientes autorizados ou por um sistema interno comprometido. Essa conclusão decorre da arquitetura de acesso. A confirmação da correção exige conferir o pacote e os processos utilizados pela aplicação.
O que acontece nas duas falhas do PHP
Na CVE-2026-109618, uma falha de alocação de memória pode interromper a requisição enquanto estruturas internas estão parcialmente inicializadas. A limpeza posterior acessa esse estado inválido. O relatório oficial demonstra execução remota em Apache com mod_php e descreve exposição no FPM após a inicialização normal, sem apresentar uma exploração completa desse segundo ambiente para essa CVE. O patch modifica o tratamento da falta de memória para evitar o abandono inseguro da execução. Fonte: aviso de corrupção por falta de memória.
A CVE-2026-109619 envolve referências internas que continuam no worker depois que a memória de uma requisição foi liberada. Outra requisição atendida pelo mesmo processo pode acessar essa memória, num acesso chamado de use-after-free. A correção reinicializa o estado afetado e o aviso confirma execução remota no caminho de sessões tanto em mod_php quanto em FPM. Fonte: aviso sobre estado global.
O recurso de progresso de upload participa de caminhos conhecidos dessas falhas. O PHP pode registrar o andamento do envio na sessão durante o processamento inicial da requisição, antes de executar o script da aplicação. Por isso, a ausência de uma barra de progresso na interface não demonstra que o recurso está desativado. O comportamento está documentado no manual de Session Upload Progress.
Atualizar dependências pelo Composer não instala essas correções no interpretador. O pacote do PHP utilizado pelo serviço precisa receber o patch, mesmo que as dependências da aplicação estejam atualizadas.
Quais versões do PHP corrigem as falhas
Para instalações que seguem as releases do projeto PHP, estas são as primeiras revisões corrigidas de cada série. Uma revisão posterior da mesma série também deve ser considerada conforme os anúncios de segurança publicados depois desta consulta.
| Série do PHP | Primeira revisão corrigida |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
A tabela segue os anúncios oficiais de 21 de outubro de 2026. Ela permite corrigir a série já utilizada, sem exigir uma migração imediata para PHP 8.5. A escolha de outra série precisa considerar os requisitos da aplicação e de suas extensões.
O número do pacote Ubuntu pode ser diferente
O Ubuntu publicou o aviso USN-8948-1, que corrige as duas CVEs nos pacotes abaixo. Esses números completos valem para os pacotes oficiais das respectivas versões do Ubuntu, não para qualquer instalação com o mesmo prefixo de PHP.
| Ubuntu | Revisão do pacote corrigido |
|---|---|
| 22.04 LTS | 8.1.2-1ubuntu2.28 |
| 24.04 LTS | 8.3.6-0ubuntu0.24.04.13 |
| 26.04 LTS | 8.5.4-0ubuntu1.5 |
| 26.10 | 8.5.9-0ubuntu2.1 |
Esse é o efeito do backport: o fornecedor incorpora a correção numa base anterior. Um pacote 8.3.6-0ubuntu0.24.04.13 pode estar corrigido apesar de o projeto PHP ter publicado a correção upstream em 8.3.36. Compare a revisão completa, a origem do pacote e o aviso de segurança correspondente.
O projeto PHP também disponibilizou, excepcionalmente, patches mínimos para as séries 7.4, 8.0 e 8.1. Isso não equivale a novas releases regulares nem à retomada do suporte dessas séries. Nessas séries, confirme com o fornecedor qual pacote incorpora as duas correções. O comunicado do PHP distingue esses backports das releases mantidas.
Mautic 4 exige conferir a compatibilidade antes de atualizar
Um Mautic sem cadastro público de usuários pode continuar exposto pelas funções de marketing. A documentação permite incorporar formulários em outros sites e registrar interações de contatos sem login administrativo. Portanto, você precisa verificar o domínio que recebe essas chamadas, mesmo que somente você utilize o painel. A documentação de formulários do Mautic 4 descreve esse uso.
A versão da aplicação também limita a troca do interpretador. Os requisitos oficiais relacionam Mautic 4.0 ao PHP 7.4 e Mautic 4.4 ao PHP 7.4 ou 8.0. Instalar PHP 8.5.12 diretamente nessa aplicação não é uma atualização compatível documentada. Você precisa obter um pacote corrigido da série aceita ou preparar a migração do Mautic com testes das integrações e dos plugins.
O suporte regular de segurança do Mautic 4 terminou em 31 de dezembro de 2024. O programa pago de suporte estendido listado até 31 de dezembro de 2026 cobre o Mautic, com exclusão expressa de dependências fora de suporte, como PHP e Symfony. Ter esse contrato não comprova que o interpretador recebeu o patch. Essas condições constam na página oficial de releases.
Os avisos consultados não apresentam uma demonstração específica contra Mautic 4. Eles descrevem falhas no PHP e condições de exploração conforme o servidor. Essa diferença impede afirmar que toda instalação do Mautic seja explorável, mas também impede considerar o login do painel uma proteção suficiente. Para a sua instalação, a resposta depende do acesso ao serviço e da revisão efetivamente instalada.
Laravel com Swoole está vulnerável?
Os avisos oficiais não demonstram exploração específica de Laravel com Octane e Swoole nem certificam a imunidade dessa combinação. A demonstração em PHP-FPM não pode ser transferida automaticamente para o ciclo de execução do Swoole. A orientação de atualizar o PHP permanece aplicável quando o interpretador instalado contém o código afetado.
O Octane aceita Swoole e OpenSwoole, além de servidores como FrankenPHP e RoadRunner. Confira o comando utilizado para iniciar a aplicação e o destino configurado no proxy. O pacote Octane no projeto não identifica sozinho o servidor de produção. A documentação do Laravel explica essas alternativas e a persistência dos processos.
Outro domínio ou uma configuração auxiliar pode encaminhar requisições para FPM no mesmo ambiente. Nessa situação, avaliar somente o serviço Swoole deixa um caminho de acesso sem conferência. O diagnóstico deve acompanhar cada destino utilizado pelo proxy.
Para o Swoole, a matriz de suporte e as releases estáveis consultadas indicam estas combinações:
| Série do Swoole | Release estável consultada | Faixa de PHP compatível |
|---|---|---|
| 6.1 | 6.1.10 | 8.1 a 8.4 |
| 6.2 | 6.2.3 | 8.2 a 8.5 |
Assim, PHP 8.4.27 com Swoole 6.1.10 está dentro da faixa documentada. PHP 8.5.12 exige uma série compatível com 8.5, como Swoole 6.2, cuja release estável consultada é 6.2.3. São combinações de compatibilidade declarada, não testes realizados na sua aplicação. Essas releases do Swoole também não substituem as correções do PHP.
Como as falhas do PHP se relacionam com Octane e OpenSwoole
No Octane com OpenSwoole, você mantém a aplicação carregada num processo PHP que atende várias requisições. O OpenSwoole recebe o tráfego HTTP e entrega um objeto de requisição ao callback do servidor. O Octane encaminha esse objeto à aplicação Laravel. Esse funcionamento aparece na documentação do OpenSwoole e no código do servidor utilizado pelo Octane.
Essa diferença de processamento impede concluir que um ataque demonstrado no FPM funcione do mesmo modo no OpenSwoole. A CVE-2026-109619 exige uma sequência específica: uma interrupção deixa referências internas para memória liberada e uma operação posterior acessa essas referências. No caminho de sessões validado pelo PHP, o progresso de upload participa dessa sequência. Manter workers ativos entre requisições não comprova que o OpenSwoole execute as operações necessárias para reproduzir a falha. O aviso técnico detalha as condições confirmadas em mod_php e FPM.
A CVE-2026-109618 envolve a interrupção por falta de memória com estruturas internas ainda incompletas. O relatório dessa falha também não demonstra exploração específica no Octane com OpenSwoole. Nos documentos consultados em 21 de outubro de 2026, não há comprovação de execução remota nessa combinação nem declaração de imunidade. A diferença de arquitetura explica por que a exposição precisa de análise própria, mas não substitui a correção do PHP.
Na sua instalação, confira se o proxy envia o domínio ao Octane ou se alguma rota ainda utiliza PHP-FPM. Atualizar apenas o pacote do Octane pelo Composer ou a extensão OpenSwoole mantém o interpretador antigo quando a implantação não substitui o PHP. Depois de instalar uma revisão corrigida, substitua o processo principal e os workers do serviço. Uma recarga do código Laravel não comprova essa troca.
O OpenSwoole tem versões próprias, por isso você precisa consultar sua compatibilidade separadamente da tabela do Swoole. O OpenSwoole 26.2.0 declara suporte ao PHP 8.5, mas esse suporte indica compatibilidade, não uma correção destas CVEs na extensão. Para usar essa série do PHP, a primeira revisão corrigida é 8.5.12. A aplicação e as demais extensões também precisam aceitar a combinação escolhida.
Como verificar a exposição sem executar um ataque
Comece pela identificação do executável e da configuração dentro do ambiente da aplicação. Num container, faça a consulta dentro dele com o mesmo executável configurado para iniciar o serviço. php -v informa a versão, php --ini lista os arquivos de configuração e php --ri swoole mostra a versão e a configuração da extensão quando ela está carregada. Para OpenSwoole, use php --ri openswoole no mesmo ambiente do serviço.
A documentação das opções de linha de comando do PHP descreve a saída de cada uma. Uma extensão ausente nesse terminal pode indicar outro executável ou outra configuração, por isso você ainda precisa comparar o resultado com a inicialização do serviço.
Esses comandos iniciam um processo novo. Eles não demonstram, sozinhos, qual versão um processo antigo continua executando. Para concluir a conferência, relacione a revisão instalada ao reinício do serviço e verifique um diagnóstico interno do runtime em cada réplica. Evite publicar phpinfo() numa rota aberta, pois essa página expõe detalhes da configuração.
Nos logs, procure falhas de memória e erros fatais próximos de requisições incomuns. Examine também os registros de tempo máximo de execução excedido. O aviso técnico alerta que a ausência de erros não comprova segurança. Esses registros justificam investigação, mas um erro fatal isolado também pode resultar de um defeito comum da aplicação. Fonte: orientações de auditoria do PHP.
Se houver suspeita de execução indevida, preserve os registros do proxy e do serviço antes de substituí-los durante a manutenção. Correlacione horários e alterações inesperadas com os acessos recebidos. A investigação de um incidente exige esse histórico, enquanto a confirmação do patch depende do pacote e dos processos implantados. Não é necessário executar uma prova de exploração em produção para identificar uma revisão sem correção.
Atualização dos processos e teste da aplicação
Para um serviço com Octane, planeje a substituição do processo principal e dos workers pelo gerenciador utilizado na implantação. Uma recarga destinada apenas ao código da aplicação não deve ser tomada como comprovação de que o executável PHP foi substituído. Em containers, a nova imagem precisa conter o pacote corrigido e substituir todas as réplicas antigas.
A reconstrução também precisa verificar a imagem-base utilizada. Repetir o build com uma base antiga pode reproduzir o mesmo PHP vulnerável. Registre o identificador da imagem implantada e confira a versão dentro dela. Depois acompanhe a retirada dos processos anteriores do tráfego.
No teste funcional, faça login, envie um arquivo permitido e execute uma operação representativa da aplicação. Observe os logs durante essas ações e confira se a extensão utilizada, Swoole ou OpenSwoole, carregou corretamente. Os testes apresentados na leitura sobre revisão de aplicações Laravel complementam essa conferência funcional. Eles não substituem a comprovação da revisão corrigida do interpretador.
Como medida temporária, o PHP orienta desativar session.upload_progress.enabled na configuração aplicada durante a inicialização e reiniciar todos os workers. Essa medida reduz caminhos conhecidos, mas não corrige as duas falhas por completo. O aviso também rejeita ini_set() e .user.ini no FPM para essa mitigação, pois são aplicados tarde demais no processamento da requisição. Fonte: orientação oficial de mitigação.
Ao encerrar a manutenção, registre a revisão do PHP e a imagem utilizada por cada réplica, junto do resultado dos testes funcionais. Compare esse registro com a imagem escolhida para um rollback antes de recolocá-la no tráfego. A relação entre aplicação, servidor e container também é desenvolvida no artigo sobre infraestrutura para aplicações.
Para estudar a administração dos serviços e dos containers, a Formação DevOps oferece uma continuidade relacionada a essa manutenção. Quando você precisa de acompanhamento técnico para executar e conferir a mudança no seu projeto, conheça o Desenvolvimento Colaborativo da Dev Side Studio.
