O PHP2Shell explodiu: CVSS 9.2, um dia antes da abertura, e os dois buracos estavam em código por 10 anos.

Em primeiro lugar, a conclusão é que:PHP produziu um código remoto não autorizado para CVSS 9.2, números CVE-2026-109618 e CVE-2026-109619, com um apelido PHP2Shell. Em 20 de outubro, foi tornado público e em 21 de outubro, em 1400 UTC patches foram lançados, enquanto os recipientes de mel da Amazon foram gravados em 17 de outubro — quatro dias antes da abertura.

O que é pior do que isso é a outra coisa: esses dois buracos são os primeiros a chegar ao PHP 5.4, o que significa...Estão em código há mais de uma década.Não sei. E em 2024, quando a auditoria do desenvolvedor principal do PHP descobriu o caminho da OOM, a equipe se reuniu para discutir como corrigi-lo.Não concordámos e depois não o resolvemos.Não sei. A razão é que ninguém pensou que poderia realmente ser usado.

Esta frase agora parece particularmente irônica. A razão para não ser capaz de fazê-lo não é que o buraco é insignificante, mas que a cadeia é muito complexa para ir além da capacidade física dos pesquisadores humanos. Então a IA veio e escreveu.

Primeiro, tire a palavra "resposta multinacional de emergência" do caminho. Olha.

A palavra favorita da festa é "alarme global". Não é exagero desta vez, mas é uma pontuação clara.

• Oficial do PHP: Um aviso prévio foi emitido em 20 de outubro, afirmando que em 21 de outubro às 14:00 UTC seria lançado em uma versão segura se os detalhes foram vazados ou aterrados. Como resultado, o número CVE foi esfaqueado para Hacker News no mesmo dia, e o lançamento previsto para 22 de outubro foi forçado a um dia antes.
• CERT-UE: release advisory 2026-018 e incluem ambos os CVEs.
• CloudflareEm 21 de outubro, o CTO Dane Knecht disse diretamente que "o ataque precoce foi visto emergindo", e as regras da WAF foram lançadas na íntegra, incluindo usuários livres. Mas ele enfatizou-se que era apenas paralisação, e a solução real era remendar.
• Informações sobre ameaças da Amazon: As latas de mel MadPot foram capturadas tentando em 17 de outubro, e outro lote foi pego em 21 de outubro, e a carga útil e infraestrutura apontou para uma série de diferentes atacantes. php2shell "é já amplamente utilizado".
• Ver o Reboque: Ambos os buracos são re-emergidos, enquanto tentativas de explorar ambos são observados.

Então "o ataque foi encontrado" não é uma representação, mas um fato. E a Resposta Multinacional de Emergência não é um golpe -- é que os principais temas da resposta são fabricantes, CDNs e organizações de emergência, não qualquer governo no país.

Dois, dois buracos, duas formas completamente diferentes de morrer.

Muitas pessoas acham que é um buraco com dois números, não. Estas são duas rotas de ataque separadas, cada CVSS 9.2.

CVE-2026-109618: Bomba quando a memória está esgotada

O processamento de uma requisição é interrompido quando a distribuição de memória PHP falha. O problema é:Neste ponto, os dados de solicitação interna podem ter sido apenas meio-inicializados, e a lógica de limpeza subsequente teria usado este pedaço não incorporado de dados ruins como dados válidos.

O método de gatilho é simples: construir uma solicitação multiparte para implodir a memória. O estranho é que...O tamanho do pedido parece corresponder ao seu tecto.Não é o tamanho máximo do post, é o decodificamento e o consumo de processamento interno.

O pior é mod php. Mod php para Apache ao solicitar a inicialização falhouAinda vai limpar., para que esta cadeia possa ser concluída antes de qualquer código aplicável ser executado. Seu código PHP é tão limpo, não há brecha, não há como pará-lo.

PHP-FPM irá matar o trabalhador quando ele não começar, apenas para cortar a cadeia, então oficialmente, mod php é o maior risco. Mas preste atenção -- isso não significa que o MPF esteja seguro.Após a inicialização bem- sucedidaAinda há uma possibilidade de exploração.

CVE-2026-109619: Estado sujo entre pedidos

Este é pior. O PHP reutilizará o processo do worker para processar várias solicitações. O último pedido para liberar a memória, o ponteiro permanece no estado interno; o próximo pedido entra,Leia o endereço em branco antes da inicialização normal.Não sei.

Erros fatais (depleção da memória, tempo limite de desempenho) interrompem a limpeza do estado. Pior ainda, algum diagnóstico não letal durante o desligamento teria substituído o estado errado.Refaz.Não sei.

