Mil e quatrocentas horas, e os sites já às escuras
A hora era precisa, e não é assim que as emergências costumam anunciar-se. Na quarta-feira, 21 de outubro de 2026, às 14:00 UTC, o PHP ia publicar uma atualização de segurança para duas vulnerabilidades críticas. A hora foi enviada para a própria lista de anúncios da linguagem, recolhida por investigadores, assinalada num post de Dane Knecht e repetida por meios que pediam aos administradores para se prepararem. A Huntress, numa nota de resposta rápida, descreveu falhas críticas vazadas e deu-lhes números: CVE-2026-109618 e CVE-2026-109619. A PC Gamer, um improvável jornal de referência para uma crise de runtime, disse aos administradores web para aguentarem e para esperarem atualizações de emergência que tapariam exploits vazados.
Quando essa hora chegou, uma parte da web já tinha escolhido a escuridão. Vários sites importantes tinham sido retirados do ar por causa de uma vulnerabilidade crítica no PHP. A BBC noticiou sites desligados em todo o mundo à medida que a atualização de cibersegurança era emitida. Não são exatamente a mesma afirmação que o conselho que viajou com elas, e a diferença merece ser guardada. Autoridades dos Estados Unidos, da Europa e do Reino Unido recomendaram que os sites saíssem temporariamente do ar até poderem ser corrigidos. Uma recomendação não é uma interrupção. Uma interrupção, no relato do Brussels Times e no da BBC, já era o facto noticiado do dia: sites retirados do ar no meio de receios de segurança, sites desligados enquanto a atualização saía. Vista de fora, a imagem era a de um patch com hora marcada e de uma web que começara a escurecer antes de se poder dizer que os pacotes tinham chegado.
No Japão, o escurecimento tinha nomes. A Gigazine noticiou que NicoNico, pixiv e vários outros sites e aplicações tinham entrado em manutenção para receber o patch de emergência. A ITmedia registou manutenção de emergência em CoDMon, Shadowverse: Worlds Beyond, o servidor de aluguer da Sakura, BASE, pictSQUARE, 킴블, X Server e つなぐ. Nada nesses avisos, no material aqui reunido, é uma confissão de que um intruso já estava lá dentro. Lêem-se como um juízo: estar acessível, nas horas em torno da correção, tornara-se o estado mais arriscado. A equipa de segurança do PHP avisara os administradores, no dia anterior, para se prepararem para atualizações de emergência que tratariam de duas vulnerabilidades críticas. A equipa anunciou a descoberta de duas falhas graves, e os patches ficaram marcados para 21 de outubro. Os maintainers planeavam-nos para vulnerabilidades com classificações de gravidade de 9,2 em 10.
Quando os pacotes foram publicados, tinham versões. PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem duas vulnerabilidades críticas que podem permitir execução remota de código sem autenticação. O National Cyber Security Centre e a BBC enquadraram a atualização nos termos mais amplos disponíveis: um problema crítico que pode permitir a atacantes executar comandos em qualquer servidor web a correr PHP. O episódio já tinha um nome, PHP2Shell, e o nome fazia o trabalho de um título. A Watchtowr usou-o. A Huntress usou-o. A Amazon usou-o a propósito de uma tentativa de exploração. A Wiz usou-o a propósito de uma descoberta de investigação no núcleo da linguagem.
A história pública era um lançamento controlado a uma hora publicada. A história da telemetria era uma tentativa que não esperou pelo anúncio.
A Amazon Threat Intelligence identificou uma tentativa de exploração de PHP2Shell na telemetria MadPot datada de 17 de outubro de 2026, quatro dias antes da divulgação pública dessas duas CVE. Entre a lista de anúncios e essa telemetria fica o mal-estar da semana. Quem responde pela linguagem tinha acertado um relógio. Não era o único a correr.
Duas vias de entrada, e um desacordo sobre a largura
As vulnerabilidades, tal como o próprio arquivo de notícias do PHP as identificou, não são um bug descrito duas vezes. CVE-2026-109618 é execução remota de código via corrupção por falta de memória. CVE-2026-109619 é execução remota de código via estado global obsoleto. O impacto confirmado, no relato que examinou o problema de falta de memória, é execução remota de código sem autenticação como a conta do worker web. Essa última cláusula faz um trabalho discreto. Não é uma afirmação, com fonte, de posse total de uma máquina. É a afirmação de que o código corre, sem login, como a conta que o servidor web já usa para fazer o seu trabalho. Para um grande número de sites, essa conta é o trabalho.
A falha de estado obsoleto tem uma forma que se pode enunciar sem a transformar num procedimento. O PHP contém vários estados globais — de erro, de sessão, de objeto e de extensão — que um worker retém, mas que apontam para memória pertencente a um pedido. Um worker, neste arranjo, sobrevive ao pedido que o preencheu. A memória, não. O que a vulnerabilidade faz desse desencontro é, nos termos do arquivo, execução remota de código. A outra falha chega a um destino semelhante pelo caminho nomeado como corrupção por falta de memória. Dois mecanismos, uma classe de resultado, e um único lançamento de emergência construído para fechar ambos.
O risco, dizia o arquivo, é mais alto para mod_php, com um exploit demonstrado em que um pedido sem autenticação pode desencadear o ataque antes de qualquer código da aplicação correr. É a frase que um operador lê duas vezes. Uma falha que espera por um recanto particular de uma aplicação pode ser triada. Uma falha alcançável por um pedido sem autenticação, antes de a aplicação ter hipótese de ser cuidadosa, é outra fila. É por isso que um valor de gravidade de 9,2 em 10, que a Ars Technica noticiou como a classificação das duas vulnerabilidades que os maintainers estavam prestes a corrigir, não está na página como ornamento. É por isso que a mensagem da equipa de segurança era para se prepararem para atualizações de emergência no dia seguinte, não para encontrarem uma janela conveniente.
Há uma diferença real na distância até onde as fontes empurram o raio de explosão, e deve ser nomeada em vez de alisada.
De um lado, a BBC e o National Cyber Security Centre enquadraram a atualização como resposta a um problema crítico que pode permitir a atacantes executar comandos em qualquer servidor web a correr PHP. «Qualquer» é uma palavra grande. É a palavra que transforma um bug de runtime em algo mais próximo de uma contingência civil. Do outro lado, o próprio arquivo da linguagem foi mais específico sobre onde o perigo demonstrado se situava: mais alto para mod_php e, nesse caso demonstrado, alcançável antes de o código da aplicação correr. Não são sinónimos educados. Um leitor pode reter ambos — um aviso oficial amplo sobre servidores a correr PHP e uma afirmação técnica mais estreita sobre onde se mostrou que o risco é mais alto — sem fingir que dizem a mesma coisa. O impacto confirmado continua a ser execução remota de código sem autenticação como a conta do worker web. Até onde essa confirmação viaja, para lá da configuração em que foi demonstrada, é o argumento que os avisos do dia não pararam para resolver. Corrigiram, e disseram às pessoas para considerarem sair do ar enquanto o faziam.
A questão das versões tem uma aresta igualmente inacabada. Acredita-se que as vulnerabilidades afetam PHP 5, 6, 7 e 8 — acredita-se, não está cerimonialmente confirmado em cada linha, e a crença é transportada pela Watchtowr, pela BleepingComputer, pela própria nota de lançamento de segurança do PHP e pela Huntress. As versões nomeadas como correção das duas falhas críticas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As fontes aqui reunidas não traçam um mapa completo do que, a 21 de outubro, estava disponível para cada linha mais antiga que os investigadores acreditam estar afetada. O que traçam é uma lacuna na papelada: uma crença sobre o alcance que recua por 5, 6 e 7, e uma lista de correções que, no arquivo e na nota de envio, é uma lista de point releases 8.x. Para um administrador num 8.2, 8.3, 8.4 ou 8.5 atual, a instrução era concreta. Para quem ainda estava mais atrás, o registo público deste episódio é um aviso sem, nestas fontes, um número de versão correspondente.
A Wiz Research descobriu várias vulnerabilidades críticas no núcleo do PHP e situou a exposição em 70 por cento de todos os sites do mundo. O Australian Financial Review, ao noticiar que a inteligência artificial tinha descoberto bugs críticos na linguagem usada pela maioria dos servidores web, usou a mesma proporção: 70 por cento dos sites do mundo em risco. Este relato não tem um censo independente. O número pertence a essas duas narrativas, e é o número contra o qual o comportamento do dia se torna inteligível. Se mesmo uma fração séria dessa fatia estivesse certa, um caminho sem autenticação até à execução de código no worker não seria uma história de especialistas. Seria uma razão para um departamento governamental passar uma manhã ao telefone, que é o que o relato australiano descreve.
Uma falha de 2024, um acordo de 2026
A emergência tem uma pré-história, e é a parte menos lisonjeira do registo.
A PHP Foundation encontrou uma falha crítica em 2024, mas não conseguiu acordo sobre uma correção até 2026. O relato de The Next Web é específico quanto à estreiteza dessa frase: o PHP sabia de uma das falhas em 2024, e o obstáculo não era a ignorância. Era o acordo. As fontes não dizem qual das duas CVE de outubro era essa descoberta, nem quem defendeu que remédio, nem o que uma correção rejeitada teria custado. Dizem que uma falha crítica foi encontrada, que não se conseguiu acordo sobre uma correção e que o acordo só chegou em 2026.
Dois anos é muito tempo para deixar uma falha crítica numa linguagem que a Wiz e o Australian Financial Review associam ambos a cerca de sete em cada dez sites. É mais tempo ainda quando o lançamento final não é uma point version calendarizada com quinze dias de aviso, mas um patch de emergência, anunciado para uma quarta-feira à tarde em UTC, com os administradores avisados na véspera para estarem prontos. A distância entre «encontrámos» e «acordámos como fechar» é, no software comum, uma discussão de oficina. Num runtime tão amplamente embutido, nesses relatos, a mesma distância é uma janela de exposição pública. O registo de outubro não prova o que atravessou essa janela. Mostra que a janela era real e que, a meio do mês, já não era apenas uma questão de governação.
Há a tentação de tratar a falta de acordo como uma moral. O material não sustenta a moral em pormenor. Sustenta uma cronologia. Uma falha crítica, conhecida da Foundation em 2024. Sem correção acordada até 2026. Depois, em poucos dias de outubro, um conjunto de coisas que costumam chegar em sequência chegou quase umas sobre as outras: uma divulgação de investigação associada à Wiz, e a relatos que atribuíram o mérito à inteligência artificial; um aviso da equipa de segurança; uma hora publicada; patches para quatro linhas de versão atuais; e, já na telemetria de um fornecedor de cloud, uma tentativa de exploração datada de 17 de outubro, antes da divulgação pública dos dois números de CVE.
A fuga, se essa for a palavra, é ela própria um enquadramento com fonte, não um mecanismo assente. A Huntress titulou vulnerabilidades críticas vazadas. A PC Gamer escreveu sobre exploits vazados e sobre administradores a prepararem-se para as atualizações que os tapariam. O anúncio oficial era de um próximo lançamento crítico de segurança, marcado para 21 de outubro às 14:00 UTC. Nada nestas fontes descreve como qualquer fuga ocorreu, quem detinha os pormenores, ou se a tentativa de 17 de outubro usou a mesma informação que investigadores e autores de títulos viriam a chamar vazada. O que as fontes permitem é uma afirmação mais dura e mais pequena. A tentativa precede a divulgação pública. A divulgação pública foi gerida como uma emergência com relógio. E pelo menos uma das falhas subjacentes estava no conhecimento da Foundation, por resolver por falta de acordo, desde 2024.
Não falharam em vê-la. Numa das falhas, falharam em acordar uma correção — de 2024 até 2026.
Essa distinção muda o tipo de garantia que um patch pode oferecer. Um bug encontrado na segunda-feira e corrigido na quarta-feira é um processo a trabalhar depressa. Um bug encontrado em 2024 e enviado, em condições de emergência, em outubro de 2026 é um processo que acabou por funcionar, depois de um atraso que, no relato de The Next Web, o consenso não conseguiu fechar. Os patches de 21 de outubro não apagam o atraso. Terminam-no.
Vale a pena notar em que tipo de lançamento isto se tornou, uma vez chegado o acordo. Não um commit silencioso. Uma atualização de segurança com hora publicada, anunciada na lista de anúncios, grave o bastante para a equipa de segurança passar o dia anterior a dizer aos administradores para se prepararem, e grave o bastante para as classificações das duas falhas ficarem em 9,2 em 10. A própria nota do PHP nesse dia traz, no título, a promessa de dizer como o projeto está a reforçar a sua segurança. O conteúdo de qualquer reforma mais longa está fora destas fontes. O facto da emergência, não. O que é visível, no material efetivamente à mão, é uma decisão de enviar, a uma hora nomeada, correções para duas falhas que o projeto já não estava disposto a deixar para um lançamento conveniente.
O dia em que a web comum se desligou a si própria
As interrupções costumam ser narradas de fora: um site falha, um utilizador repara, uma página de estado alcança o resto. Esta foi narrada, em vários sítios, como uma escolha.
O Brussels Times noticiou sites importantes a saírem do ar enquanto a vulnerabilidade disparava receios de segurança, e a afirmação por baixo é direta. Vários sites importantes foram retirados do ar por causa de uma vulnerabilidade crítica na linguagem. A escala da BBC era ainda mais larga: sites desligados em todo o mundo à medida que a atualização de cibersegurança era emitida. Nenhum dos relatos inventaria o método — o que foi parado, por quem, durante quanto tempo — e seria ficção fornecer as operações em falta. Fixam a causa no problema do PHP. Fixam a resposta, no relato de mais de um país, como ausência, e não como um hotfix aplicado em silêncio.
O conselho oficial deu a essa escolha um patrocinador. Autoridades dos Estados Unidos, da Europa e do Reino Unido recomendaram que os sites saíssem temporariamente do ar até poderem ser corrigidos. É difícil exagerar quão raramente essa frase é a responsável. Tirar um site do ar é, em tempos normais, o resultado que um atacante quer e que um operador teme. Aqui, três conjuntos de autoridades trataram a ausência temporária como o estado mais seguro, enquanto a correção ainda não estivesse aplicada. O aviso do National Cyber Security Centre sobre um problema crítico de segurança que afeta o PHP fica no mesmo clima, mesmo onde este registo não cita o Centre a emitir a recomendação de sair do ar nessas palavras. Aquilo para que o Centre é citado, ao lado da BBC, é a substância: um problema crítico que pode permitir a atacantes executar comandos em qualquer servidor web a correr PHP, e uma atualização de segurança publicada para o tratar.
A versão australiana da manhã foi uma corrida para aplicar o patch. O Australian Financial Review noticiou que a inteligência artificial tinha descoberto bugs críticos na linguagem de programação usada pela maioria dos servidores web, e que agências governamentais corriam para corrigir vulnerabilidades em sites. Esse pormenor tira a história do teatro habitual das interrupções de consumo. Serviços com nome a irem para manutenção é um tipo de dano: um público que não consegue chegar a algo que usa sem pensar. Uma agência governamental a corrigir à pressa é outro. A mesma linguagem, embutida em sites que não são opcionais da mesma maneira. O enquadramento do AFR era o número dos 70 por cento, e a descoberta. O enquadramento operacional era mais simples. O bug estava na linguagem. A linguagem estava nos sites. Os sites tinham de se mexer.
O Japão fornece a lista mais concreta e, por isso, o corretivo mais útil à abstração. É fácil dizer «a web» e querer dizer um diagrama. É mais difícil descartar um aviso de manutenção que nomeia CoDMon, Shadowverse: Worlds Beyond, o servidor de aluguer da Sakura, BASE, pictSQUARE, 킴블, X Server e つなぐ. Junte-se NicoNico e pixiv, como fez a Gigazine, e a lista deixa de ser uma metáfora. O alojamento é o multiplicador escondido nesses nomes. Uma vulnerabilidade numa única aplicação é uma vulnerabilidade nessa aplicação. Uma vulnerabilidade na linguagem, num servidor de aluguer ou no X Server, é uma fila de clientes que não escolheram o bug e não podem, em qualquer sentido útil, contorná-lo com um patch feito por eles. Estas fontes não contam esses clientes. Mostram os anfitriões a tratar o patch como urgente o bastante para levar o serviço a manutenção de emergência.
A equipa de segurança pedira preparação, e o calendário mostra a forma do que foi pedido. O aviso era para se prepararem para atualizações de emergência no dia seguinte. O lançamento estava marcado para as 14:00 UTC do dia 21. Os patches, uma vez enviados, eram as quatro point releases já nomeadas. O que encheu as horas em torno dessa marcação não foi, neste registo, um apagão único e coordenado. Foi uma manta de retalhos: alguns sites retirados do ar no meio de receios de segurança, alguns desligados enquanto a atualização saía, alguns postos em manutenção nomeada, alguns sobre os quais agências governamentais australianas se debruçavam à pressa, cujo problema era o próprio patch. O elemento comum é a linguagem, e o juízo de que esperar por uma noite conveniente já não era a escolha conservadora.
A gravidade ajuda a explicar o juízo sem o explicar para o lado. Duas vulnerabilidades, cada uma com uma classificação de 9,2 em 10, não é um par que convide a um rollout faseado num fim de semana calmo. Alcance sem autenticação, no caso demonstrado de mod_php, antes de o código da aplicação correr, não é um par que convide confiança nas verificações que uma aplicação possa mais tarde fazer. Ponha-se isso ao lado de um aviso de que o problema pode permitir execução de comandos em qualquer servidor web a correr PHP, e o conselho de sair do ar até estar corrigido deixa de parecer teatro. Parece a opção residual, uma vez compreendido que a falha está no runtime e não num recanto que um operador possa simplesmente desligar.
Nada disto exigia que as vulnerabilidades fossem novas para toda a gente. Exigia que se tivessem tornado inegáveis. O conhecimento da Foundation em 2024, e a sua incapacidade de acordar uma correção até 2026, pertence ao mesmo fôlego que os avisos de manutenção. Os sites que escureceram a 21 de outubro viviam dentro de um atraso sobre o qual não votaram. Esse é o facto político dentro de um facto de engenharia de lançamento. Uma linguagem usada, no relato da Wiz e do AFR, por algo como 70 por cento dos sites do mundo não é uma base de código privada, mesmo quando a sua governação é uma discussão privada. O custo de uma correção não acordada é pago por pessoas que não estão na reunião.
Quem sabia, e quem já estava a tentar
Há duas estreias nesta história, e respondem a perguntas diferentes.
A Wiz Research descobriu várias vulnerabilidades críticas no núcleo do PHP. O relato da empresa, e o do Australian Financial Review, põem ambos a inteligência artificial na descoberta. A Wiz enquadrou o achado como IA a descobrir vulnerabilidades críticas de execução remota de código que afetam 70 por cento da internet. O AFR noticiou que a IA tinha descoberto um bug que punha em risco 70 por cento dos sites do mundo, e que agências governamentais australianas corriam. Como qualquer modelo foi usado, o que lhe foi mostrado, o que um investigador humano ainda teve de provar: nada disso está no material aqui, e seria ficção fornecê-lo. O que está no material é a atribuição. Um esforço de investigação associado à Wiz, e descrito em mais de um sítio como trabalho de IA, fez emergir várias falhas críticas no núcleo da linguagem. Nesse relato, isto não era uma má configuração numa extensão popular. Era o próprio PHP.
A outra estreia não é uma descoberta. É uma tentativa. A Amazon Threat Intelligence identificou uma tentativa de exploração de PHP2Shell datada de 17 de outubro de 2026, na telemetria MadPot, quatro dias antes da divulgação pública de CVE-2026-109618 e CVE-2026-109619. Uma tentativa não é um censo de intrusões. Estas fontes não dizem quantos servidores responderam, o que foi levado, ou se a tentativa teve êxito de forma duradoura. Dizem que foi identificada, que foi datada do dia 17 e que a divulgação pública das duas CVE chegou quatro dias depois. Numa semana de afirmações grandes — qualquer servidor web, 70 por cento dos sites, desligamentos mundiais — a frase da Amazon é quase austera, e é a que mais muda a temperatura. Alguém não estava à espera das FAQ.
Posta a direito, a sequência é esta. Uma falha crítica conhecida da Foundation desde 2024, sem correção acordada. Uma tentativa de exploração a 17 de outubro de 2026, vista na telemetria MadPot da Amazon. Um aviso da equipa de segurança do PHP para se prepararem para atualizações de emergência no dia seguinte. Um lançamento anunciado para as 14:00 UTC de 21 de outubro, transportado em php.announce e corroborado pela Huntress, pelo relato da PC Gamer sobre administradores a prepararem-se, e pelo post de Dane Knecht. Patches enviados no mesmo dia, como 8.5.12, 8.4.27, 8.3.36 e 8.2.35, a fechar duas vulnerabilidades críticas que permitem execução remota de código sem autenticação. Em torno desse envio: sites fora do ar, sites em manutenção, agências a correr, autoridades a recomendar a escuridão como controlo temporário.
O que esta cronologia não sustenta é um único enredo a correr de um desacordo de 2024 até uma sonda de 17 de outubro. Nada aqui liga a falha inédita da Foundation em chegar a acordo com a tentativa MadPot, ou essa tentativa com a divulgação da investigação, ou a divulgação da investigação com um operador nomeado. O quadro honesto é o de vários relógios, não o de uma conspiração. Um relógio de governação que correu dois anos. Um relógio de investigação que terminou numa descoberta pública atribuída à Wiz e à IA. Um relógio defensivo acertado, muito deliberadamente, para as 14:00 UTC de uma quarta-feira. E um relógio ofensivo que, no relato da Amazon, já tinha batido no dia 17.
O enquadramento de exploit vazado senta-se de forma desajeitada sobre esses relógios, e o desconforto deve ficar visível. Se a Huntress e a PC Gamer têm razão em que as vulnerabilidades, ou os exploits, tinham vazado, então o lançamento de emergência é em parte uma resposta a uma perda de controlo sobre a informação, não apenas uma resposta a um bug. Se a lista de anúncios for lida por si, o lançamento é uma atualização crítica de segurança planeada, com hora de início. Ambos podem ser verdade: um plano, e um plano conduzido onde outros já descreviam uma fuga. As fontes não arbitraram. Mostram um projeto a escolher uma hora pública, investigadores a descrever falhas vazadas, e os sensores de um fornecedor de cloud a registar uma tentativa antes de os números de CVE serem públicos. Isso basta para rejeitar a versão reconfortante, em que a primeira vez que alguém de fora ouviu falar das falhas foi um aviso polido e um conjunto de pacotes.
Também basta para ter cuidado com o êxito. «Tentativa de exploração» é a frase que o relato da Amazon sustenta. «Pode permitir» é a frase ligada à execução de comandos em qualquer servidor web a correr PHP. «Demonstrado» é a palavra que o arquivo do PHP usa para o caminho de mod_php, em que um pedido sem autenticação pode desencadear o ataque antes de o código da aplicação correr. «Impacto confirmado» é execução remota de código sem autenticação como a conta do worker web. Empilhadas sem cuidado, essas frases tornam-se uma sensação de compromisso geral já consumado. Lidas como estão escritas, são mais precisas, e a precisão é a notícia. Há um caminho demonstrado. Há uma classe confirmada de impacto. Há uma tentativa registada antes da divulgação. Há um aviso largo o bastante para cobrir qualquer servidor a correr a linguagem. Não há, neste material, uma contagem publicada de intrusões.
O que quatro números de versão podem fechar
Os pacotes são a parte da história com números de versão, e os números de versão são uma misericórdia. PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem duas vulnerabilidades críticas que podem permitir execução remota de código sem autenticação. Quatro ramos, quatro point releases, uma tarde. Para os operadores nesses ramos, a emergência tinha um fim que se podia descarregar. A atualização de segurança não foi apenas prometida para as 14:00 UTC. Foi publicada, para tratar de um problema crítico que pode permitir a atacantes executar comandos em qualquer servidor web a correr PHP. Essa é a frase que o National Cyber Security Centre e a BBC deixam no registo, e é a frase contra a qual as janelas de manutenção foram abertas, e contra a qual podem fechar.
O que os pacotes não fecham automaticamente é o argumento sobre o âmbito.
Não respondem, à face destas fontes, ao administrador cujo PHP é 7, ou 5, ou 6, todos dentro do conjunto de versões que se acredita estarem afetadas. Uma crença não é um patch. A crença está bem atestada — quatro fontes, incluindo a escrita do próprio projeto sobre o lançamento de segurança e uma FAQ especializada da Watchtowr. As correções que são nomeadas não são um conjunto correspondente. Fingir o contrário, em nome de um final limpo, seria inventar um backport que estes conjuntos não contêm. A afirmação limpa é a desarrumada. Os atuais 8.2, 8.3, 8.4 e 8.5 têm correções nomeadas. As linhas mais antigas estão, no juízo dessas quatro fontes, dentro do raio de explosão em que se acredita, e este registo pára aí.
Nem os pacotes dissolvem a diferença entre «qualquer servidor web a correr PHP» e «mais alto para mod_php». Um operador cuja configuração não é aquela que o arquivo marcou como o risco mais alto pode ler o aviso oficial e a nota técnica e não saber qual governa a noite. O caso demonstrado do arquivo é aquele em que um pedido sem autenticação desencadeia o ataque antes de qualquer código da aplicação correr, e liga essa demonstração a mod_php como o risco mais alto. O aviso mais amplo não espera pela distinção. Autoridades nos Estados Unidos, na Europa e na Grã-Bretanha recomendaram um estado temporário fora do ar até os sites poderem ser corrigidos, e essa recomendação não se lê como limitada a um único módulo de servidor. Se há uma disputa neste episódio, não é uma discussão aos gritos entre fornecedores. É esta: uma descrição institucional larga de quem está exposto, e uma descrição técnica mais estreita de onde o perigo se mostrou no seu ponto mais alto, publicadas na mesma semana, sobre as mesmas duas CVE. Ambas estão no registo. Nenhuma cancela a outra.
A afirmação de impacto tem a sua própria fronteira, e a fronteira vale a pena ser guardada. O impacto confirmado é execução remota de código sem autenticação como a conta do worker web. Isso é grave, e é específico. A execução de comandos, na formulação da BBC e do NCSC, é o poder sobre o qual se avisa. A conta nomeada na confirmação de impacto é a do worker. Um leitor cuidadoso não troca uma pela outra, a subir. Execução de código como o worker basta, na afirmação com fonte, para importar enormemente: são as próprias mãos do site. Não é, nesta evidência, uma afirmação com fonte de controlo automático para lá dessa conta. O medo do dia foi calibrado à afirmação que as fontes realmente fazem, e essa afirmação já bastava para esvaziar homepages e para justificar, no juízo de três conjuntos de autoridades, um desaparecimento temporário.
Há uma fronteira adicional em torno da palavra «tentativa». A Amazon viu uma tentativa de exploração de PHP2Shell a 17 de outubro, antes da divulgação. Os patches do dia 21 não a podem desver. Podem fechar os bugs de que uma tentativa dessas precisaria, nas versões que cobrem, para os operadores que os aplicarem. Não podem dizer quantas tentativas desse tipo nunca foram vistas, ou quantas tiveram êxito em sítios sem telemetria do tipo da MadPot. A ausência de uma lista de vítimas nestas fontes não é prova de uma semana calma. É prova de que este registo é sobre a falha, a correção, o conselho e uma tentativa identificada — não sobre um balanço concluído do dano.
E há a fronteira em torno de 2024. Os patches acordam uma correção. Não explicam o desacordo que atrasou uma. O achado de The Next Web permanece como a estática por baixo das notas de lançamento: uma das falhas era conhecida em 2024; uma correção não pôde ser acordada até 2026; o acordo, quando chegou, chegou como emergência, anunciada na véspera e classificada em 9,2 em 10. Quem quiser uma história sobre um sprint da descoberta ao patch terá de pôr o relógio a andar em outubro. Quem o puser a andar onde The Next Web o põe verá uma discussão de dois anos, e depois uma quarta-feira.
PHP2Shell é um nome suficientemente bom para uma semana. É um mau nome para a condição que a semana expôs. A condição é que uma falha nesta linguagem pode ser conhecida, e não acordada, e de repente de toda a gente; que o patch, quando chega, pode ser real e ainda assim não cobrir, nas fontes que temos, todas as versões que os investigadores acreditam estar no âmbito; que o aviso oficial e a nota técnica podem ambos ser cuidadosos e ainda assim não dizer a mesma coisa. A instrução sensata, para um dia, não era ser mais esperto do que o bug. Era estar fora do ar até os pacotes com esses quatro números deixarem de ser uma promessa para as 14:00 UTC e passarem a ser um ficheiro que tinha mesmo sido enviado.
A web, nos relatos dessa quarta-feira, não caiu sozinha. Partes dela foram postas a dormir de propósito, por operadores e anfitriões que tinham lido o aviso e preferiam uma página de manutenção a um worker a executar os comandos de outra pessoa. Não é uma história pequena sobre uma point release. É a história de quanta vida comum está agora dentro de um processo PHP — uma fatia que a Wiz e o Australian Financial Review põem ambas perto de 70 por cento dos sites do mundo — e de quão pouco espaço isso deixa quando um worker já não pode ser de confiança para impedir que a memória de um pedido permaneça como o estado do pedido seguinte. A correção, nas linhas que cobre, são quatro números de versão e uma tarde. O atraso que fez da tarde uma emergência durou dois anos.