A versão do PHP que corrige CVE-2026-109618 e CVE-2026-109619 será conhecida na quarta-feira, 21 de outubro de 2026, às 14:00 UTC, quando o time de segurança do PHP publicar o patch. Enquanto isso, você já pode verificar se seu branch do PHP vai receber a correção.
Atualização pendente: no momento da publicação desta nota (21 de outubro de 2026, antes das 14:00 UTC), o PHP ainda não havia publicado o patch. Adicionaremos aqui a versão corrigida de cada branch assim que aparecer em php.net.
O anúncio oficial saiu na lista php.announce. Nele, o time de segurança do PHP confirma duas vulnerabilidades críticas, cada uma com uma pontuação CVSS v4.0 de 9.2. O aviso não menciona identificadores CVE, versões afetadas nem detalhes técnicos.
https://news-web.php.net/php.announce/509
Qual versão do PHP corrige CVE-2026-109618 e CVE-2026-109619?
No momento da publicação, ainda nenhuma: o PHP não havia anunciado os números de versão corrigidos. Conforme php.net, as versões afetadas e as corrigidas serão publicadas junto com o patch.
O que você já pode fazer é identificar seu branch. O PHP mantém quatro branches com suporte: 8.2, 8.3, 8.4 e 8.5. Suas versões mais recentes são as da atualização de segurança de 24 de setembro:
| Branch | Última versão antes deste patch | Suporte de segurança até |
|---|---|---|
| 8.5 | 8.5.11 | 31 dez 2029 |
| 8.4 | 8.4.26 | 31 dez 2028 |
| 8.3 | 8.3.35 | 31 dez 2027 |
| 8.2 | 8.2.34 | 31 dez 2026 |
Se seu branch aparece na tabela, você receberá uma correção. Se não aparecer, leia mais abaixo a seção sobre versões antigas.
O PHP 8.6.0 ainda está em fase de release candidate (RC3, com RC4 prevista para 22 de outubro) e não deve ser usado em produção.
A que horas sai o patch de segurança do PHP?
O PHP critical security release está agendado para as 14:00 UTC de quarta-feira, 21 de outubro de 2026. Em horário local:
| Cidade | Horário local |
|---|---|
| Cidade do México | 08:00 |
| Bogotá, Lima | 09:00 |
| Buenos Aires, Santiago | 11:00 |
| Madrid | 16:00 |
Pode sair antes. O time se reserva o direito de adiantar a publicação se detalhes de alguma das vulnerabilidades vazar ou se detectar exploração ativa.
O que se sabe sobre as vulnerabilidades PHP2Shell?
Oficialmente, muito pouco. Vale separar o que disse o PHP do que estão reportando outros.
Confirmado pelo PHP:
- São duas vulnerabilidades, ambas de severidade crítica com CVSS v4.0 9.2.
- Haverá uma publicação coordenada às 14:00 UTC.
- O anúncio do PHP não nomeia CVE, nem versões afetadas, nem como funcionam as falhas.
Reportado por pesquisadores, não pelo PHP:
- Identificadores. CVE-2026-109618 e CVE-2026-109619 apareceram primeiro em uma publicação do Hacker News que depois foi removida. Depois foram repetidos pela watchTowr à BleepingComputer, e aparecem no aviso 2026-018 da CERT-EU.
- Alcance e gravidade. A watchTowr afirma que ambas são vulnerabilidades de execução remota de código (RCE) que afetam PHP 5, 6, 7 e 8. A empresa lhes atribui CVSS 10, contra o 9.2 oficial do PHP.
- Estado da exploração. A watchTowr diz ter reproduzido a CVE-2026-109618. Em 20 de outubro não havia observado exploração ativa.
- CERT-EU coleta estes relatórios. Atribui a caracterização como RCE a vazamentos, e o alcance “desde PHP 5” a um pesquisador de segurança. Recomenda identificar já as aplicações baseadas em PHP e, onde não seja possível parchear imediatamente, isolar da rede pública as aplicações expostas à internet.
- Apelido. As falhas circulam com o nome não oficial de PHP2Shell.
- Mecanismo. Uma análise de terceiros atribui uma das falhas a um heap use-after-free em
session.upload_progress. Nem PHP nem CERT-EU confirmaram, então trate como não verificado.
Como saber qual versão do PHP tenho com php -v e phpinfo()?
No terminal, execute:
php -v
A primeira linha mostra a versão e o SAPI, por exemplo PHP 8.3.35 (cli).
Atenção: o binário php de seu terminal é o CLI. Seu servidor web pode estar executando outra compilação via PHP-FPM ou o módulo do Apache, com outra versão e outro php.ini.
Para ver o que realmente executa seu site, crie temporariamente um arquivo com <?php phpinfo(); na raiz web e o abra no navegador. Depois delete imediatamente, porque expõe toda sua configuração.
Para ver qual php.ini o CLI carrega:
php --ini
Você instala PHP com os pacotes de sua distribuição Linux? Então a correção chegará como uma atualização de segurança da distro, e seu número de versão pode não coincidir com o do PHP. Revise também os avisos de segurança de sua distribuição.
O que acontece se uso PHP 8.1, 7.4 ou 5.x?
Você não vai receber uma correção oficial. PHP 8.1 e todas as versões anteriores estão em end of life (fim de suporte), e o projeto PHP só patcheia os quatro branches com suporte.
Se for confirmado o alcance reportado (“desde PHP 5”), todo servidor em um branch sem suporte continuará exposto depois das 14:00 UTC. As opções realistas são:
- migrar para um branch com suporte;
- depender de um provedor ou distribuição que aplique backports de segurança, como fazem algumas distribuições Linux empresariais;
- isolar a aplicação da internet, como sugere CERT-EU.
Tenha em mente que o próprio branch 8.2 perde o suporte de segurança em 31 de dezembro de 2026, em dez semanas.
Há uma mitigação enquanto chega o patch?
Há uma medida temporária que está circulando, mas não está confirmada como solução para estas CVE. Vários pesquisadores sugerem desativar o rastreamento do progresso de uploads em php.ini:
session.upload_progress.enabled = Off
Dois dados fazem valer a pena considerá-la mesmo sem confirmação:
- Vem ativada por padrão. O manual indica que seu valor padrão é
1. - O próprio manual do PHP já recomenda desativá-la se você não usa barras de progresso de upload. A função escreve no armazenamento de sessão os nomes de arquivo e de campo que o cliente envia, sem validá-los. Conforme o manual, isso torna trivial explorar qualquer vulnerabilidade de inclusão local de arquivos.
A diretiva é INI_PERDIR, então a mude em php.ini, não em tempo de execução com ini_set(). Depois recarregue PHP-FPM ou seu servidor web.
No momento da publicação desta nota, nem PHP nem CERT-EU haviam confirmado que este ajuste bloqueia alguma das duas vulnerabilidades. Use-o para reduzir a exposição, não como substituto da atualização.
Como atualizar PHP quando sair o patch?
Assim que for publicado, siga esta ordem:
- Leia o anúncio da versão em php.net. Aí estarão a versão corrigida de seu branch e o detalhe das CVE.
- Atualize primeiro tudo que serve tráfego web. Depois, o CLI, os workers e os containers. Reconstrua as imagens Docker que fixam uma imagem base do PHP.
- Verifique a versão que realmente corre. Use
php -vephpinfo()no SAPI web para verificar que é a nova. - Revise o ajuste de
session.upload_progress. Se desativou e sua aplicação usa barras de progresso de upload, decida de forma deliberada se volta a ativar depois de parchear.
E você? Qual versão do PHP corre hoje em seu servidor de produção?
- No mesmo dia que sair
- Esta semana
- Depende de meu hosting ou de minha distribuição
- Prefiro outra opção (conte-nos qual)
Comente abaixo ou, se este artigo chegou até você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: Seu projeto usa uma versão vulnerável do Handlebars? Como verificar e atualizar para 4.7.10