As vias oficialmente confirmadas incluem: RCEs com erro fatal quando o PHP 8.5 ativa os backtraces de erro fatal (abertura padrão) e o ciclo de vida da sessão RCEs no php motor e FPM.session.upload_progress Por padrão, você pode agir como um consumidor precoce em um estado de sujeira.E não há necessidade de aplicar chamadasNão sei.

Este buraco ainda está preso.Vazamento de memóriaNão sei. O que estava a vazar? é a senha, token, chave API, certificado para outras solicitações na memória do processo. Wiz diretamente comparado com Heartbled, que não é muito.

Linha do tempo, mais do que olhar título.

Hora	O que aconteceu?
Ano 2024	A auditoria do desenvolvedor principal do PHP encontrou OOM, que bug, a equipe não tinha consenso sobre a lei, colocá-lo em espera.
2026-08	Ryan Austin da Califórnia identifica brechas com OpenAI GPT-5.6 Sol; Wiz Independent Discovery
2026-10-17	Amazon MadPot, o mel pode gravar uma tentativa, quatro dias antes da abertura.
2026-10-20	Número CVE vazado em Hacker News e Social Media, PHP
2026-10-21	14:00 UTC Publicação 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35

17 de Outubro deve ser escolhido.O dia público foi dia 20, mas o ataque ocorreu no dia 17.A proposta da Amazon é direta: o ponto de partida não deve ser na data de divulgação, mas deve ser encaminhado para pelo menos 17 de outubro.

Quanto a como os atacantes conseguiram as informações com antecedência, o Amazonas disse "não claro". Não posso entrar nisto, mas tens de aceitar uma realidade.O dia da revelação nunca foi o dia do ataque, mas o dia em que finalmente soubeste.

Quatro, desta vez é mesmo IA.

O blog de Wiz contém uma frase que li duas vezes: “Essas falhas subjacentes existem há décadas, mas para provar que podem ser usadas, precisam de uma cadeia de passos excepcionalmente complexa, à margem das capacidades reais dos pesquisadores humanos.O modelo de IA de linha de frente reduz significativamente esse limiar.Não sei.

Específico: Ryan Austin, pesquisador do Calif, foi encontrado no projeto OpenAI "Patch the Planet" com GPT-5.6 Sol. Wiz encontrou o mesmo problema independentemente. Para fazer uso dele, precisamos de uma cadeia de falhas e de atingir cada alvo.Disposição da memória calibrada repetidamenteWiz diz que o modelo de linha de frente permite que eles desenvolvam aplicações utilizáveis para diferentes aplicações dentro de horas.

Não significa que a IA ganhou outra vez.O ponto é que o fosso do "complexo" está falhando.

Muitas velhas lacunas não foram superadas nas últimas duas décadas, não porque não sejam sérias, mas porque o limiar de utilização é muito alto — algumas semanas de investimento por pesquisadores de topo e um pouco de sorte. Então coloca-os na coluna "teoricamente arriscados". Agora esta vedação desapareceu.

Esses buracos de dez anos de idade que estão no seu sistema e são avaliados como "difíceis e não processados" têm de ser reavaliados.

Cinco, para qual deles deves ir?

Ramo	Versão afetada	Eliminação
PHP 8.5	< 8.5.12	Aumento para 8,5.12.
PHP 8.4	< 8.4.27	Aumento para 8.4.27.
PHP 8.3	< 8.3.36	Aumento para 8.3.36.
PHP 8.2	< 8.2.35	Aumentar para 8.2.35.
PHP 7.4 / 8.0 / 8.1	Tudo	Oficialmente não publicado, apenas o nível de fonte
PHP 5.4 – 7.3	Tudo	EOL, o governo não resolve isso. Negócios

Vários lembretes da vida real:

• Linux Release e LTS FornecedorTenho um remendo adiantado.Verifique o aconselhamento do seu fabricante com um pacote de distribuição. Não apresses o código-fonte.
• Utilização rpms.remirepo.net Nota: PHP declarou oficialmente a fonte em 21 de outubro.Sem atualizaçãoEntão você pode mudar para um pacote de distribuição ou fazê-lo a partir do código fonte.
• O binário Windows do PHP 8.5 também está na página oficial de download.
• Não pense que está tudo bem correr no recipiente -- a versão PHP do espelho do recipiente tem que ser verificada.

Seis, se não conseguires um remendo, faz estes quatro primeiro.

Primeiro estado:Nenhum destes abaixo vai torná-lo seguro.A frase oficial do PHP é "reduzir a exposição a caminhos de ataque específicos, mas não tornar as instalações mais seguras". O valor deles é dar-lhe tempo para obter patches.

Definir o limite de memória para -1

