Falha crítica no PHP (PHP2Shell): como corrigir no Ubuntu

Em 21 de outubro de 2026, o projeto PHP lançou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Elas corrigem duas falhas críticas, a CVE-2026-109618 e a CVE-2026-109619. As duas receberam nota 9.2 no CVSS v4.0 e permitem execução remota de código, ou seja, um atacante pode rodar comandos no servidor. Os pesquisadores chamaram o par de falhas de PHP2Shell. Se você mantém algum servidor com PHP, a correção é uma só: atualizar o PHP e reiniciar os serviços que o usam. Neste artigo você entende o que são as falhas, quem é afetado e vê um passo a passo completo para um servidor Ubuntu com Apache ou Nginx.

O que aconteceu

Em 20 de outubro, a equipe de segurança do PHP publicou um aviso antecipado: haveria uma versão de emergência no dia seguinte, às 14:00 UTC (11:00 no horário de Brasília), para corrigir duas vulnerabilidades críticas. A equipe também disse que poderia antecipar o lançamento se os detalhes vazassem ou se aparecessem sinais de exploração. No mesmo dia, o CERT-EU publicou um alerta, e o National Cyber Security Centre, do Reino Unido, também avisou sobre o problema.

No dia 21, as versões corrigidas saíram, e as distribuições Linux, que tinham recebido as correções com antecedência, publicaram pacotes atualizados. A Ubuntu, por exemplo, lançou o aviso de segurança USN-8948-1.

As duas falhas, em linguagem simples

CVE-2026-109618: corrupção de memória quando falta memória

Quando uma requisição faz o PHP atingir o limite de memória, o processamento pode ser interrompido enquanto os dados internos da requisição ainda estão pela metade. Depois, na limpeza da requisição, o PHP trata esses dados incompletos como se fossem válidos. Um atacante pode provocar essa situação de propósito com uma requisição preparada. Segundo a equipe do PHP, a execução remota de código foi confirmada por HTTP em servidores com Apache e mod_php. Pela análise do código, o PHP-FPM também é vulnerável, mas nenhuma exploração completa via FPM havia sido demonstrada até o lançamento.

CVE-2026-109619: estado antigo reaproveitado entre requisições

Os servidores reaproveitam o mesmo processo (o worker) para atender várias requisições. Por causa dessa falha, uma informação interna de uma requisição pode continuar existindo depois que a memória dela foi liberada, e a requisição seguinte, no mesmo worker, pode usar esse dado antigo. É um caso de use-after-free. Os caminhos confirmados envolvem o tratamento de sessões e os backtraces de erros fatais. Além de executar código, a falha pode vazar dados da memória do servidor.

Quem é afetado

Qualquer instalação de PHP que atenda requisições web: PHP-FPM (comum com Nginx), Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A equipe do PHP considera o Apache com mod_php o caso de maior risco.
Versões antigas também. Segundo o Laravel Forge, as falhas existem em versões do PHP desde 2004.
Qualquer aplicação. O ataque acontece antes do código da aplicação rodar. Os pesquisadores dizem ter conseguido execução de código sem login contra WordPress, Drupal e Joomla, e até contra um simples "Hello World".

Em relação à exploração: a equipe do PHP disse não ter identificado exploits funcionais até o lançamento. O CERT-EU relatou que provas de conceito começaram a circular, e a Cloudflare informou ter visto tráfego de ataque contra seus clientes. Por isso, trate a atualização como urgente.

Versões corrigidas

Ramo do PHP	Versão corrigida	Situação do ramo
8.5	8.5.12	Suporte ativo
8.4	8.4.27	Suporte ativo
8.3	8.3.36	Só correções de segurança, até 31/12/2027
8.2	8.2.35	Só correções de segurança, até 31/12/2026
8.1 ou anterior	Sem correção oficial do PHP	Fim de vida

Atenção: no Ubuntu, o número da versão pode ser diferente

Este é o ponto que mais confunde. Os pacotes oficiais do Ubuntu não trocam a versão do PHP: eles aplicam a correção na versão que a distribuição já usa (o chamado backport). Por isso, um Ubuntu 24.04 corrigido continua mostrando PHP 8.3.6 no php -v, e não 8.3.36. O que muda é a revisão do pacote. Estas são as versões corrigidas segundo a USN-8948-1:

Ubuntu	Pacote	Versão corrigida do pacote
26.10	php8.5	8.5.9-0ubuntu2.1
26.04 LTS	php8.5	8.5.4-0ubuntu1.5
24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
22.04 LTS	php8.1	8.1.2-1ubuntu2.28

Repare que o Ubuntu 22.04 corrigiu o PHP 8.1, mesmo esse ramo não recebendo mais correções do projeto PHP. O Ubuntu 20.04 e as versões mais antigas também receberam correção, mas só pelo ESM, que exige o Ubuntu Pro (gratuito para até 5 máquinas).

