> ## Content Index > Fetch the complete content index at: https://teg6.com/llms.txt > Use this file to discover other available public pages before exploring further. # PHP2Shell: falhas críticas no PHP exigem atualização imediata - URL: https://teg6.com/php2shell-falhas-criticas-php-atualizacao-urgente/ - Published: 2026-10-21T18:01:33.000Z - Updated: 2026-10-21T18:16:51.000Z - Description: Duas falhas críticas no PHP permitem execução remota sem login. Veja as versões corrigidas, os riscos e os limites das medidas temporárias. - Author: Elton Ciatto - Tags: Segurança, Notícias O projeto PHP publicou nesta quarta-feira, 21 de outubro, atualizações emergenciais para corrigir duas vulnerabilidades críticas que podem permitir a execução remota de código sem autenticação. A orientação dos mantenedores é atualizar imediatamente os ambientes afetados. As correções estão disponíveis nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35\. [Comunicado oficial do PHP](https://www.php.net/archive/2026.php?ref=teg6.com#2026-10-21-5). Conhecidas em conjunto como PHP2Shell, as falhas receberam os identificadores CVE-2026-109618 e CVE-2026-109619\. Ambas têm classificação crítica e pontuação 9,2 no CVSS 4.0\. O problema exige atenção de equipes responsáveis por sites, plataformas corporativas e produtos que incorporam o PHP, mesmo quando essa dependência não aparece diretamente para o usuário. [Primeiro advisory do PHP](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=teg6.com) e [segundo advisory do PHP](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp?ref=teg6.com). ## Quem descobriu as falhas e como a investigação aconteceu A identificação do PHP2Shell reuniu pesquisas independentes e um trabalho anterior de auditoria. A PHP Foundation destaca Ryan A., da Calif, e Amy Burnett, da equipe OpenAI Codex Security, além da Wiz. Segundo a fundação, Calif e OpenAI reportaram a mesma raiz do problema de falta de memória em 11 de agosto de 2026\. Novos caminhos de ataque foram comunicados pela Wiz em 24 de agosto e pela OpenAI em 18 de setembro. [Relato da PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/?ref=teg6.com). Na Wiz, a publicação é assinada por Sagi Tzadik, Shir Tamari, Nir Ohfeld e Tomer Schwartz. A empresa informa que usou Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol na pesquisa. O processo combinou análise do funcionamento do PHP, testes e depuração repetidos para entender o comportamento da memória e demonstrar execução remota em aplicações de laboratório, incluindo WordPress, Drupal e Joomla. A cronologia da Wiz registra a primeira descoberta em 19 de agosto e o envio do relatório ao PHP cinco dias depois. [Pesquisa da Wiz](https://www.wiz.io/blog/php2shell-php-rce?ref=teg6.com). A OpenAI confirma o uso de GPT-5.6 Sol pela Calif no programa Patch the Planet e a descoberta independente das vulnerabilidades pela Wiz. Os mantenedores do PHP lideraram as correções e os lançamentos. [Relato da OpenAI](https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/?ref=teg6.com). Há um antecedente importante: os primeiros sinais do defeito de falta de memória foram identificados em 2024 por um desenvolvedor do núcleo do PHP, durante o trabalho de correção de um achado da auditoria realizada pela Quarkslab. Na época, ainda não havia um caminho concreto demonstrado para execução remota. A pesquisa de 2026 tornou esse impacto verificável e elevou a correção à prioridade máxima. [Histórico explicado pela PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/?ref=teg6.com). ## O que as duas vulnerabilidades permitem A CVE-2026-109618 envolve o tratamento de situações de falta de memória. Em determinadas condições, o processamento é interrompido quando dados internos de uma requisição ainda não foram completamente inicializados. A etapa de encerramento pode interpretar esse estado inválido como legítimo, abrindo caminho para execução de código. [Advisory da CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=teg6.com). A CVE-2026-109619 está relacionada a informações internas que continuam sendo referenciadas depois que a memória correspondente foi liberada. Quando o mesmo processo atende outra requisição, esse estado antigo pode ser utilizado antes da reinicialização adequada. A exploração depende das operações, extensões e configurações envolvidas. [Advisory da CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp?ref=teg6.com). No caso de uma exploração bem-sucedida, o código é executado com os privilégios da conta usada pelo processo web. Isso pode comprometer informações e recursos acessíveis à aplicação. O advisory da primeira falha confirma execução remota por HTTP em Apache com mod\_php e ressalta que a confiabilidade do ataque varia conforme a compilação, as extensões e o ambiente. [Detalhes de impacto](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=teg6.com). ## Quem precisa verificar seus sistemas O alerta do PHP abrange instalações que processam requisições web, incluindo PHP-FPM, Apache com mod\_php, php-cgi, FrankenPHP e LiteSpeed. O risco é considerado maior em mod\_php, onde foi demonstrado um ataque que ocorre antes da execução do código da aplicação. [Orientação dos mantenedores](https://www.php.net/archive/2026.php?ref=teg6.com#2026-10-21-5). Essa diferença entre ambientes não torna o PHP-FPM imune. O segundo advisory descreve um caminho validado nessa arquitetura que depende de uma operação adequada na aplicação, seguida de erro fatal e reutilização de estado em outra requisição. A avaliação precisa considerar como cada serviço está configurado. [Análise do PHP-FPM](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp?ref=teg6.com). O inventário também deve alcançar imagens de contêineres, interfaces de administração, equipamentos e softwares de terceiros que tragam seu próprio PHP. O NCSC dos Países Baixos destaca que, nesses produtos, o administrador pode depender de uma atualização do fornecedor. [Orientações operacionais do NCSC](https://github.com/NCSC-NL/php2shell?ref=teg6.com). ## Impacto mundial: serviços públicos fora do ar e atualizações emergenciais O PHP2Shell provocou interrupções preventivas e mobilizou fornecedores de infraestrutura em diferentes países. O impacto documentado inclui serviços retirados do ar, atualizações emergenciais e tentativas de ataque observadas por empresas de segurança. Nos Países Baixos, o governo confirmou que Overheid.nl, MijnOverheid.nl e DigiD foram retirados do ar por precaução. O comunicado de 21 de outubro, publicado às 15h13 no horário local, registrava a decisão de reduzir a exposição enquanto a correção era aguardada. A nota também esclareceu que muitos sites governamentais, incluindo Rijksoverheid.nl, não utilizavam PHP e não eram afetados por essas falhas. [Comunicado do governo neerlandês](https://www.rijksoverheid.nl/actueel/nieuws/2026/10/21/aantal-websites-rijksoverheid-preventief-offline-na-kwetsbaarheden-php?ref=teg6.com). A Wikimedia Foundation desligou deliberadamente serviços de apoio, incluindo Toolforge e Cloud VPS, e alertou para possíveis indisponibilidades dos wikis durante as atualizações. Trata-se de impacto operacional confirmado, sem indicação de invasão nesse comunicado. [Nota da Wikimedia Foundation](https://diff.wikimedia.org/2026/10/21/impact-of-php-vulnerabilities-on-wikimedia-tools-and-services/?ref=teg6.com). No Japão, a Sakura Internet suspendeu as interfaces web phpMyAdmin, phpPgAdmin e pgAdmin de seu Database Appliance. O Database Cluster ficou fora do escopo dessa suspensão. A medida atingiu funcionalidades administrativas, conforme a descrição da própria empresa. [Aviso da Sakura Cloud](https://cloud.sakura.ad.jp/news/2026/10/21/database-appliance-feature-suspension/?ref=teg6.com). ## Como as grandes empresas de tecnologia reagiram A Cloudflare informou ter observado tráfego de ataque contra clientes e tentativas de modificar as requisições para contornar suas proteções. A empresa ativou regras de firewall de aplicações web às 03h02 UTC de 21 de outubro, inclusive para clientes de planos gratuitos. O registro confirma tentativas de exploração; o comunicado não apresenta um total de invasões bem-sucedidas. [Relato da Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection?ref=teg6.com). O Google Cloud afirmou que sua plataforma em si não é vulnerável, mas que aplicações PHP executadas pelos clientes podem estar expostas. A companhia disponibilizou imagens corrigidas e instruções de atualização e reimplantação conforme o serviço utilizado. [Orientações do Google Cloud](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619?ref=teg6.com). Wiz também cita AWS, Microsoft, Google Cloud, Automattic, Fastly, Akamai, Imperva e Vercel entre os parceiros que prepararam orientações, mecanismos de detecção e mitigações antes da divulgação. Essa participação descreve uma resposta defensiva coordenada e não comprova que essas empresas foram invadidas. [Relato dos pesquisadores da Wiz](https://www.wiz.io/blog/php2shell-php-rce?ref=teg6.com). ## E os bancos e o Brasil? Até a conclusão desta apuração, não foi encontrada confirmação pública de banco específico invadido ou com serviços interrompidos por PHP2Shell. Também não há, nas fontes consultadas, uma estimativa consolidada de prejuízos financeiros globais. A exposição precisa ser avaliada por sistema e fornecedor; a ausência de um caso divulgado não permite concluir que todo o setor esteja protegido. No Brasil, o CTIR Gov, ligado ao Gabinete de Segurança Institucional, publicou a Recomendação 19/2026 em 21 de outubro. O órgão orientou atualização imediata e avaliação de isolamento temporário das aplicações expostas à internet quando a correção não pudesse ser aplicada. O documento é um alerta técnico e não relata comprometimento de instituição brasileira. [Recomendação do CTIR Gov](https://www.gov.br/gsi/pt-br/assuntos/ctir/recomendacoes/2026/recomendacao-19-2026?ref=teg6.com). ## Quais versões instalar Os pontos de correção nas quatro linhas são: - PHP 8.5: versão 8.5.12 - PHP 8.4: versão 8.4.27 - PHP 8.3: versão 8.3.36 - PHP 8.2: versão 8.2.35 Distribuições Linux e fornecedores de suporte prolongado podem distribuir pacotes com correções retroportadas. Por isso, a confirmação deve incluir o boletim do fornecedor. PHP 8.1 e versões anteriores estão fora do suporte regular do projeto; excepcionalmente, foram disponibilizadas correções mínimas em código-fonte para 7.4, 8.0 e 8.1\. Isso não representa a retomada do suporte dessas linhas. [Resumo de atualização do NCSC](https://github.com/NCSC-NL/php2shell?ref=teg6.com). ## Mitigações temporárias têm limites O CERT-EU recomenda considerar o isolamento de aplicações expostas à internet quando a atualização imediata não for viável. A orientação é manter essa proteção até que a correção tenha sido aplicada e verificada. [Recomendação do CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/?ref=teg6.com). Existem ajustes temporários para reduzir caminhos específicos de exploração, como desativar o acompanhamento de uploads por sessão e reiniciar todos os processos PHP. Os documentos também detalham cuidados com limites de memória e requisições. Essas medidas exigem avaliação técnica: nenhuma configuração temporária cobre todas as variantes, e apenas atualizar oferece a correção completa. [Medidas temporárias oficiais](https://cert.europa.eu/publications/security-advisories/2026-018/?ref=teg6.com). ## Alerta grave não comprova uma invasão Provas de conceito demonstram que uma vulnerabilidade pode ser explorada em determinadas condições. Elas não comprovam, por si só, que uma organização foi invadida. Da mesma forma, a decisão de retirar um serviço do ar preventivamente precisa ser distinguida de uma interrupção causada por ataque. O CERT-EU alerta para a circulação de provas de conceito e para o risco de exploração, sem apresentar nesse boletim uma lista de governos comprometidos. [Situação descrita pelo CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/?ref=teg6.com). ## Plataformas também precisam ser atualizadas O Coolify é um exemplo de software que já incorporou a correção: a versão 4.4.7 atualiza o PHP para 8.4.27 e cita as duas CVEs nas notas de segurança. [Release oficial do Coolify](https://github.com/coollabsio/coolify/releases/tag/v4.4.7?ref=teg6.com). Para quem administra infraestrutura, a recomendação prática é registrar cada ambiente afetado, aplicar o pacote adequado e confirmar qual runtime está realmente atendendo às requisições após a mudança. Atualizar uma plataforma de gestão não deve ser tomado como confirmação automática de que todas as aplicações hospedadas nela também receberam um PHP corrigido. Cada componente precisa de verificação própria.