A OpenAI publicou nesta quarta-feira (21), no GitHub, o php2shell-checker (abre em nova aba). É um verificador para quem quer saber se o próprio site roda uma versão do PHP exposta às duas falhas críticas divulgadas no mesmo dia. A ferramenta é útil, mas bem mais modesta do que o anúncio em volta dela sugere. Ela não testa a falha nem procura brecha. Só lê um número de versão, e apenas quando o servidor aceita mostrá-lo.
O problema, esse sim, não tem nada de modesto. O projeto PHP (abre em nova aba) lançou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para fechar duas vulnerabilidades que permitem a um invasor executar código no servidor sem fazer login. Na prática, ele pode assumir a máquina que hospeda o site. As duas falhas receberam nota 9,2 numa escala de gravidade que vai até 10. Segundo o alerta oficial, corre risco toda instalação de PHP que atende visitantes na web. O pior cenário é o Apache com mod_php, um dos jeitos de acoplar o PHP ao servidor web Apache. Nessa configuração, o ataque foi demonstrado antes mesmo de o código do site começar a rodar. Também não existe quebra-galho completo: atualizar é a única escolha segura, diz o PHP.
O que a ferramenta faz
Quando alguém abre um site, o servidor manda junto, sem aparecer na tela, uma espécie de etiqueta técnica (os cabeçalhos HTTP). Às vezes essa etiqueta informa a versão do PHP. O verificador lê essa informação ou, se rodar dentro do próprio servidor, pergunta a versão diretamente. Depois compara o número com uma tabela embutida e devolve um de três veredictos: OK, VULNERABLE (vulnerável) ou UNKNOWN (desconhecido). A ferramenta vem em duas "skills" para o Codex, o agente de programação da OpenAI. Uma só precisa do endereço do site. A outra serve para quem tem acesso ao servidor.
Pasquale Pillitteri, que destrinchou o código e publicou a análise no próprio site, listou essa tabela embutida, datada de 20 de outubro. Nos ramos ainda suportados, ela bate com as versões corrigidas:
| Ramo do PHP | Última versão tratada como vulnerável | Versão com a correção |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
O anúncio feito pela conta oficial da OpenAI no X deixa claro que o verificador também funciona como vitrine do Codex:
Se você está se perguntando se o seu site foi afetado, empacotamos uma skill do Codex para ajudar a verificar. Aponte o seu Codex para este repositório para que ele guie você pelo processo: https://github.com/openai/php2shell-checker
O veredicto mais provável é "não sei"
A pegadinha está no próprio manual do repositório, e a OpenAI tem o mérito de admiti-la: "UNKNOWN não significa que o alvo está corrigido". Há três limitações:
- Servidores podem esconder ou alterar a etiqueta, e aí o resultado é desconhecido.
- Correções aplicadas pelas distribuições do sistema operacional podem não mudar o número oficial da versão. Com isso, um servidor já protegido pode parecer vulnerável.
- O OK só presume que as versões mais novas trazem a correção. Não confere.
No teste de Pillitteri, o site dele voltou como UNKNOWN, com a mensagem "versão do PHP não encontrada". Já uma instalação local do PHP 8.5.6 foi marcada como vulnerável.
Quem achou, quem consertou
O verificador é a parte pequena de uma narrativa grande. A OpenAI diz ter liderado, por dois meses, uma coalizão de mantenedores, pesquisadores e empresas de segurança. Chama o caso de um dos problemas de segurança de maior impacto da memória recente e afirma que, "até onde sabemos, a IA de fronteira encontrou essas vulnerabilidades antes dos atacantes". Na versão da empresa, a Calif achou uma falha crítica usando o GPT-5.6 Sol, dentro da iniciativa Patch the Planet (abre em nova aba), e a Wiz (abre em nova aba) descobriu as duas de forma independente. A OpenAI também diz ter acionado a Super Intelligence Force, da Casa Branca, e a CISA (abre em nova aba), agência americana de cibersegurança. E afirma ter reservado US$ 1 bilhão em acesso subsidiado ao Daybreak para defensores de sistemas.
A cronologia da PHP Foundation (abre em nova aba) reparte melhor o crédito:
- 30 de julho: a Calif começa a auditar o PHP.
- 11 de agosto: o pesquisador Ryan A, da Calif, reporta o ataque. A causa é a mesma de um problema de memória encontrado em 2024. No mesmo dia, a OpenAI reporta, de forma independente, essa mesma causa.
- 24 de agosto: a Wiz aponta novos caminhos de ataque.
- 18 de setembro: a OpenAI aponta outros caminhos.
As correções saíram das mãos dos mantenedores do PHP, como a própria OpenAI reconhece. E o plano quase descarrilou. Na terça (20), os códigos das falhas vazaram com horário e nota errados (10 em vez de 9,2), mas sem detalhes técnicos. Por causa disso, o lançamento foi antecipado em um dia.
A IA ajudou de verdade, e a fundação agradece nominalmente à equipe de segurança do Codex. Mas o centro desta história é quem escreveu e publicou a correção. O repositório da OpenAI passou de 680 estrelas no GitHub e não aceita contribuições de código de fora. É uma lanterna, não uma fechadura.
O que fazer agora
- Pergunte à hospedagem, ou a quem cuida do site, qual versão do PHP está rodando e se ela já é uma das corrigidas da tabela.
- Na versão 8.1 ou anterior, o projeto PHP não atualiza mais. Algumas distribuições e fornecedores de suporte estendido oferecem correções adaptadas. A equipe de segurança do PHP também publicou ajustes mínimos para as versões 7.4, 8.0 e 8.1, voltados a quem compila o PHP por conta própria.
- No 8.2, atualize e já planeje a mudança: esse ramo perde suporte em 31 de dezembro de 2026.
- Os ajustes provisórios de configuração sugeridos pelo PHP só reduzem a exposição em caminhos específicos. Não deixam o site seguro.
Rodar o verificador leva segundos, mas o que tira o site da linha de tiro é a atualização.