Para quem é isto: qualquer pessoa que mantenha um site em PHP (servidor próprio, VPS, nuvem, Docker ou hospedagem compartilhada) e quem desenvolve sites com WordPress, Laravel, EC-CUBE e similares. Este artigo se baseia em comunicados oficiais da equipe de segurança do PHP e em declarações de órgãos públicos e provedores. Ele não explica como atacar nada.
Em andamento: esta página será atualizada conforme novas informações forem publicadas
Em 25 de outubro de 2026 (JST); provedores de hospedagem e pacotes de sistema operacional até 02:15 UTC de 23 de outubroAinda não se sabe
- Versões afetadas, pontuação CVSS e versão corrigida do terceiro problema, CVE-2026-115560 (previsto para a próxima versão regular)
- Exploração na natureza (visão oficial) e se houve invasões
- Fluxos de pacotes de sistema operacional ainda pendentes (RHEL 9 php:8.4, Debian testing forky)
- Provedores de hospedagem que não anunciaram conclusão (KAGOYA, CPI para versões sem correção disponível, Xserver para PHP 5.5 e anteriores, e outros)
A equipe de segurança do PHP lançou as correções em 21 de outubro, e a IPA e a JPCERT/CC do Japão emitiram alertas em 22 de outubro. A maioria dos principais provedores de hospedagem compartilhada anunciou que a correção foi aplicada. Várias empresas observaram tentativas de exploração, mas nenhuma invasão confirmada foi anunciada. Em 23 de outubro, foi divulgado um terceiro problema (CVE-2026-115560) que as versões corrigidas não tratam. A equipe do PHP considera o caso improvável na prática, mas recomenda definir session.upload_progress.enabled=0 até a próxima versão regular. Esta página será atualizada conforme os pacotes de sistemas operacionais restantes e os provedores forem confirmados.
As versões corrigidas e as vulnerabilidades (do php.net)
Em 21 de outubro de 2026, a equipe de segurança do PHP publicou um aviso de segurança no php.net (“Critical remote code execution vulnerabilities, update now”) e anunciou a versão corrigida de cada ramo.
- Versões corrigidas
- PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
- CVE-2026-109618
- O tratamento de falta de memória pode interromper o PHP enquanto os dados internos da requisição estão apenas parcialmente inicializados, e a limpeza da requisição pode então tratar os dados inválidos como válidos. Leva à execução remota de código (RCE)
- CVE-2026-109619
- Um estado interno pertencente à requisição pode sobreviver depois que sua memória de suporte foi liberada, e uma requisição posterior tratada pelo mesmo worker pode usar esse estado obsoleto antes que a inicialização o redefina. Leva à execução remota de código (RCE)
- Gravidade
- Ambas com CVSS v4.0 9.2
- Quem está em risco
- Todas as instalações do PHP que atendem requisições web (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). O mod_php é o de maior risco, com um exploit demonstrado em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação ser executado
- 8.1 e anteriores
- Nenhuma atualização do projeto PHP. Foram disponibilizados backports mínimos de código-fonte para 7.4, 8.0 e 8.1
- Distribuições
- As distribuições Linux e os fornecedores de LTS receberam os patches antecipadamente; consulte seu fornecedor para pacotes atualizados
- Mitigações
- Não há mitigação completa; atualizar é a única escolha segura (medidas temporárias, caso você ainda não possa atualizar, estão no quadro abaixo)
Medidas temporárias se você ainda não puder atualizar (do aviso; elas não tornam o sistema seguro)
A equipe do PHP lista configurações que reduzem caminhos específicos de ataque até que você possa atualizar, mas afirma que nenhuma delas torna uma instalação segura. As principais são revisar memory_limit e limites de tamanho de requisição como post_max_size, desativar session.upload_progress.enabled e reiniciar os workers, e, no PHP 8.5, desativar fatal_error_backtraces. As condições importam, então leia o aviso oficial antes de alterar qualquer coisa, e priorize a atualização.
Um terceiro problema não corrigido pelas versões (CVE-2026-115560, divulgado em 23 de outubro)
Em 23 de outubro de 2026, a equipe de segurança do PHP publicou “Informational advisory: Session upload progress” no php.net, divulgando um problema que as versões de 21 de outubro não corrigem. Ele é separado das duas vulnerabilidades críticas.
- CVE
- CVE-2026-115560. Um aviso completo será publicado com a próxima versão (em 25 de outubro, o registro da CVE e o NVD ainda não tinham entrada)
- Condições
- Só é afetada uma combinação incomum de configuração e código de aplicação: a configuração define session.serialize_handler como php_binary ou php_serialize, a aplicação o troca para php em tempo de execução com ini_set() antes de chamar session_start(), e o progresso de upload de sessão (session.upload_progress) continua ativo. Aplicações que nunca alteram o serialize handler em tempo de execução podem manter o recurso ativado
- Impacto
- Pode levar à execução remota de código (RCE). A equipe classifica essa configuração como “improvável na prática”
- Mitigação
- Defina session.upload_progress.enabled=0 até a próxima versão regular. A mesma configuração já constava como mitigação no aviso de 21 de outubro para a CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp); se você a aplicou naquela data, mantenha-a e não é preciso fazer mais nada
- Correção
- Como a configuração é improvável, o caso será tratado no ciclo regular de versões, com a correção e um aviso completo na próxima versão. Não foi informada data
- Ainda não publicado
- Versões afetadas e uma pontuação CVSS
- Exploração
- O comunicado da equipe do PHP não menciona exploração
Após o lançamento (até 02:15 UTC de 23 de outubro de 2026)
- Horário do lançamento
- Os avisos de segurança do GitHub foram publicados por volta das 13:34 UTC (22:34 JST), cerca de 30 minutos antes do horário previsto, 14:00 UTC
- Versões afetadas
- Segundo os avisos oficiais do GitHub, versões anteriores a 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Os registros de CVE listam 8.2 a 8.5 e não mencionam a 8.1 e as anteriores (a equipe disponibilizou correções de código-fonte para 7.4, 8.0 e 8.1)
- Impacto confirmado (dos avisos)
- CVE-2026-109618: execução remota de código sem autenticação confirmada no mod_php; o PHP-FPM pode ser afetado segundo a análise do código-fonte, mas um exploit completo não foi demonstrado. CVE-2026-109619: execução remota de código confirmada no mod_php; também validada no PHP-FPM pelo caminho de progresso de upload de sessão, que depende de uma operação adequada da aplicação
- Órgãos públicos japoneses
- Em 22 de outubro, a IPA publicou “PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)” (Medidas para as vulnerabilidades do PHP, em japonês), um acompanhamento do aviso antecipado de 21 de outubro. Ela pede que os usuários atualizem para as versões corrigidas (8.2.35, 8.3.36, 8.4.27, 8.5.12). Para a 8.1 e anteriores, que estão no fim de vida, pede que os usuários migrem para uma versão do PHP com suporte ou para um produto ou serviço já corrigido. Se medidas provisórias eficazes forem difíceis, pede que as organizações avaliem se precisam bloquear o acesso externo ou suspender temporariamente o serviço. Também cita a opinião de uma empresa de segurança envolvida na pesquisa de que o PHP 5.4 e versões posteriores são afetados por pelo menos uma das falhas (opinião dessa empresa, não uma declaração da equipe do PHP). A JVN publicou a JVNVU#99905564 às 10:30 JST (01:30 UTC) do mesmo dia, pedindo que os usuários apliquem os patches. A JPCERT/CC emitiu um alerta (JPCERT-AT-2026-0033) no mesmo dia, pedindo atualizações imediatas e verificações de sinais de comprometimento. Ele também descreve o que procurar ao verificar um comprometimento
- CISA
- A CISA emitiu um alerta em 21 de outubro, pedindo que as organizações apliquem os patches imediatamente. Ela afirma que “não observou exploração dessas vulnerabilidades até o momento da publicação”. Diz às organizações que não podem atualizar imediatamente, ou que ainda usam a 8.1 ou anterior, que tirem de operação os sistemas baseados em PHP até que possam ser corrigidos ou atualizados. As falhas não constam do catálogo Known Exploited Vulnerabilities (edição de 21 de outubro)
- Exploração na natureza
- Nenhuma declaração da equipe do PHP, e a CISA afirma que não observou exploração até a data de publicação. A classificação de exploração que a CISA adicionou aos registros de CVE continuava “nenhuma” após a atualização de 22 de outubro. A equipe de inteligência de ameaças de um grande provedor de nuvem disse em 21 de outubro que seus honeypots registraram uma tentativa de exploração em 17 de outubro, quatro dias antes da divulgação (publicação). Afirma que as falhas estão “agora sendo alvo de tentativas de exploração generalizadas na natureza”, mas que “não está claro se alguma dessas tentativas teria sido bem-sucedida em sistemas reais”. Recomenda investigar a partir de pelo menos 17 de outubro. Um provedor de CDN e várias empresas de segurança também relatam ter observado tráfego de ataque ou de sondagem (provedor de CDN, resumo de notícias). Outra empresa de segurança afirmou, em atualização de 22 de outubro, que os exploits públicos não funcionam contra uma instalação padrão do PHP e que a exploração em massa é menos provável do que se esperava inicialmente. No Japão, a Lolipop e a Heteml disseram, em 22 de outubro, que observaram acessos que pareciam direcionados às falhas, mas nenhum acesso não autorizado ou vazamento de dados resultante foi confirmado até agora. Até 02:15 UTC de 23 de outubro, nenhuma invasão confirmada havia sido anunciada
- Pacotes do sistema operacional
- A Ubuntu fornece correções para as versões listadas 26.10, 26.04, 24.04 e 22.04. As correções para 20.04 e 18.04 exigem Ubuntu Pro; 16.04 e 14.04 exigem o complemento Legacy Support (USN-8948-1, USN-8948-2). A Debian corrigiu a 13 (DSA-6574-1) e a 12 (DLA-4848-1); o sid já tem a versão corrigida 8.4.27-1, enquanto o testing (forky) ainda está na versão não corrigida 8.4.26-1. A Red Hat corrigiu muitos fluxos do RHEL 8 a 10 (classificados como Important, access.redhat.com) e adicionou o php:8.2 do RHEL 8 em 21 de outubro (RHSA-2026:87073). O php:8.4 do RHEL 9 ainda não tem correção (“Affected” na atualização de 22 de outubro). O RHEL 6 está marcado como “Fora do escopo de suporte”, sem correção prevista, e o RHEL 7 é afetado pela CVE-2026-109619, sem correção ainda. A Alpine corrigiu as versões 8.5, 8.4 e 8.3. Se o PHP vem dos pacotes do sistema operacional, aplique agora a atualização do seu fornecedor
- Imagens oficiais do Docker
- As tags latest, 8.5, 8.4, 8.3 e 8.2 (incluindo as variantes -apache e -fpm) apontam todas para as versões corrigidas (8.5.12, 8.4.27, 8.3.36, 8.2.35) (hub.docker.com). As tags da 8.1 e anteriores, que estão no fim de vida, não foram atualizadas. A correção só tem efeito depois que você baixar a imagem novamente e recriar os contêineres
- NVD
- A pontuação própria do NVD para ambas é CVSS 3.1 9.8 (Critical); a pontuação da equipe do PHP é CVSS v4.0 9.2 (nvd.nist.gov)
- Alegação de que a correção está incompleta
- Uma publicação em uma lista de discussão sobre vulnerabilidades afirmou que a correção da 8.5.12 “pode estar incompleta”. O desenvolvedor que publicou o anúncio pela equipe de segurança do PHP respondeu na mesma lista em 22 de outubro (09:11 UTC) que se trata de um “problema não relacionado, com impacto mínimo” (uma falha em um componente em um cenário improvável) e que “não tem nada a ver com a RCE” (resposta). O aviso no php.net não foi alterado
- Windows
- Builds para Windows das versões corrigidas estão disponíveis
- remirepo
- A equipe do PHP diz que o rpms.remirepo.net, mantido por voluntários, não terá atualizações hoje, e recomenda migrar para os pacotes da distribuição ou compilar a partir do código-fonte
O aviso antecipado (20 de outubro)
Um dia antes, em 20 de outubro de 2026, a equipe de segurança do PHP publicou no php.net um aviso intitulado “Upcoming Critical PHP Security Release”. Ele dizia o seguinte.
- Horário do lançamento
- Quarta-feira, 21 de outubro de 2026, 14:00 UTC (23:00 no Japão)
- Escopo
- Duas vulnerabilidades críticas
- Gravidade
- Ambas classificadas com 9.2 no CVSS v4.0
- Pedido
- Todos os usuários do PHP são incentivados a se preparar agora, para atualizar assim que a versão estiver disponível
- Lançamento antecipado
- A equipe pode lançar antes se detalhes de qualquer uma das vulnerabilidades se tornarem públicos ou se surgirem evidências de exploração ativa
- Ainda não publicado
- Detalhes completos, versões afetadas e versões corrigidas, todos previstos para o lançamento
- Últimas versões na data
- 8.5.11, 8.4.26, 8.3.35 e 8.2.34 (versões de segurança de 24 de setembro de 2026)
O CVSS classifica a gravidade de uma vulnerabilidade de 0 a 10, e 9.0 ou mais corresponde à faixa mais alta, “Critical” (veja O que é CVSS). A IPA do Japão também publicou, em 21 de outubro, um aviso de “preparação antecipada” pedindo que as organizações façam um inventário de programas que usam PHP. A IPA destaca que o PHP também pode rodar dentro de produtos de software e dispositivos de rede, e não apenas em aplicações web.
Quem atualiza o PHP: depende da sua configuração
Qualquer site que roda em PHP pode ser afetado, mas quem atualiza o PHP de fato varia conforme o ambiente. Errar nisso gera lacunas como “achei que o provedor tinha feito” ou “atualizei um PHP diferente daquele que atende o site”.
Servidor próprio, VPS, nuvem
Você atualiza (atualize os pacotes e depois reinicie)
Docker (imagem oficial)
Você reconstrói quando as novas tags forem publicadas
Pacotes da distribuição (Debian, Ubuntu, RHEL …)
A distribuição faz o backport da correção, e você a aplica. Os números de versão diferem do upstream
Hospedagem compartilhada
O provedor atualiza o PHP. Você verifica qual versão selecionou
| Ambiente | Quem atualiza o PHP | O que você faz |
|---|---|---|
| Servidor próprio, VPS, servidor em nuvem | Você | Instale a versão corrigida (ou o pacote corrigido da distribuição) e reinicie o PHP-FPM ou o Apache |
Imagem oficial do Docker (php:8.4-fpm e similares) | Os mantenedores das imagens e você | Quando a tag corrigida for publicada, baixe-a, reconstrua sua imagem e substitua os contêineres. Não reutilize uma imagem base antiga em cache |
| Pacotes da distribuição (família Debian, Ubuntu, RHEL) | A distribuição e você | Verifique os avisos de segurança da distribuição para o pacote corrigido e aplique-o. As distribuições fazem backport apenas da correção, então seus números de versão não coincidirão com os números do PHP upstream |
| Hospedagem compartilhada | O provedor | Verifique a versão do PHP de cada site no painel de controle, planeje a troca se for 8.1 ou anterior, e leia os avisos do provedor em seu site oficial |
| PHP embutido em produtos ou dispositivos | O fabricante | Verifique os avisos de segurança do fabricante (você pode não conseguir ver o PHP interno) |
O botão de atualização do WordPress ou do Laravel não atualiza o próprio PHP. Atualizar sua aplicação e atualizar o PHP são tarefas separadas.
Como verificar sua versão do PHP com segurança
Se você consegue fazer login no servidor, use a linha de comando
Se você tem acesso ao shell, este comando mostra a versão do PHP.
php -vEssa é a versão do PHP de linha de comando (CLI), no entanto. O PHP que atende seu site (PHP-FPM ou o módulo do Apache) pode ser outra versão. É comum um servidor ter a 8.2 e a 8.4 instaladas ao mesmo tempo. Verifique o lado web com os métodos abaixo ou pelo nome do serviço PHP-FPM (por exemplo php8.4-fpm).
No WordPress, use a Saúde do Site
No painel do WordPress, abra Ferramentas, depois Saúde do Site, depois a aba Informações, e expanda “Servidor”. Ela mostra a versão do PHP que realmente executa o site, então qualquer pessoa com acesso de administrador pode verificar sem fazer login no servidor.
Na hospedagem compartilhada, use o painel de controle
Na hospedagem compartilhada, as configurações de versão do PHP no painel de controle mostram a versão selecionada para cada domínio. Muitos provedores permitem escolher uma versão diferente por domínio, então verifique todos os domínios.
Não deixe uma página phpinfo() online
Uma forma de ver a versão é colocar um arquivo que chama phpinfo() no diretório público, mas essa página lista a versão, a configuração e os detalhes internos do servidor do PHP. Ela dá a um atacante informações úteis para direcionar o ataque, então apague-a assim que terminar. Se os três métodos acima bastarem, nem crie uma. Como encontrar arquivos esquecidos é tratado em Arquivos secretos deixados em diretórios públicos.
Antes de atualizar
Liste seus sites e servidores
Para cada site, anote em uma única tabela em qual servidor ele está, a versão do PHP (CLI e web), quem atualiza o PHP (você, o provedor ou um prestador de serviços) e os dados de contato do responsável. Inclua sites de homologação e sites esquecidos que ainda estão públicos. Sites esquecidos são os que perdem atualizações. Um método está no checklist de inventário de segurança.
Faça backups
Faça backup de arquivos e bancos de dados para poder reverter caso a atualização quebre o site. Guarde o backup fora do servidor e confirme que consegue restaurá-lo (fundamentos de backup e recuperação).
Defina uma janela de manutenção e as etapas
Decida quando você vai atualizar (incluindo horários noturnos), quem fará a atualização e como vai avisar as pessoas. Nos seus próprios servidores, anote os comandos de atualização, os serviços a reiniciar e como confirmar o resultado. Se um prestador de serviços ou uma agência gerencia o servidor, confirme hoje quem o atualiza e quando.
Em um ramo no fim de vida, planeje a migração
De acordo com o php.net, o suporte ao PHP 8.1 terminou em 31 de dezembro de 2025, assim como para a 8.0 e anteriores. Pela política de suporte do projeto PHP, ramos no fim de vida não recebem versões de segurança. Também desta vez não houve versão oficial (apenas backports mínimos de código-fonte para 7.4, 8.0 e 8.1); planeje a migração para uma versão com suporte, 8.2 a 8.5. O suporte de segurança à 8.2 também termina em 31 de dezembro de 2026, então 8.3 ou posterior é o alvo mais seguro se você está migrando agora.
Não corra para plugins ou configurações de “correção” não oficiais
Antes de uma correção ser lançada, costumam circular plugins não oficiais e alterações de configuração que prometem bloquear o problema. Métodos que não constam do aviso oficial não podem ser verificados. A única correção real é a versão corrigida do PHP (ou o pacote corrigido da sua distribuição). Regras de WAF (firewall de aplicação web) podem ganhar tempo, mas não fazem nada pelo tráfego que chega ao servidor sem passar pelo WAF.
Atualizando para a versão corrigida
As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35 (lançadas em 21 de outubro de 2026). Se você instalou o PHP pelos pacotes do sistema operacional, use os pacotes atualizados que sua distribuição disponibiliza.
Atualize para a versão corrigida do seu ramo
Consulte o anúncio de lançamento e o ChangeLog no php.net para a versão corrigida do seu ramo (8.2, 8.3, 8.4 ou 8.5) e atualize para essa versão ou posterior. Se você usa pacotes da distribuição, verifique os avisos de segurança da sua distribuição (Debian, Ubuntu, Red Hat e outras) para a versão corrigida do pacote. No Docker, baixe e reconstrua assim que as tags corrigidas forem publicadas.
Reinicie o PHP-FPM e o Apache
Atualizar o pacote não altera processos PHP que já estão em execução. Reinicie o PHP-FPM (por exemplo php8.4-fpm), ou o Apache se você usa o módulo PHP dele, para que o novo PHP seja carregado.
Verifique suas configurações de sessão quanto ao terceiro problema (CVE-2026-115560)
Esse problema permanece mesmo depois de você migrar para as versões de 21 de outubro. Verifique duas coisas.
- Se a configuração (php.ini e similares) define session.serialize_handler como php_binary ou php_serialize, e se o código da aplicação o troca para php com ini_set() (buscar
session.serialize_handlerno seu código é uma forma rápida de encontrar isso) - Se session.upload_progress.enabled ainda está ativo (ele vem ativo por padrão; o
php -ida CLI pode diferir do lado web, então verifique também o pool do PHP-FPM e a configuração do PHP que atende o site)
Se as duas condições se aplicarem, ou se você não souber dizer, defina session.upload_progress.enabled=0 até a próxima versão regular. Defina-o onde ele é lido na inicialização, como no php.ini, no pool do PHP-FPM ou na configuração do servidor web, e reinicie todos os workers (o aviso de 21 de outubro diz para definir session.upload_progress.enabled=0 administrativamente e reiniciar todos os workers). O recurso informa o progresso de uploads de arquivos; se o seu site exibe o progresso de upload, confira depois se ele ainda funciona. Se você já desativou o recurso como medida temporária pelo aviso de 21 de outubro, deixe como está. Entre os provedores de hospedagem japoneses, a Heteml e a Lolipop já desativaram esse recurso.
Confirme a versão na CLI e no web
Além de php -v, use a Saúde do Site do WordPress ou o status do serviço PHP-FPM para confirmar que o PHP que atende o site agora é a versão corrigida. Em servidores com várias versões do PHP instaladas, verifique todas.
Confirme que o site funciona e que nada parece estranho
Verifique as páginas principais, o login, os formulários de contato e os pagamentos. Se você está preocupado que o site tenha sido atacado antes da correção, procure arquivos desconhecidos, contas de administrador extras e desfigurações. Um grande provedor de nuvem registrou uma tentativa de exploração em 17 de outubro, quatro dias antes da divulgação, e recomenda investigar a partir pelo menos dessa data. O alerta da JPCERT/CC também lista o que procurar. Como verificar está em Como verificar se seu site ou servidor foi comprometido.
Para usuários de hospedagem compartilhada
Na hospedagem compartilhada, o provedor instala e gerencia o PHP no servidor. Os usuários não conseguem instalar a versão corrigida por conta própria.
O que o provedor faz
- Atualiza o PHP instalado nos servidores para a versão corrigida
- Aplica proteções temporárias ou manutenção emergencial, se necessário
- Publica atualizações de status no site oficial e nas redes sociais
O que você faz
- Verifica a versão do PHP selecionada para cada domínio no painel de controle
- Se for 8.1 ou anterior, testa e depois migra para uma versão mais nova
- Lê os avisos do provedor no site oficial, não pelos links de e-mail
- Mantém o núcleo do WordPress, os plugins e os temas atualizados também
A manutenção emergencial do lado do provedor pode deixar o painel de controle indisponível por um tempo. Conclua suas verificações cedo, para não ficar sem poder trocar a versão do PHP durante essa janela.
Respostas dos provedores (confirmadas por este site até 02:15 UTC de 23 de outubro de 2026)
Muitos provedores dizem que terminaram de aplicar a correção. Até 02:15 UTC de 23 de outubro (11:15 JST), a KAGOYA não tinha anunciado a conclusão. A CPI pede que os clientes em versões sem correção disponível apliquem mitigações ou migrem para uma versão corrigida. Não foi encontrado aviso sobre o PHP para a Rakko Server nem para a WADAX. Os horários abaixo são em JST.
| Provedor | Aviso oficial | O que diz |
|---|---|---|
| Xserver (Japão) | Aviso de suspensão temporária dos sites oficiais e dos painéis de controle como medida preventiva de segurança (situação às 20:10 de 22 de outubro, em japonês) | Aplicou correções oficiais ou próprias em cada versão do PHP que oferece. Concluiu a aplicação em todos os servidores-alvo para o PHP 8.2–8.5 às 06:45 de 22 de outubro, 7.4–8.1 às 12:00 e 5.6–7.3 às 14:00. Para o PHP 5.5 e anteriores, os patches ainda estão “sendo criados e verificados”. A partir das 20:10 reabriu, em sequência, seus sites de serviço; os sites oficiais, painéis de controle, webmail, API/MCP e formulário de contato voltaram (algumas funções, como o webmail antigo, ainda estão em manutenção). Pode pedir a alguns clientes etapas adicionais, conforme o uso. Diz que a ação não se deve a acesso não autorizado |
| Sakura Rental Server (Japão) | Situação da resposta às vulnerabilidades do PHP (22 de outubro, em japonês) | Correção aplicada a todas as versões do PHP selecionáveis no painel de controle; nenhuma ação urgente do cliente é necessária. Também sugere migrar para a versão mais recente com suporte. O webmail usado por alguns serviços foi restaurado às 13:45 de 22 de outubro e o phpMyAdmin às 15:15 (aviso de manutenção). A manutenção emergencial de 21 de outubro (n-2697) terminou às 22:30 de 21 de outubro |
| mixhost (Japão) | [Concluído] Resposta às vulnerabilidades críticas do PHP (22 de outubro, em japonês) | Pacotes de correção aplicados em todos os servidores por volta das 10:18 de 22 de outubro, cobrindo o PHP 5.2–8.5. Os números de versão não mudam (por exemplo, 8.4.26 continua 8.4.26). Nenhuma ação do cliente é necessária. A manutenção da Minha Página desde as 22:10 de 21 de outubro também terminou |
| ColorfulBox (Japão) | Aviso (22 de outubro, em japonês) | As proteções antecipadas e a atualização para as versões corrigidas foram concluídas em todos os servidores (compartilhados, business, Tada Server e dedicados) até a manhã de 22 de outubro, incluindo 7.4, 8.0 e 8.1. Atualizado no próprio lugar, mantendo a versão do PHP que você usa; nenhuma ação do cliente é necessária |
| XREA, VALUESERVER, CORESERVER, One Rental Server (Japão) | XREA, VALUESERVER, CORESERVER V1 / V2, One (em japonês) | Todos os cinco concluídos. XREA, VALUESERVER e CORESERVER V1 concluíram às 00:50 de 22 de outubro, e os avisos atualizados dizem que todas as versões do PHP oferecidas (5.3–8.5) estão corrigidas. O One Rental Server concluiu às 10:20 (5.6–8.5) e o CORESERVER V2 às 11:13 (5.2–8.5). Os usuários não precisam trocar de versão do PHP |
| Heteml (Japão) | Manutenção das vulnerabilidades do PHP concluída, e como ela se desenrolou, [Concluído] aviso de manutenção (18:05 de 22 de outubro, em japonês) | Os sites dos clientes voltaram às 11:24 de 22 de outubro e todos os serviços foram restaurados às 18:05. O PHP 8.2–8.5 recebeu as versões oficiais corrigidas; 7.4, 8.0 e 8.1 receberam as correções da equipe do PHP para ramos no fim de vida; e 5.6–7.3 receberam correções próprias do provedor, baseadas nas oficiais. Em todas as versões, um recurso (session.upload_progress) fica desativado por essa medida, e pede-se aos clientes que verifiquem se seus sites funcionam e que migrem para a 8.2 ou posterior. Até a aplicação das correções, interrompeu sites de alguns servidores a partir de cerca de 03:05 de 22 de outubro |
| Lolipop (Japão) | Manutenção das vulnerabilidades do PHP concluída, e como ela se desenrolou, [Concluído] aviso de manutenção (atualizado às 16:57 de 22 de outubro, em japonês) | Os sites dos clientes voltaram por volta das 13:00 de 22 de outubro e toda a manutenção foi concluída às 16:57. O PHP 8.2–8.5 recebeu as versões oficiais corrigidas; 7.4, 8.0 e 8.1 receberam as correções da equipe do PHP para ramos no fim de vida; e 5.3–7.3 receberam correções próprias do provedor, baseadas nas oficiais. Um recurso (session.upload_progress) está desativado em todas as versões, e pede-se aos clientes que verifiquem seus sites e migrem para a 8.2 ou posterior. Até a aplicação das correções, interrompeu sites de alguns servidores a partir de cerca de 03:09 de 22 de outubro |
| KAGOYA (Japão) | Impacto das vulnerabilidades do PHP em seus serviços (atualizado às 18:15 de 22 de outubro, em japonês) | Para seus servidores de aluguel (PHP 7.4 e 8.1–8.5), afirmou que as atualizações para as versões corrigidas estavam em andamento e deviam ser concluídas às 24:00 de 22 de outubro. Até 11:15 de 23 de outubro, não foi encontrado aviso de conclusão. Para os planos de dedicado gerenciado, compartilhado e WordPress, a correção definitiva ainda está sendo organizada, e pede-se aos clientes que considerem tirar os sites do ar (mudando para uma página de manutenção) ou restringir o acesso como medida provisória. A atualização das 10:35 disse que nenhum dano, como ataques ou vazamentos de dados, foi confirmado. Desde as 14:15 de 22 de outubro também executa manutenção de segurança no webmail, no site de membros e nos painéis de controle, sem horário de término informado |
| ConoHa WING (Japão) | Resposta às vulnerabilidades do PHP concluída (relatório final) (22 de outubro, em japonês) | Patches de segurança foram aplicados a todos os servidores até as 20:45 de 22 de outubro, quando a manutenção emergencial também terminou. Os patches foram aplicados a todas as versões do PHP oferecidas, incorporando apenas a correção, sem elevar a versão; por isso, a Saúde do Site do WordPress e telas semelhantes podem ainda mostrar o número antigo (por exemplo 8.5.11). Os clientes não precisam trocar de versão. O webmail e o gerenciador de arquivos voltaram por volta das 18:30, e o phpMyAdmin também voltou |
| Onamae.com Rental Server (Japão) | Resposta às vulnerabilidades do PHP concluída (22 de outubro, em japonês) | Mesmo conteúdo do ConoHa WING: os patches foram aplicados até as 20:45 de 22 de outubro (planos Basic, RS e AI Homepage Pack). Apenas a correção foi incorporada a todas as versões do PHP oferecidas, então o número de versão exibido pode ter permanecido o mesmo. Os clientes não precisam trocar de versão. O webmail e o gerenciador de arquivos voltaram por volta das 18:30, e o phpMyAdmin também voltou |
| CPI (Japão) | Aviso sobre a suspensão do site de serviços e dos painéis de controle por causa das vulnerabilidades do PHP (atualizado às 09:55 de 23 de outubro, em japonês) | As versões que têm o patch mais recente estão concluídas (por exemplo, 8.2 e 8.3 no SV-Basic, 8.2–8.4 no Business Standard). Para as demais versões, pede-se aos clientes que considerem aplicar mitigações e migrar para uma versão do PHP corrigida (nos planos mais antigos, que considerem aplicar mitigações). O site de serviços reabriu às 21:00 de 22 de outubro e o painel de controle por volta das 17:00; o gerenciador de arquivos seguro e algumas outras ferramentas são esperados depois de 30 de outubro. Diz que nenhum acesso não autorizado ou ataque explorando as falhas foi confirmado |
| Rakko Server (Japão) | Site oficial (em japonês) | O site de serviços foi interrompido a partir das 19:00 de 21 de outubro como precaução (disse que não foi encontrado acesso não autorizado). O site voltou, mas não foi encontrado aviso sobre o PHP até 11:15 de 23 de outubro |
| WADAX (Japão) | Site oficial (em japonês) | Ao ser verificado em 22 de outubro, o site inteiro estava suspenso por segurança até que a segurança fosse garantida. Até 11:15 de 23 de outubro o site voltou, mas não foi encontrado aviso sobre o PHP |
Os provedores redigem seus avisos de conclusão de formas diferentes. Verifique no aviso do seu provedor quais versões do PHP estão cobertas e se você precisa fazer alguma coisa. Alguns provedores, como ConoHa WING, Onamae.com e mixhost, incorporaram apenas a correção, então o número da versão do PHP não muda. Não considere um site sem patch apenas pelo número; verifique o aviso do provedor. Os avisos de outros provedores serão incluídos quando forem confirmados.
Cuidado com e-mails falsos que se passam pelo seu provedor
Quando uma vulnerabilidade ou uma manutenção emergencial está em destaque, tornam-se mais comuns e-mails falsos que alegam vir de provedores de hospedagem ou de domínio (“faça login novamente para uma manutenção urgente”, “sua conta será suspensa”). Não faça login por links de e-mail. Verifique pelo site oficial que você mesmo salvou nos favoritos ou pela conta oficial do provedor nas redes sociais. Como identificá-los está em O que é phishing. Como se preparar para uma violação no próprio provedor está em Quando seu provedor de hospedagem sofre uma violação.
Relatos anteriores ao lançamento
O comunicado oficial de 21 de outubro confirmou os IDs de CVE (CVE-2026-109618, CVE-2026-109619) e que ambas são vulnerabilidades de execução remota de código (RCE). A tabela abaixo mostra o que foi relatado antes do lançamento; a exploração na natureza ainda não está oficialmente confirmada.
Antes do lançamento, a mídia e empresas de segurança repassaram várias alegações. Nenhuma delas foi declaração oficial da equipe de segurança do PHP. Este site não alterou as etapas recomendadas com base nelas.
| Alegação | Fonte | Situação |
|---|---|---|
| Detalhes das falhas vazaram antes do lançamento previsto | Uma empresa de segurança (falando a um veículo de notícias) | Não confirmado |
| Ambas são falhas de execução remota de código (RCE) | Empresas de segurança e a CERT-EU (o CSIRT das instituições da UE) | Confirmado pelo comunicado de 21 de outubro |
| IDs de CVE (CVE-2026-109618, CVE-2026-109619) | Empresas de segurança, mídia, CERT-EU | Confirmado pelo comunicado de 21 de outubro |
| Uma ampla faixa a partir do PHP 5 é afetada | Empresas de segurança, CERT-EU | Não confirmado (os avisos do GitHub cobrem versões anteriores a cada versão corrigida, sem limite inferior declarado; backports fornecidos para 7.4/8.0/8.1). O alerta da IPA de 22 de outubro cita uma empresa de segurança envolvida na pesquisa dizendo que o PHP 5.4 e versões posteriores são afetados |
| Nenhuma exploração observada | Uma empresa de segurança (falando a um veículo de notícias) | Opinião da própria fonte |
| Sinais de ataques observados | Um executivo de um provedor de CDN, outra empresa de segurança (citando relatos de parceiros de hospedagem) e um grande provedor de nuvem | Um provedor de CDN afirmou, em publicação às 13:56 UTC, ter observado tráfego de ataque, e um grande provedor de nuvem disse ter visto tentativas de exploração a partir de 17 de outubro (veja “Após o lançamento”). Nenhum órgão público confirmou |
As visões sobre a exploração diferem entre as fontes. Em seu aviso antecipado de 21 de outubro, a IPA afirmou que naquele momento não tinha confirmado ataques explorando as falhas. A CISA também afirmou em seu alerta de 21 de outubro que não havia observado exploração até a publicação. Já um grande provedor de nuvem afirma ter visto uma tentativa de exploração em 17 de outubro, antes da divulgação. Tenha havido ou não exploração, a ação é a mesma: atualize para a versão corrigida agora.
Avaliação deste site: o que você decide hoje é quem atualiza e quando
As versões corrigidas já estão disponíveis. O que resta é decidir quem atualiza e quando, e fazer a atualização. A lacuna comum não é técnica, e sim de responsabilidade. Um site que uma agência criou, uma VPS configurada por alguém que já saiu da empresa, um servidor de testes que ninguém lembra: o PHP sem um responsável nomeado é o que fica desatualizado por mais tempo. Como avaliar a gravidade está em Como priorizar vulnerabilidades (CVSS, EPSS, KEV), e as etapas após a divulgação em O que fazer quando uma vulnerabilidade é publicada.
Cronologia
24 de setembro de 2026
PHP 8.5.11, 8.4.26, 8.3.35 e 8.2.34 lançados como versões de segurança (as versões mais recentes na data do aviso).17 de outubro (anunciado em 21 de outubro)
Os honeypots de um grande provedor de nuvem registram uma tentativa de exploração, quatro dias antes da divulgação.20 de outubro
A equipe de segurança do PHP anuncia no php.net uma versão de segurança para as 14:00 UTC de 21 de outubro. Ambas as vulnerabilidades são classificadas com 9.2 no CVSS v4.0. No mesmo dia, uma empresa de segurança é noticiada dizendo a um veículo de notícias que os detalhes haviam vazado.21 de outubro
A IPA publica seu aviso de “preparação antecipada”. A Xserver suspende o acesso aos seus sites oficiais e painéis de controle a partir das 16:00 JST.21 de outubro
A equipe de segurança do PHP lança as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 e um aviso de segurança. Afirma que CVE-2026-109618 e CVE-2026-109619 podem ambas permitir execução remota de código sem autenticação e pede que todos atualizem imediatamente.21 de outubro
A CISA emite um alerta pedindo aplicação imediata dos patches e afirma que não observou exploração até a publicação.22 de outubro
A Xserver (8.2–8.5), a Sakura, a mixhost, a ColorfulBox, os serviços do grupo Value Domain, a Heteml, a Lolipop e outros anunciam que a correção foi aplicada. A JVN publica a JVNVU#99905564, a IPA emite seu alerta sobre medidas para as vulnerabilidades do PHP, e a JPCERT/CC emite seu alerta (JPCERT-AT-2026-0033).22 de outubro (noite, JST)
ConoHa WING e Onamae.com dizem que os patches tinham sido aplicados até as 20:45 JST. A Xserver concluiu o PHP 5.6–8.5 até as 14:00 JST e reabre seus sites oficiais a partir das 20:10 JST. A KAGOYA diz esperar que seus servidores de aluguel estejam concluídos às 24:00 JST.23 de outubro
A equipe de segurança do PHP divulga um terceiro problema (CVE-2026-115560) não corrigido pelas versões de 21 de outubro. Considera o problema improvável na prática e recomenda definir session.upload_progress.enabled=0 até a próxima versão regular.
Fontes (registro público)
Os fatos deste artigo se baseiam nas informações públicas abaixo. Itens que o PHP não publicou oficialmente (como a exploração na natureza) são atribuídos à mídia ou a empresas de segurança e marcados como não confirmados.
- Equipe de segurança do PHP, “Security advisory: Critical remote code execution vulnerabilities, update now” (21 de outubro de 2026) — php.net
- Equipe de segurança do PHP, “Informational advisory: Session upload progress” (CVE-2026-115560, 23 de outubro de 2026) — php.net
- Aviso de segurança do GitHub para a CVE-2026-109618 — github.com
- Aviso de segurança do GitHub para a CVE-2026-109619 — github.com
- ChangeLog (8.5.12, 8.4.27, 8.3.36, 8.2.35) — php.net
- PHP, “Upcoming Critical PHP Security Release” (20 de outubro de 2026) — php.net
- Página inicial do PHP (versões mais recentes na data: 8.5.11, 8.4.26, 8.3.35, 8.2.34) — php.net
- PHP, “Supported Versions” — php.net
- PHP, “Unsupported Branches” (fim de vida do 8.1: 31 de dezembro de 2025) — php.net
- Avisos de segurança do php-src (GitHub) — github.com
- IPA, aviso pedindo preparação antecipada para a versão de segurança do PHP (21 de outubro de 2026, em japonês) — ipa.go.jp
- IPA, “PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)” (22 de outubro de 2026, em japonês) — ipa.go.jp
- JVN, JVNVU#99905564 sobre múltiplas vulnerabilidades do PHP que permitem execução arbitrária de código (22 de outubro de 2026, em japonês) — jvn.jp
- JPCERT/CC, alerta sobre múltiplas vulnerabilidades do PHP (CVE-2026-109618, CVE-2026-109619) (JPCERT-AT-2026-0033, 22 de outubro de 2026, em japonês) — jpcert.or.jp
- CISA, “Critical Vulnerabilities in PHP Require Immediate Patching” (21 de outubro de 2026) — cisa.gov
- Xserver Inc., aviso de suspensão temporária como medida preventiva de segurança (22 de outubro de 2026; situação às 20:10 JST, em japonês) — xserver.ne.jp
- Equipe de inteligência de ameaças de um grande provedor de nuvem: tentativas de exploração a partir de 17 de outubro, antes da divulgação (21 de outubro de 2026) — aws.amazon.com
- Resposta de um desenvolvedor da equipe de segurança do PHP à alegação de que a correção está incompleta (22 de outubro de 2026) — openwall.com
- Avisos de conclusão de provedores de hospedagem: ConoHa WING / Onamae.com / Lolipop / Heteml (todos de 22 de outubro de 2026, em japonês)
- CERT-EU, “Security Advisory 2026-018: Critical Vulnerabilities in PHP” (fonte das alegações não confirmadas) — cert.europa.eu
- Reportagem da mídia: relato de uma empresa de segurança sobre o vazamento e sua opinião de que nenhuma exploração foi observada (BleepingComputer, 20 de outubro de 2026) — bleepingcomputer.com
- Reportagem da mídia: a mitigação para o terceiro problema (CVE-2026-115560) (BleepingComputer, 23 de outubro de 2026) — bleepingcomputer.com
- Alerta de empresa de segurança: relatos de ataques vindos de parceiros de hospedagem (21 de outubro de 2026) — patchstack.com
- Publicação de executivo de um provedor de CDN: ataques iniciais e regras de WAF (21 de outubro de 2026; citada no alerta acima) — x.com
- Resposta rápida de empresa de segurança: nenhuma exploração na natureza observada em sistemas parceiros (até 21 de outubro de 2026) — huntress.com
- Análises de empresas de segurança (IDs de CVE, tipo e escopo relatados) — sansec.io / tenable.com
- Avisos de segurança das distribuições: Debian security-tracker.debian.org / Ubuntu ubuntu.com / Red Hat access.redhat.com (RHEL 8 php:8.2: RHSA-2026:87073)
- Imagem oficial do Docker (php) — hub.docker.com
Histórico de atualizações
2026-10-25: Incluído o terceiro problema divulgado pela equipe de segurança do PHP em 23 de outubro (CVE-2026-115560, não corrigido pelas versões de 21 de outubro): suas condições, a mitigação (session.upload_progress.enabled=0) e a correção prevista, além de uma etapa para os administradores verificarem suas configurações. Atualizados o resumo, a caixa de status, o FAQ, a cronologia e as fontes.
2026-10-23 (02:15 UTC): Incluído o relato de um grande provedor de nuvem sobre tentativas de exploração a partir de 17 de outubro (não está claro se alguma foi bem-sucedida), os relatos de provedores japoneses sobre acessos que pareciam direcionados às falhas (nenhum dano confirmado) e que nenhuma invasão confirmada foi anunciada; incluída a recomendação de revisar os logs a partir de 17 de outubro. Incluída a resposta do desenvolvedor da equipe de segurança do PHP de que o relato de “correção incompleta” não tem relação. Atualizados os pacotes de sistemas operacionais (Debian sid corrigido, php:8.4 do RHEL 9 ainda sem correção, sem correção prevista para o RHEL 6) e a situação dos provedores (ConoHa WING, Onamae.com, Lolipop e Heteml concluídos; Xserver concluiu o PHP 5.6–7.3; versões cobertas pelos serviços do grupo Value Domain; situação da KAGOYA e da CPI).
2026-10-22 (04:45 UTC): Alterado o título para o formato de notícia urgente e incluídos os alertas da IPA, da JPCERT/CC (JPCERT-AT-2026-0033), a JVNVU#99905564 e o alerta da CISA. Atualizados os relatos de exploração (ainda sem invasão confirmada), os pacotes de sistemas operacionais (adicionado o php:8.2 do RHEL 8; php:8.4 do RHEL 9 e os ramos de desenvolvimento da Debian pendentes), as imagens oficiais do Docker e a situação de conclusão dos provedores de hospedagem compartilhada (Xserver, Sakura, mixhost, ColorfulBox, serviços do grupo Value Domain, Heteml e outros).
2026-10-21 (21:30 UTC): Atualizados os relatos de exploração (tentativas observadas, nenhuma invasão confirmada), os pacotes corrigidos dos fornecedores de sistemas operacionais, as imagens oficiais do Docker (agora corrigidas), a pontuação do NVD, uma alegação não confirmada de que a correção está incompleta, e as atualizações de hospedagem (a Xserver começou a aplicar as correções, a WADAX foi incluída).
2026-10-21 (14:30 UTC): Incluído o relato de um provedor de CDN sobre tráfego de ataque observado, os pacotes corrigidos da Ubuntu (USN-8948-1), os registros do NVD e a situação das imagens oficiais do Docker.
2026-10-21 (14:10 UTC): Incluída a situação após o lançamento (horário do lançamento, versões afetadas, impacto confirmado nos avisos, nenhuma declaração oficial sobre exploração, pacotes de sistemas operacionais, imagens oficiais do Docker, remirepo) e atualizações de hospedagem após 21:00 JST (incluídas CPI e mixhost, FAQ da Xserver, conclusão da Sakura).
2026-10-21 (após o lançamento): Incluído o comunicado da equipe de segurança do PHP de 21 de outubro (versões corrigidas, IDs de CVE, a natureza das falhas, quem está em risco, como a 8.1 e as anteriores são tratadas, medidas temporárias) e reescritos o título e o destaque principal (takeaway).
2026-10-21: Primeira versão, com base no aviso da equipe de segurança do PHP de 20 de outubro, no aviso de preparação antecipada da IPA e no aviso da Xserver. Os IDs de CVE, as versões afetadas e os números das versões corrigidas serão incluídos após o lançamento.
Leia em seguida
- Seu site foi atacado: Como verificar se seu site ou servidor foi comprometido
- Quando o provedor sofre uma violação: Quando seu provedor de hospedagem sofre uma violação / Acesso não autorizado ao ConoHa WING
- Configurações de hospedagem compartilhada: Protegendo o .env na hospedagem compartilhada
- WordPress e Laravel: Segurança do WordPress / Segurança do Laravel
- Preparação: Fundamentos de backup e recuperação / Checklist de inventário de segurança
- Outra correção crítica na mesma semana: GitLab CVE-2026-110264 (com as correções de regex do Ruby)
- Termos: O que é RCE (execução remota de código) / O que é CVSS