Se você instalou o PHP pelo repositório de Ondřej Surý (o PPA ondrej/php, muito usado para ter versões mais novas), aí sim a versão segue a do PHP, como 8.4.27. E vale um alerta: as atualizações automáticas do Ubuntu (unattended-upgrades) aplicam só o que vem do repositório de segurança do próprio Ubuntu. Quem usa o PPA precisa atualizar manualmente.

Passo a passo: como corrigir no Ubuntu com Apache ou Nginx

Os comandos abaixo usam o PHP 8.3 como exemplo. Troque 8.3 pela versão do seu servidor. Rode tudo com um usuário que tenha sudo.

1. Descubra quais versões do PHP estão instaladas

php -v
ls /etc/php
dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2, $3}'

O último comando lista cada pacote do PHP com a versão instalada. Anote o resultado para comparar depois. Se aparecer mais de uma versão em /etc/php, atualize todas, inclusive as que nenhum site usa hoje.

2. Descubra como o PHP é executado

Isso define qual serviço você vai reiniciar no fim.

Apache:

apache2ctl -M 2>/dev/null | grep -E 'php|proxy_fcgi'
ls /etc/apache2/conf-enabled | grep -i fpm

Se aparecer php_module (ou php8.3_module), o Apache usa mod_php.
Se aparecer proxy_fcgi_module e um arquivo como php8.3-fpm.conf, o Apache usa PHP-FPM.

Nginx: o Nginx sempre usa o PHP-FPM. Veja qual versão cada site chama:

grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/null

Uma linha como fastcgi_pass unix:/run/php/php8.3-fpm.sock; indica que o site usa o PHP-FPM 8.3.

3. Descubra de onde vem o pacote

sudo apt update
apt-cache policy php8.3-cli
ls /etc/apt/sources.list.d/

Na saída do apt-cache policy, veja a linha Candidate e a origem. Se ela vier de ppa.launchpadcontent.net/ondrej/php ou packages.sury.org, o PHP vem do repositório do Ondřej, e a versão candidata deve ser a do projeto PHP (por exemplo, 8.3.36). Se vier de security.ubuntu.com ou archive.ubuntu.com, compare com a tabela do Ubuntu acima. Se a versão candidata ainda não for a corrigida, o pacote ainda não chegou ao repositório: espere um pouco e rode sudo apt update de novo.

4. Faça backup

Antes de mexer em produção, faça backup dos arquivos do site, do banco de dados e das configurações do PHP. Um exemplo simples:

sudo tar czf /root/backup-php-config-$(date +%F).tar.gz /etc/php /etc/apache2 /etc/nginx 2>/dev/null

Se o servidor for uma VM na nuvem, tirar um snapshot do disco é ainda melhor. E se tiver um ambiente de homologação, aplique a atualização lá primeiro.

5. Atualize os pacotes do PHP

Este comando atualiza todos os pacotes do PHP já instalados, sem instalar nada novo. A opção --force-confold mantém o seu php.ini e as configurações do FPM:

sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2}')

Se preferir, sudo apt update && sudo apt upgrade atualiza o sistema inteiro, o que também é recomendado pela Ubuntu.

6. Reinicie os serviços

Atualizar o pacote não basta: o processo que já estava rodando continua com o código antigo na memória até ser reiniciado. Escolha o seu caso:

Apache com mod_php:

sudo systemctl restart apache2

Apache ou Nginx com PHP-FPM (repita para cada versão instalada):

sudo systemctl restart php8.3-fpm

Com o PHP-FPM, não é preciso reiniciar o Apache nem o Nginx, já que eles só repassam as requisições para o FPM. O reinício derruba o site por alguns segundos, então prefira um horário de pouco acesso.

Processos PHP de longa duração: filas, workers do Supervisor, Laravel Horizon, Octane ou qualquer script que rode sem parar pela linha de comando continuam com a versão antiga até serem reiniciados. No Laravel, por exemplo:

php artisan queue:restart
php artisan horizon:terminate
sudo supervisorctl restart all

Se não souber tudo o que roda no servidor, reiniciar a máquina (sudo reboot) resolve de uma vez.

7. Confirme que a correção está ativa

dpkg -l 'php*' 'libapache2-mod-php*' | awk '/^ii/ {print $2, $3}'
php -v
php-fpm8.3 -v
systemctl status php8.3-fpm --no-pager | head -5

Confira se as versões batem com a tabela correspondente (do PHP, se você usa o PPA; do Ubuntu, se usa os pacotes oficiais) e se o serviço foi iniciado depois da atualização. Nos pacotes oficiais do Ubuntu, você também pode procurar as CVEs no changelog:

