Adicionar como fonte preferencial no Google
Em 21 de outubro de 2026, invasores já estavam atacando sites com solicitações criadas para explorar duas vulnerabilidades críticas do PHP, conhecidas como PHP2Shell. As correções oficiais de segurança ainda não estavam disponíveis, mas nossas equipes de engenharia e segurança já estavam trabalhando para proteger os sites hospedados na Kinsta.
A resposta envolveu várias frentes de atuação. Nossa equipe habilitou regras emergenciais de firewall do Cloudflare, ajustou as configurações do PHP e se preparou para implementar as correções em centenas de milhares de contêineres assim que estivessem disponíveis. Ao mesmo tempo, nossa equipe de Suporte lidava com um aumento no volume de solicitações de clientes preocupados com seus sites.
Até 23 de outubro, nossas proteções do Cloudflare haviam bloqueado mais de 550.000 solicitações direcionadas às vulnerabilidades. Também havíamos implementado as atualizações de segurança necessárias do PHP em toda a nossa plataforma de hospedagem e não encontramos evidências de invasões bem-sucedidas.
Veja como nossa resposta se desenrolou, desde os primeiros sinais de exploração das vulnerabilidades até a implementação das correções e o trabalho realizado mais tarde.
Preparação para o PHP2Shell antes da disponibilização das correções
Em 20 de outubro, a equipe de segurança do PHP anunciou uma atualização crítica de segurança, programada para o dia seguinte. O anúncio alertava sobre duas vulnerabilidades com pontuação de gravidade 9,2 no CVSS 4.0 e recomendava que os usuários do PHP se preparassem para atualizar suas instalações assim que as correções estivessem disponíveis.
As vulnerabilidades, mais tarde identificadas como CVE-2026-109618 e CVE-2026-109619, afetam o gerenciamento interno de memória do PHP e poderiam, em determinadas condições, permitir que invasores executassem código remotamente sem autenticação.
O anúncio foi especialmente importante para os sites WordPress porque o PHP é responsável pela execução do próprio aplicativo. Atualizar um plugin ou tema do WordPress não corrigiria essas vulnerabilidades. O ambiente de execução do PHP precisava de correções de segurança.
Para provedores de hospedagem como a Kinsta, o desafio inicial era proteger os sites antes que as correções oficiais estivessem disponíveis. Nossa equipe começou a se preparar para o lançamento, mas as tentativas de exploração já estavam surgindo.
Segundo Laszlo Farkas, Diretor de Engenharia da Kinsta, nossa equipe começou a observar solicitações direcionadas às vulnerabilidades nas primeiras horas de 21 de outubro. Os engenheiros verificaram manualmente os sites que estavam sendo alvo dos ataques e continuaram monitorando as atividades em busca de sinais de invasões bem-sucedidas.
Naquele momento, já havíamos tomado medidas para proteger os sites da nossa plataforma.
Como ativamos as regras emergenciais do WAF do Cloudflare
Todos os sites hospedados na Kinsta já utilizam o Cloudflare como camada de proteção, incluindo os ambientes de produção e de teste. Isso permite que nossa equipe de engenharia aplique proteções de firewall em toda a plataforma de hospedagem, sem exigir que os clientes configurem regras individualmente para cada site.
Antes da divulgação pública do PHP2Shell, o Cloudflare introduziu regras emergenciais de Web Application Firewall (WAF) para detectar tentativas de exploração. Nossa equipe de engenharia acompanhou de perto o registro de alterações do WAF do Cloudflare à medida que novas regras eram disponibilizadas, analisou cada uma delas e definiu a ação como Block o mais rápido possível.
Como todos os sites da Kinsta já utilizam o Cloudflare como camada de proteção, conseguimos aplicar essas proteções em toda a nossa plataforma de hospedagem, abrangendo tanto os ambientes de produção quanto os de teste, sem exigir nenhuma ação dos clientes.
Essa proteção em toda a plataforma foi importante porque o PHP2Shell não era uma vulnerabilidade comum no nível do aplicativo. Os ataques tinham como alvo o próprio PHP, portanto, atualizações de segurança do WordPress ou proteções no nível dos plugins não resolveriam o problema subjacente.
As regras do WAF nos permitiram bloquear tentativas conhecidas de exploração enquanto preparávamos as correções do PHP. O Cloudflare continuou atualizando suas proteções à medida que os invasores modificavam suas técnicas. Seu relatório técnico sobre o PHP2Shell descreve como os invasores alteraram seus payloads para contornar os mecanismos de detecção existentes.
O Cloudflare também introduziu a detecção de transação completa, que analisa sinais tanto da solicitação HTTP quanto da resposta do servidor. Isso fornece informações adicionais para identificar solicitações suspeitas e pode impedir que uma resposta correspondente aos critérios de detecção chegue ao solicitante.
Nossos engenheiros conseguiram observar as mudanças nos padrões de ataque à medida que novas regras eram disponibilizadas.
Até 23 de outubro, as proteções do Cloudflare que abrangem os sites da Kinsta haviam bloqueado mais de 550.000 solicitações direcionadas ao PHP2Shell.
Esse número representa requisições bloqueadas relacionadas às vulnerabilidades, e não invasões bem-sucedidas ou invasores únicos. Ele reflete o tráfego suspeito que nossas proteções de firewall gerenciaram enquanto a equipe trabalhava na implementação das correções do PHP.
Adicionando proteções temporárias à configuração do PHP
Não dependemos apenas do Cloudflare. Enquanto aguardávamos os pacotes corrigidos do PHP, nossa equipe de engenharia também implementou alterações na configuração do PHP em nossos ambientes de hospedagem para reduzir a exposição a vetores conhecidos de exploração das vulnerabilidades.
Uma dessas alterações envolveu desabilitar o recurso de monitoramento do progresso de upload de sessões do PHP por meio da configuração “session.upload_progress.enabled”.
O aviso de segurança do PHP identifica essa configuração como uma medida de mitigação para determinados métodos de exploração. Desabilitá-la ajuda a bloquear ataques que dependem do mecanismo de monitoramento do progresso de upload de sessões do PHP, embora não impeça todas as formas possíveis de exploração das vulnerabilidades.
As regras de firewall e as alterações de configuração forneceram proteção adicional enquanto as correções não estavam disponíveis ou ainda estavam sendo implementadas. No entanto, a atualização do ambiente de execução do PHP continuava sendo necessária.
Em 23 de outubro, a equipe do PHP publicou outro aviso recomendando que o recurso de monitoramento do progresso de upload de sessões do PHP permanecesse desabilitado até uma atualização posterior de correção de bugs. Isso reforçou a medida preventiva que nossa equipe de engenharia já havia adotado.
Nossas regras do Cloudflare e proteções de configuração locais permaneceram ativas durante toda a implementação das correções, independentemente de cada ambiente já ter recebido seu pacote atualizado do PHP.
Implementando correções do PHP em centenas de milhares de contêineres
Quando a equipe de desenvolvimento do PHP lançou as atualizações de segurança em 21 de outubro, nosso próximo desafio foi implementar essas correções em toda a infraestrutura de hospedagem.
As versões oficiais incluíam PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. No entanto, a Kinsta também oferece suporte a versões mais antigas do PHP, que exigiam correções de segurança fornecidas por mantenedores terceirizados.
Trabalhamos com a Freexian, nossa fornecedora de pacotes PHP, para obter pacotes corrigidos para as versões do PHP utilizadas em nossa plataforma, incluindo versões mais antigas com suporte de longo prazo.
Os pacotes foram disponibilizados progressivamente, e não todos de uma vez. À medida que cada pacote compilado era disponibilizado em nosso repositório espelho, nossa equipe de engenharia o validava e iniciava a implementação, sem esperar que todas as versões do PHP estivessem prontas.
Veja como a implementação avançou:
| Data e hora (UTC) | O que aconteceu |
|---|---|
| 21 de outubro, ~14h–17h45 | O PHP lançou as correções de segurança. O PHP 8.5.12 ficou disponível em nosso repositório espelho de pacotes às 14h24, e a implementação começou às 15h54. Até as 17h45, dezenas de milhares de contêineres haviam sido atualizados. |
| 21 de outubro, 18h50–19h04 | O PHP 8.3.36 ficou disponível, e sua implementação começou em paralelo à do PHP 8.5. |
| 21 de outubro, 21h17–22h28 | Os pacotes corrigidos para PHP 7.4, 8.0 e 8.1 ficaram disponíveis, e novas implementações começaram às 22h28. |
| 21–22 de outubro, 23h25–01h37 | Os pacotes para PHP 8.2 e 8.4 chegaram às 23h25, e a implementação começou à 1h37 de 22 de outubro. |
| 22 de outubro, 04h31 | Apenas 1.888 contêineres, aproximadamente 0,5% do total, ainda precisavam ser atualizados e exigiam atenção adicional. |
| 22 de outubro, 08h26 | Confirmamos 100% de cobertura de proteção e declaramos o incidente resolvido. |
A capacidade de implementar alterações nessa escala foi uma das partes mais importantes da nossa resposta.
Farkas destacou a rapidez com que a equipe conseguiu implementar alterações em toda a infraestrutura:
“Essa é a parte da qual mais me orgulho. Depois que uma alteração é validada e sabemos que ela não causará problemas, conseguimos implementá-la em toda a infraestrutura em poucas horas.”
Essa capacidade permitiu que nossa equipe implementasse pacotes corrigidos do PHP em centenas de milhares de contêineres em questão de horas.
Também não precisamos coordenar as atualizações do PHP individualmente com os clientes. A Kinsta gerencia o PHP no nível da plataforma. Assim, depois que a equipe de engenharia validava um pacote atualizado, podíamos implementá-lo nos ambientes afetados sem solicitar que os proprietários dos sites instalassem as atualizações por conta própria.
Por que versões mais antigas do PHP precisavam de correções adicionais
A implementação também precisou considerar a diferença entre as versões oficialmente suportadas pelo PHP e as versões mais antigas mantidas por fornecedores terceirizados.
O projeto PHP lançou atualizações de segurança para as versões 8.2 a 8.5. Versões como PHP 7.4, 8.0 e 8.1 já não recebiam atualizações regulares de segurança diretamente do projeto PHP, embora fornecedores de suporte de longo prazo pudessem disponibilizar correções adaptadas para essas versões.
O backporting permite que os mantenedores apliquem correções de segurança a uma versão mais antiga de um software sem exigir que os usuários atualizem para uma versão mais recente do PHP.
Isso significava que podíamos implementar atualizações de segurança nesses ambientes PHP mais antigos à medida que a Freexian disponibilizava os pacotes corrigidos.
Isso também explica por que apenas o número da versão do PHP nem sempre indica se uma determinada correção de segurança foi aplicada. Os pacotes mantidos por fornecedores podem incluir correções de segurança sem apresentar o mesmo número de versão dos lançamentos oficiais do PHP.
Durante toda a implementação, continuamos aplicando as atualizações e mantendo as proteções adicionais de firewall e configuração.
Monitorando ataques e verificando sinais de comprometimento
A implementação das correções foi apenas uma parte da resposta. Nossa equipe também precisava determinar se alguma das tentativas de exploração observadas havia sido bem-sucedida.
Quando identificamos as primeiras atividades direcionadas aos sites hospedados na Kinsta, nas primeiras horas de 21 de outubro, nossos engenheiros investigaram manualmente os sites envolvidos.
Eles continuaram monitorando o tráfego suspeito e realizando verificações pontuais nos ambientes de hospedagem durante todo o incidente, procurando sinais de que os invasores tivessem explorado as vulnerabilidades com sucesso.
Os eventos de segurança do Cloudflare nos ajudaram a entender quais eram os alvos dos ataques e como os padrões de ataque mudavam à medida que disponibilizávamos novas regras. No entanto, apenas a quantidade de solicitações bloqueadas não permitia determinar se algum ataque havia sido bem-sucedido.
Por isso, as verificações manuais foram importantes. Nossa equipe também manteve contato próximo com a Patchstack, nossa parceira de Proteção contra vulnerabilidades, compartilhando informações sobre as ameaças e os padrões de ataque observados pelas duas equipes. Também participamos de discussões com outros provedores de hospedagem para trocar informações e boas práticas enquanto a comunidade PHP respondia ao incidente.
Essas iniciativas complementaram nosso trabalho com o Cloudflare e a Freexian. O Cloudflare forneceu proteções contra tentativas de exploração, a Freexian disponibilizou os pacotes corrigidos do PHP e a colaboração com parceiros de segurança ajudou nossos engenheiros a compreender como a ameaça estava evoluindo.
Durante todo o incidente, não encontramos evidências de invasões bem-sucedidas relacionadas ao PHP2Shell.
Essa conclusão se baseia no monitoramento e nas investigações realizadas durante a resposta. Isso não significa que não houve ataques, como demonstram os dados do firewall. Significa que nossas verificações não identificaram sinais de comprometimento bem-sucedido.
Resolvendo o incidente e continuando as verificações
Em 22 de outubro, às 08h26 UTC, declaramos o incidente de segurança do PHP resolvido em nossa página pública de status.
Naquele momento, já havíamos implementado as atualizações de segurança em toda a plataforma, e todos os sites estavam protegidos por uma combinação de correções e medidas de mitigação.
A resolução do incidente não significou o fim das verificações. Nossa equipe continuou verificando os ambientes e monitorando as proteções após o encerramento público do incidente.
Isso foi importante em uma implementação que envolveu várias versões do PHP e centenas de milhares de contêineres. Às 04h31 UTC, cerca de 0,5% dos contêineres ainda exigiam atenção adicional. Nossos engenheiros continuaram trabalhando nesses ambientes restantes e verificando os resultados, em vez de considerar a disponibilidade de um pacote corrigido como prova de que todas as instalações haviam sido atualizadas.
As regras do Cloudflare e as proteções de configuração do PHP também permaneceram ativas durante esse trabalho de verificação.
Os clientes não precisaram instalar as correções de segurança do PHP manualmente nem mudar a versão do PHP.
Respondendo aos clientes que adotaram precauções adicionais
A resposta ao PHP2Shell foi muito além dos provedores de hospedagem. À medida que as notícias sobre as vulnerabilidades se espalhavam, órgãos governamentais e outras organizações em todo o mundo começaram a tirar sites do ar temporariamente enquanto preparavam as atualizações de segurança.
Nos Países Baixos, o Centro Nacional de Segurança Cibernética retirou seu próprio site do ar como medida preventiva. Sites governamentais da Alemanha, França, Bélgica e Finlândia também foram temporariamente desativados. No Japão, a primeira-ministra Sanae Takaichi publicou um alerta urgente no X, recomendando que os responsáveis pelos sites aplicassem as correções o mais rápido possível ou suspendessem temporariamente os serviços caso não conseguissem realizar a atualização imediatamente.
Na Kinsta, observamos preocupações semelhantes entre nossos clientes. Nossa equipe de Suporte recebeu um volume significativamente maior de perguntas sobre o PHP2Shell, e alguns clientes começaram a adotar precauções adicionais para proteger seus sites.
Essas medidas incluíam utilizar o recurso de suspensão de ambientes do MyKinsta para tirar sites do ar, habilitar verificações em todo o site por meio da Proteção contra bots ou solicitar ao Suporte o bloqueio do tráfego de entrada no nível do servidor. Durante o incidente, os clientes suspenderam preventivamente aproximadamente 3.000 sites.
Considerando a gravidade das vulnerabilidades e as precauções adotadas em outros lugares, essas decisões eram compreensíveis. No entanto, a equipe de Engenharia não recomendou que os clientes tirassem do ar seus sites hospedados na Kinsta. Já havíamos habilitado as regras emergenciais do WAF do Cloudflare em toda a nossa plataforma de hospedagem. Assim, os sites que permaneceram on-line continuaram recebendo essas proteções sem ficar indisponíveis para os visitantes.
Nossa equipe de Suporte começou a orientar os clientes a evitar suspensões desnecessárias, enquanto a equipe de Engenharia continuava implementando as correções do PHP.
Depois de implementar as atualizações de segurança, revisamos as ações de suspensão realizadas durante o incidente para identificar os sites que os clientes haviam tirado do ar especificamente por causa do PHP2Shell.
Em seguida, nossa equipe reativou esses ambientes, mantendo suspensos os sites que haviam sido desativados por outros motivos. Isso exigiu distinguir as suspensões preventivas daquelas realizadas intencionalmente por outros motivos, em vez de simplesmente restaurar todos os ambientes que haviam sido tirados do ar.
Além de bloquear ataques e implementar correções, nossas equipes também precisaram ajudar os clientes a reverter as medidas preventivas que haviam adotado durante o incidente.
O que a resposta significou para os clientes da Kinsta
O PHP2Shell exigiu coordenação entre as equipes de Engenharia e Suporte, além de vários parceiros externos de segurança e infraestrutura. No entanto, a própria plataforma ficou responsável pela aplicação das correções.
Os clientes não precisaram acompanhar a disponibilização de cada atualização do PHP, determinar qual pacote corrigido seus sites exigiam nem instalar as atualizações por conta própria.
Farkas explicou o que essa resposta representou, em última análise, para os clientes da Kinsta:
“Para mim, a principal mensagem é que os clientes não precisaram se preocupar com nada disso: o que atualizar, quando ou como. Eles já estavam protegidos pela nossa plataforma.”
A reação dos clientes durante o incidente também demonstrou por que era importante comunicar essas proteções. Alguns clientes tiraram seus sites do ar mesmo com as regras emergenciais do WAF já ativas, e nossas equipes trabalharam mais tarde para restaurar os ambientes suspensos devido às vulnerabilidades.
Enquanto isso, nossa equipe de engenharia implementou as atualizações de segurança do PHP em centenas de milhares de contêineres, sem exigir que os clientes gerenciassem as alterações.
Para consultar o registro das atualizações de segurança e da resolução do incidente, confira nosso relatório do incidente de segurança do PHP.
Para saber o que essas vulnerabilidades significam para seu site, leia nosso artigo complementar, PHP2Shell: como a Kinsta protegeu os sites WordPress.