Objetivo: Para eliminar o previsível cap de memória PHP falhou, ou seja, CVE-2026-109618 confirmou a condição de gatilho da qual depende.

A questão é,Como?: para ser definido em locais onde a aplicação não é alterada, como o FPM Pool php_admin_value ou Configuração Apache. Você deve verificar se não há pops, diretórios, configurações de aplicativos para adicionar o limite de volta.Em seguida, reinicie cada trabalhador.

O preço é claro: você está fora da cerca de memória do PHP, e a falha de distribuição inferior ainda pode estar nesse caminho perigoso. Então tem que ser um recipiente ou um grupo para limitar a capa -- mas é apenas uma estratégia para "matar pessoas afetadas".Nunca utilize RLIMIT AS ou RLIMIT DATAEsses dois são precisamente o tipo de falhas de distribuição que criam as lacunas.

Reduzir o tamanho máximo pós

Sites sem arquivo 8M para arquivo 32M e garantido upload_max_filesize Menos que isso. Ao mesmo tempo, são adicionados limites ao servidor web ou camada proxy - o volume de solicitações decodificadas, o número de campos, o número de partes múltiplas, o número de cabeças, a profundidade de ninhos.Estas restrições devem abranger pedidos que não sejam válidosOu vamos dar a volta.

3. Desligando o processo session.upload

session.upload_progress.enabled = 0

É escrito em php.ini, ferramenta FPM ou configuração do servidor.Tem de ser eficaz antes do pedido.Não sei. Utilização ini_set() Ou FPM. .user.ini Era tarde demais. Estava sujo. A mudança também é para reiniciar todo o workker.

PHP 8.5 Mais um single

fatal_error_backtraces = 0

Este bloco só confirmou os erros fatais, sem outras variantes. Também requer configurações de nível de administrador + reiniciar o workker.

Além disso, o oficial menciona que muitos ignorarão:Corrigir os erros fatais que os atacantes podem desencadear e executar o tempo., incluindo backup, upload, processamento de importação, falhas de limpeza. E...Excluir configurações desatualizadas ou ilegais impostas a pedidoEles cuspiram informações de diagnóstico antes de inicializar e alimentar a fuga.

Esta última frase é mais facilmente mal compreendida:Não funciona para esconder o diagnóstico com relatórios de erro, erros de exibição ou @.Não vai acontecer.

VII. REAL LIÇÕES DESTA

Não quero terminar escrevendo "Fechar o patch". Claro que é. É hoje. Mas alguns julgamentos têm de mudar.

1. O termo "difícil de usar" não é mais o mesmo que "prescrito".PHP a cadeia de acesso deste buraco é complicada o suficiente para precisar da ajuda da IA, que já ajudou. Os buracos antigos na sua lista de ativos que marcam "risco teórico" devem ser reavaliados.
2. A linguagem funciona num único ponto.WordPress, Drupal, Joomla, Magento, MediaWiki todos executados no PHP, sua auditoria de código de aplicação está limpa, eo núcleo PHP está em apuros. Ritmo compensatório de camadas de infraestrutura, com camadas de aplicação separadas.
3. "O código da aplicação está quebrado sem correr." O WAF só pode atrasar.O próprio Cloudflare disse que era stopgap. Colocar o WAF como solução equivale a dar vida à cobertura das regras.
4. Há muitos sites antigos no país usando PHP.As estações que funcionam no PHP 5.6/7.0, que foram há muito tempo não mantidas e penduradas em um mainframe de nuvem, estão nessa exposição de 1,3 a 1,9 milhões. Eles não receberão qualquer aviso.

Calibrações de dados são registradas: W3Techs diz que PHPs representam 69,3 por cento das línguas conhecidas pelo serviço, e Wiz 70 por cento; hospedeiros de exposição, o pesquisador de segurança Silas Cutler estima que mais de 1,3 milhões, e a busca Shodan de Henk Poley é mais de 1,9 milhões. Estes números são de diferentes calibres e não os usam como valores precisos, mas a escala é a mesma -Milhões, globalmente.

Mais um detalhe vale a pena lembrar: quando o número CVE foi vazado, os pontos CVSS que saíram foram 10.0, PHP foi oficialmente confirmado.Essa pontuação estava errada.Na verdade, é 9.2. Ninguém saberia nada sobre este detalhe, mas estará sempre em circulação. Vendo 10.0, você sabe que onda é.

Um buraco de 10 anos, dois meses de pesquisa assistida por IA, quatro dias de utilização precoce, janela de um dia. Esta escala de tempo é o normal de todo o software básico que segue.

Verifique a versão agora.php -vOu olhe para o seu recipiente espelhos na etiqueta. Não esperes por amanhã.