apt changelog php8.3-fpm 2>/dev/null | grep -m2 -E 'CVE-2026-10961[89]'

Por fim, abra o site e confira se tudo funciona normalmente.

E se eu ainda uso PHP 8.1 ou anterior?

O projeto PHP não vai corrigir esses ramos. Suas opções são:

Ubuntu 22.04 com o PHP 8.1 oficial: a Ubuntu já corrigiu. Basta seguir o passo a passo.
Ubuntu 20.04 ou anterior: ative o Ubuntu Pro para receber a correção pelo ESM, e planeje a migração para uma versão suportada.
PHP antigo vindo de outra fonte: migre para uma versão suportada (8.3 ou mais nova) assim que possível. Teste antes, porque plugins e bibliotecas antigos podem quebrar em versões novas.

Se não der para atualizar agora

A equipe do PHP é clara: não existe mitigação completa, só a atualização resolve. Enquanto isso, algumas medidas reduzem o risco:

Desative o progresso de upload de sessões no php.ini ou no pool do FPM com session.upload_progress.enabled = 0 e reinicie todos os workers. Fazer isso com ini_set() ou .user.ini não funciona.
Reduza o tamanho máximo das requisições: post_max_size de 8M se o site não recebe uploads, ou 32M se recebe, com upload_max_filesize menor que ele. No servidor web, ajuste client_max_body_size (Nginx) ou LimitRequestBody (Apache) no mesmo sentido.
No PHP 8.5, defina fatal_error_backtraces = 0.
Se o site passa pela Cloudflare, ela publicou regras de WAF para os vetores conhecidos, inclusive no plano gratuito. É uma proteção paliativa e só vale para o tráfego que passa por ela.

O CERT-EU também recomenda, nos casos mais críticos, tirar a aplicação do acesso público até a correção.

Vale checar se houve invasão

Se o servidor ficou exposto com uma versão vulnerável, faça uma verificação rápida depois de atualizar:

# Arquivos PHP modificados nos últimos 7 dias
sudo find /var/www -name "*.php" -mtime -7 -not -path "*/cache/*"

# Últimos logins e tarefas agendadas
last -n 20
sudo crontab -l; ls /etc/cron.d

Confira também usuários administradores novos na aplicação (no WordPress, em Usuários) e requisições estranhas nos logs de acesso do Apache ou do Nginx. Até a publicação deste artigo, nem o PHP nem os órgãos de segurança tinham divulgado indicadores de comprometimento específicos.

E quem usa WordPress?

A falha está no PHP, e não no WordPress. Atualizar o WordPress, os plugins ou os temas não corrige o problema. Na hospedagem compartilhada ou gerenciada, quem atualiza o PHP é o provedor: confirme com ele. Em VPS ou servidor próprio, siga o passo a passo acima. Para ver a versão do PHP pelo painel, vá em Ferramentas, Saúde do Site, aba Informações, seção Servidor.

Conclusão

As falhas CVE-2026-109618 e CVE-2026-109619 afetam praticamente qualquer servidor com PHP, e a única correção completa é atualizar. Resumindo: descubra a versão e a origem dos pacotes, faça backup, atualize, reinicie o Apache ou o PHP-FPM e os workers, e confirme a versão. Se o seu servidor ainda roda PHP 8.1 ou anterior, aproveite o susto para planejar a migração.

Quer aprofundar em PHP e servidores Linux? Conheça os cursos da plataforma da Hcode e acompanhe o blog.

Perguntas frequentes

Meu Ubuntu mostra PHP 8.3.6. Estou vulnerável?

Não necessariamente. Nos pacotes oficiais do Ubuntu 24.04, a correção chega na revisão do pacote 8.3.6-0ubuntu0.24.04.13. Confira a versão completa do pacote com dpkg -l 'php8.3*', e não só o php -v.

Preciso reiniciar o Nginx?

Não. Com o Nginx, quem executa o PHP é o PHP-FPM, então basta reiniciar o serviço php8.x-fpm. Com o Apache e mod_php, reinicie o apache2.

As atualizações automáticas do Ubuntu resolvem?

Se você usa os pacotes oficiais do Ubuntu e o unattended-upgrades está ativo, a correção é aplicada em até 24 horas, mas os serviços ainda precisam ser reiniciados. Se você usa o PPA do Ondřej, a atualização automática não cobre o PHP.

Mudar configurações do php.ini resolve?

Não. As configurações reduzem o risco, mas a própria equipe do PHP afirma que a única mitigação completa é atualizar.

Fontes

php

apache

ubuntu

Falha crítica no PHP (PHP2Shell): o que é e como corrigir no Ubuntu com Apache ou Nginx