PHP2Shell: quando uma requisição basta para dominar um servidor
25 minutos de leitura
Entre os dias 21 e 22 de outubro de 2026, algo bem estranho aconteceu na internet: diversos governos ao redor do mundo começaram a tirar seus próprios sites do ar.
Na Europa, órgãos públicos de países como Holanda e Finlândia desligaram seus portais. No Nepal, milhares de sites do governo e de bancos saíram do ar de uma vez.
E aqui no Brasil, a Anatel e alguns Tribunais Regionais Federais suspenderam o acesso externo ao SEI, o sistema utilizado por diversos órgãos públicos para gerenciar documentos e processos.
O detalhe curioso é que nenhum desses sites havia sido invadido, pois, a princípio, ninguém estava sob ataque naquele momento.
Por que então alguém tiraria o seu próprio site do ar, sem ter sofrido nenhum ataque?
A resposta: PHP2Shell, o nome atribuído a duas vulnerabilidades críticas no PHP que tinham acabado de ser divulgadas, sendo que bastava uma única requisição HTTP, sem nenhum tipo de autenticação, para que um atacante conseguisse executar comandos no servidor da vítima.
Neste artigo vou explicar o que foi o PHP2Shell, como ele funciona, como foi descoberto, os impactos que causou, além das lições que esse caso deixa para quem trabalha ou estuda cibersegurança.
O PHP e a Web
Para entender o tamanho do problema, primeiro é preciso entender o tamanho do PHP.
O PHP é uma linguagem de programação criada em 1994, focada no desenvolvimento Web, sendo que até hoje é utilizada por uma quantidade gigante de sites no mundo inteiro.
Segundo o W3Techs, cerca de 70% dos sites cuja linguagem de servidor é conhecida utilizam PHP.
Muitas vezes nem percebemos isso, pois o PHP está "escondido" por trás de ferramentas muito populares, como WordPress, Drupal, Joomla, Magento, Moodle, phpMyAdmin e o Nextcloud, além de frameworks como o Laravel e o Symfony.
Inclusive, muitos painéis de administração de hospedagens e sistemas internos de empresas e órgãos públicos também são desenvolvidos em PHP.
Ou seja, quando uma falha grave aparece no próprio PHP, o impacto potencial é gigantesco.
Formas de execução do PHP no servidor
Existe também um outro ponto importante, que vai fazer diferença mais adiante, que é a forma como o PHP é executado no servidor. As duas formas mais comuns são:
- mod_php: o PHP roda como um módulo dentro do próprio servidor Web Apache, sendo esta uma configuração mais antiga, mas ainda muito utilizada;
- PHP-FPM: o PHP roda como um serviço separado, com um conjunto de processos, chamados de workers, que recebem as requisições repassadas pelo servidor Web (normalmente o Nginx ou o Apache).
Em ambos os casos, um mesmo processo costuma atender diversas requisições em sequência, uma após a outra, sendo que isso é algo muito relevante para entender uma das falhas do PHP2Shell.
O que é o PHP2Shell
PHP2Shell é o nome que a comunidade de segurança deu a duas vulnerabilidades encontradas no núcleo do PHP, que foram divulgadas oficialmente em 21 de outubro de 2026:
- CVE-2026-109618: corrupção de memória causada pelo tratamento de falta de memória (out of memory);
- CVE-2026-109619: uso de um estado interno "antigo", que sobrevive de uma requisição para a outra apontando para uma memória que já foi liberada.
As duas receberam nota 9.2 no CVSS 4.0 e ambas permitem algo que é praticamente o pior cenário possível para uma aplicação Web: execução remota de código sem autenticação.
O nome segue uma tradição comum no mundo de segurança, de batizar falhas graves com nomes fáceis de lembrar, como aconteceu com o Heartbleed, o Shellshock e o Log4Shell.
E a ideia por trás dele é bem direta: alguém envia uma requisição para o seu site, e sai do outro lado com um shell, ou seja, um terminal para executar comandos no seu servidor.
O que é um RCE?
RCE é a sigla para Remote Code Execution (ou Execução Remota de Código), que é quando um atacante consegue fazer o servidor executar remotamente código ou comandos escolhidos por ele.
Na prática, é como se ele estivesse sentado na frente do servidor, podendo ler arquivos, roubar senhas e dados, instalar programas maliciosos e utilizar aquela máquina como ponto de partida para atacar outras. Quando o RCE não exige autenticação, qualquer pessoa na internet pode tentar explorá-lo.
O que são CVE e CVSS?
CVE (Common Vulnerabilities and Exposures) é um identificador único atribuído a cada vulnerabilidade divulgada publicamente, como o CVE-2026-109618.
Ele serve para que todo mundo, fabricantes, pesquisadores e equipes de segurança, fale exatamente da mesma falha.
Já o CVSS (Common Vulnerability Scoring System) é um sistema que dá uma nota de 0 a 10 para a gravidade de uma vulnerabilidade. Uma nota 9.2 está na faixa crítica, sendo a mais alta da escala.
Outro ponto que torna o PHP2Shell tão grave é o seu alcance, pois segundo os pesquisadores que o descobriram, o caminho de código vulnerável mais antigo existe desde o PHP 5.4.0, que foi lançado em 2012.
E a equipe do PHP deixou claro em seu comunicado oficial que estão em risco "todas as instalações PHP que atendem requisições Web", incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.
Como funciona o ataque
Vou explicar o funcionamento das falhas sem entrar em detalhes de exploração, apenas o suficiente para você entender a ideia por trás delas.
Caso você queira se aprofundar, a publicação técnica da Calif, empresa que descobriu as falhas, traz todos os detalhes.
O limite de memória do PHP
Todo script PHP possui um limite de memória que ele pode utilizar ao processar uma requisição, definido pela configuração memory_limit, que por padrão é de 128 MB. Existe também um limite para o tamanho do corpo das requisições, definido pela configuração post_max_size, que por padrão é de 8 MB.
Na teoria, uma requisição de no máximo 8 MB nunca deveria conseguir estourar um limite de memória de 128 MB, certo?
Porém, o PHP compara o post_max_size com o tamanho que a requisição declara ter, no cabeçalho Content-Length, e não com a quantidade de bytes que ele realmente acaba lendo.
E existem maneiras de enviar uma requisição sem declarar o tamanho do corpo, como o envio em partes (chunked) do HTTP/1.1 ou requisições no HTTP/2.
Fazendo uma analogia, é como ter um funcionário no checkin de um aeroporto que confia no peso escrito na etiqueta da mala, mas sem de fato pesá-la para conferir se o peso descrito está correto.
Além disso, ao processar um formulário com envio de arquivos (o famoso multipart/form-data), o PHP cria diversas estruturas internas para cada campo recebido.
Com campos montados de uma maneira bem específica, uma requisição pequena acaba "inflando" dentro do PHP, até consumir toda a memória disponível.
CVE-2026-109618
Quando o limite de memória é atingido, o PHP gera um erro fatal e interrompe imediatamente o que estava fazendo, pulando direto para a etapa de finalização da requisição.
O problema é que essa interrupção pode acontecer no meio da criação de uma estrutura interna, sendo que o PHP já tinha registrado que existia um novo elemento em uma lista, mas ainda não tinha terminado de montá-lo.
E com isso, na hora de fazer a limpeza, ele confia nesse registro e trata como válido um dado que estava pela metade.
Para entender melhor, vamos a outra analogia: imagine um garçom que anota na comanda que uma determinada mesa pediu cinco pratos, mas ele foi interrompido justo no momento em que ia anotar qual era o último prato, deixando então a comando com um espaço em branco.
Na hora de fechar a conta, o caixa vai calcular o valor total baseado nos itens que estiverem descritos na comanda. Ou seja, o cliente poderia escrever no lugar do último prato que pediu um café de R$5, ao invés do prato de R$49,90.
É justamente isso que permite a um atacante desviar o fluxo do PHP para executar o código que ele quiser.
CVE-2026-109619
A segunda falha envolve um recurso do PHP chamado upload progress, que acompanha o progresso de envio de arquivos e vem habilitado por padrão, controlado pela configuração session.upload_progress.enabled.
Esse recurso começa a funcionar durante a leitura da requisição, antes mesmo de o código da aplicação ser executado.
Se um erro fatal acontece nesse momento, a memória da requisição é liberada, mas algumas informações internas do PHP continuam apontando para ela, sendo que o mesmo processo vai atender a próxima requisição.
Fazendo mais uma analogia, é como um hotel que libera um quarto, mas esquece de apagar o número dele da ficha do hóspede antigo.
O atacante então faz o "check-in" naquele mesmo quarto, com uma segunda requisição, e o PHP entra nele achando que ainda está lidando com os dados do hóspede anterior.
Esse tipo de falha é conhecido como use-after-free, ou uso após liberação, sendo uma das classes de vulnerabilidade de memória mais exploradas da história.
Por que nem mesmo um código seguro escapa
Perceba um detalhe muito importante: tudo isso acontece antes de qualquer linha de código da aplicação ser executada.
Ou seja, não importa se o sistema foi muito bem desenvolvido, seguindo boas práticas de programação e de segurança, pois a falha está no PHP em si e não no código escrito com ele.
Segundo a equipe do PHP, o risco é maior ainda em instalações com mod_php, nas quais foi demonstrado que uma única requisição não autenticada consegue disparar o ataque antes de qualquer código da aplicação ser executado.
Já no PHP-FPM o caminho é mais difícil, pois o worker costuma ser encerrado após o erro, entretanto os pesquisadores também encontraram caminhos de exploração nele.
Os pesquisadores da Calif confirmaram a execução remota de código sem autenticação contra versões atuais de WordPress, Drupal, Joomla, Magento, phpMyAdmin, Nextcloud, MediaWiki, Laravel e Symfony, dentre outros. A Wiz, que também pesquisou as falhas, chegou a afirmar que até mesmo uma simples aplicação "Hello World" em uma versão afetada do PHP pode ser vulnerável.
E não para por aí, pois a Wiz também demonstrou que uma das falhas permite ler a memória do processo PHP, mesmo sem chegar a executar código, sendo que essa memória pode conter dados de requisições de outros usuários, como senhas, tokens de autenticação, chaves de API e certificados.
Uma falha com mais de 20 anos de história
Uma pergunta comum neste momento é: como uma falha tão grave passou tanto tempo despercebida? E a resposta é que ela não passou tão despercebida assim. Vejamos a linha do tempo:
- 2004: o pesquisador Stefan Esser encontra uma falha de execução remota de código ligada ao limite de memória do PHP, mas não publica seu exploit;
- 2020: um bug é reportado ao PHP descrevendo problemas em situações de falta de memória;
- 2024: uma auditoria de segurança no PHP feita pela empresa Quarkslab, organizada pelo OSTIF e financiada pela Sovereign Tech Agency, leva um desenvolvedor do PHP a identificar sinais do problema de falta de memória. Mas como ninguém conseguiu provar que ele era explorável, a correção não foi feita;
- 30 de julho de 2026: a Calif inicia uma auditoria no PHP, como parte do programa Patch the Planet, da OpenAI;
- 1º de agosto de 2026: o pesquisador Ryan Austin, da Calif, encontra a primeira falha;
- 11 de agosto de 2026: a falha é reportada à equipe de segurança do PHP;
- 14 e 15 de agosto de 2026: a Calif envia uma prova de conceito de execução remota de código, e o PHP confirma que ela funciona;
- 19 a 24 de agosto de 2026: de maneira independente, a Wiz encontra falhas relacionadas, confirma a execução remota de código contra Drupal e WordPress e também reporta ao PHP;
- 21 de outubro de 2026: as versões corrigidas do PHP são publicadas.
Repare que o problema já tinha dado sinais em 2004, em 2020 e em 2024. Então, o que mudou em 2026?
Um fator importante foi o uso de inteligência artificial, já que a Calif relatou ter utilizado ferramentas de IA para auditar o código do PHP, mas destacou que o ponto de partida foi algo bem humano: conhecer o histórico do alvo.
Os pesquisadores sabiam da falha de 2004 encontrada por Stefan Esser e direcionaram a IA para investigar códigos antigos relacionados ao limite de memória.
Depois de encontrar a primeira falha, eles transformaram o padrão encontrado em uma espécie de "receita" para que a IA procurasse outras falhas parecidas.
A Wiz também relatou o uso de modelos de IA, como o Gemini 4 Argon e o GPT-5.6 Sol, tanto para encontrar as falhas quanto para desenvolver os exploits e validar as correções.
O vazamento e a corrida contra o tempo
Quando um pesquisador encontra uma vulnerabilidade, o caminho considerado mais responsável é a chamada divulgação coordenada.
O pesquisador avisa o responsável pelo software de maneira privada, e ambos combinam uma data para a divulgação pública, dando tempo para que a correção seja desenvolvida e para que distribuições Linux e fornecedores preparem seus pacotes atualizados. Até essa data, todos os envolvidos devem manter sigilo, algo que é conhecido como embargo.
No caso do PHP2Shell, a divulgação estava marcada para o dia 22 de outubro, mas as coisas não saíram como planejado.
Na manhã do dia 20 de outubro, os identificadores das CVEs começaram a circular na internet, a partir de uma publicação no Hacker News que logo foi removida, mas cujas capturas de tela se espalharam pelas redes sociais.
As informações que circularam inclusive estavam erradas, com um horário de divulgação incorreto e uma nota CVSS de 10.0, e não de 9.2.
Segundo a PHP Foundation, nenhum detalhe técnico tinha vazado nesse momento. Mesmo assim, a equipe do PHP decidiu antecipar a divulgação para o dia 21 de outubro e publicou um aviso prévio informando que duas falhas críticas seriam corrigidas no dia seguinte.
A partir deste ponto, outros problemas foram surgindo:
- A própria Calif publicou, por engano, um vídeo mostrando uma prova de conceito do ataque. O vídeo foi apagado, mas já tinha se espalhado, e segundo a PHP Foundation acabou acelerando o desenvolvimento de exploits por terceiros;
- A Chainguard, empresa que fornece imagens de contêiner, publicou imagens já contendo a correção na manhã do dia 21, mais de seis horas antes do horário combinado, quebrando com isso o embargo;
- A Amazon informou ter registrado, em sua rede de honeypots chamada MadPot, uma tentativa de exploração no dia 17 de outubro, ou seja, quatro dias antes da divulgação pública. Até o momento, não se sabe como o atacante obteve essas informações.
No dia 21, as versões corrigidas foram publicadas e a Cloudflare informou já estar vendo os primeiros ataques, publicando então regras de proteção em seu WAF, e a Amazon registrou novas tentativas de exploração, indicando a participação de diversos atacantes diferentes.
Nos dias seguintes, os relatos de exploração bem-sucedida começaram a aparecer. No dia 24, um pesquisador relatou a invasão de três servidores honeypot rodando a versão 8.4.26 do PHP.
No dia 26, a Trail of Bits confirmou ter exploits funcionais contra as versões 8.2 a 8.5 sem a correção, e a CISA, agência de cibersegurança dos Estados Unidos, adicionou as duas falhas ao seu catálogo de vulnerabilidades conhecidamente exploradas, o KEV.
Cuidado com as informações durante um incidente
No dia 23 de outubro, a Unit 42, equipe de pesquisa da Palo Alto Networks, publicou que uma invasão a um órgão de governo europeu tinha sido causada pelo PHP2Shell.
Dois dias depois, a publicação foi retirada, pois não foi possível confirmar que a invasão tinha relação com essas falhas.
Da mesma maneira, a afirmação inicial da PHP Foundation de que não existiam exploits funcionais logo ficou desatualizada.
Durante um incidente as informações mudam muito rapidamente, e por isso é importante sempre conferir a data e a fonte do que você está lendo.
Os impactos ao redor do mundo
Com uma falha crítica, fácil de explorar, afetando cerca de 70% dos sites e com exploits começando a circular, muitas organizações tomaram uma decisão drástica: desligar seus sites até conseguirem atualizar o PHP.
E essa não foi uma decisão isolada, pois a própria CISA recomendou que sistemas PHP que não pudessem ser atualizados imediatamente fossem retirados do ar até receberem a correção.
Na Europa, governos de diversos países tiraram do ar sites e serviços públicos por precaução. Empresas e instituições também fizeram o mesmo, como a Nintendo, o projeto OBS e o hospital universitário Charité, de Berlim.
No Nepal, como boa parte dos sites do governo utiliza uma mesma plataforma, as autoridades conseguiram tirar milhares de sites do ar de uma só vez, assim como os sites do banco central do país e de diversos bancos privados.
No Brasil, o CTIR Gov, centro de tratamento de incidentes do governo federal, publicou no dia 21 uma recomendação para que os órgãos públicos identificassem seus sistemas em PHP e os atualizassem imediatamente, avaliando restringir o acesso pela internet caso isso não fosse possível.
A Anatel, o TRF1 e a Justiça Federal da 4ª Região suspenderam o acesso externo ao SEI, o mesmo aconteceu em Campinas, e o TRF6, em Minas Gerais, chegou a suspender o expediente e os prazos processuais.
Um ponto que merece atenção é que, na grande maioria desses casos, não houve invasão confirmada, sendo que os sites foram desligados por precaução.
Isso certamente gerou um impacto enorme para os cidadãos e clientes que dependiam desses serviços, mas foi uma decisão consciente, que trocou alguns dias de indisponibilidade pela segurança dos dados.
E o problema não se limita às versões atuais do PHP, pois as correções oficiais foram publicadas apenas para as versões 8.2, 8.3, 8.4 e 8.5, que ainda recebem suporte.
Para as versões 7.4, 8.0 e 8.1 foram disponibilizadas apenas correções em código-fonte, sendo que é preciso compilar o PHP manualmente para aplicá-las ou depender de algum fornecedor que ofereça pacotes atualizados.
Já as versões entre a 5.4 e a 7.3 não receberão nenhuma correção, sendo que, segundo a empresa Detectify, cerca de metade dos sites em PHP ainda roda em versões antigas.
Como se não bastasse, as novas versões 8.4.27 e 8.5.12 trouxeram uma regressão que pode derrubar algumas aplicações que utilizam o SimpleXML, causada por outra correção incluída no mesmo pacote.
E no dia 23, a equipe do PHP divulgou uma terceira falha, a CVE-2026-115560, considerada um vetor improvável de execução remota de código, que depende de uma combinação incomum de configuração e de código da aplicação.
Ou seja, as equipes tiveram que atualizar às pressas, lidar com efeitos colaterais da atualização e ainda acompanhar as novidades que surgiam a cada dia.
Como se proteger
A recomendação principal é bem simples, sendo repetida por todas as fontes oficiais: atualize o PHP.
As versões corrigidas são:
- 8.5.12;
- 8.4.27;
- 8.3.36;
- 8.2.35.
Mas na prática, para uma organização, isso envolve alguns passos:
- Fazer um inventário de todos os lugares em que o PHP está rodando, começando pelos sistemas expostos à internet. E não esqueça do PHP "escondido" em painéis de hospedagem, imagens de contêiner e softwares de terceiros;
- Atualizar para a versão corrigida, ou instalar o pacote atualizado da sua distribuição Linux, pois elas receberam as correções antecipadamente;
- Reiniciar todos os processos do PHP. Esse é um detalhe que muita gente esquece: atualizar o pacote não corrige os processos que já estão em execução, que continuam utilizando o código antigo na memória;
- Tratar as versões sem suporte, atualizando-as para uma versão suportada ou, enquanto isso não for possível, restringindo o acesso pela internet.
Para quem não consegue atualizar imediatamente, a equipe do PHP sugeriu algumas mitigações temporárias, sendo que elas reduzem a exposição a alguns caminhos de ataque, mas não deixam a instalação segura:
; Mitigações temporárias, NÃO substituem a atualização do PHP
; CVE-2026-109618: remove o limite de memória do PHP
; (use um limite de memória no contêiner ou cgroup no lugar)
memory_limit = -1
; Reduz o tamanho máximo do corpo das requisições
; (8M para aplicações sem upload de arquivos)
post_max_size = 8M
; CVE-2026-109619 (e CVE-2026-115560): desabilita o upload progress
session.upload_progress.enabled = 0
Repare que a primeira mitigação é bem curiosa: ela remove completamente o limite de memória do PHP, algo que por si só aumenta o risco de um ataque de negação de serviço.
Por isso, a recomendação é definir um limite de memória no nível do contêiner ou do sistema operacional, e de preferência em um local que a aplicação não consiga sobrescrever.
Ainda segundo a equipe do PHP, essas configurações devem ser feitas no php.ini, no pool do PHP-FPM ou na configuração do servidor Web, e não via ini_set() ou .user.ini, pois a falha acontece antes de o código da aplicação rodar.
E esconder as mensagens de erro, com display_errors ou error_reporting, não ajuda em nada.
MITIGAÇÃO NÃO É CORREÇÃO!
Um WAF, como o da Cloudflare, também pode ajudar a bloquear os ataques conhecidos, mas a própria Cloudflare descreveu suas regras como uma medida paliativa, pois elas cobrem apenas as variações já conhecidas do ataque.
Como saber se fui atacado?
Atualizar fecha a porta, mas não diz se alguém já entrou antes disso. Por isso também é importante procurar por sinais de exploração, como:
- Processos do PHP (php-fpm, php-cgi) ou do Apache executando programas como sh, bash, curl, wget ou nc. Um processo do PHP abrindo um terminal é um forte sinal de RCE;
- Comandos de reconhecimento executados pelo usuário do servidor Web, como whoami, id e uname -a;
- Requisições multipart incomuns seguidas de erros de limite de memória, muitas respostas com código HTTP 500 e reinícios frequentes dos workers;
- Arquivos novos e estranhos no diretório da aplicação, como webshells, além de novas tarefas agendadas e novos usuários no sistema.
E um detalhe para quem trabalha com resposta a incidentes: o Google Cloud e a Mandiant recomendaram capturar a memória dos processos do PHP antes de reiniciá-los nos servidores que mostraram sinais de ataque, pois o reinício apaga evidências importantes.
Lições aprendidas
O PHP2Shell certamente vai ficar marcado como um dos incidentes mais marcantes dos últimos anos, e deixa diversas lições para quem trabalha com segurança.
Problema conhecido é problema esperando para acontecer
O problema de falta de memória foi identificado em 2024 e não foi corrigido, pois ninguém tinha conseguido provar que ele era explorável.
A equipe do PHP avaliou diversas correções possíveis, todas com algum efeito colateral, como quebrar compatibilidade ou exigir mudanças em extensões de terceiros, e acabou não chegando a uma decisão.
A própria PHP Foundation reconheceu o erro publicamente, descrevendo o atraso como uma "falha estrutural, causada tanto pelo processo de decisão da equipe de segurança quanto pela sua falta de recursos".
"Não conseguimos explorar" não é a mesma coisa que "não é explorável". Uma falha conhecida e não corrigida é uma dívida, e um dia alguém vai cobrá-la.
Open source não é de graça para manter
O PHP sustenta cerca de 70% da Web, mas é mantido por uma equipe pequena. Isso não é exclusividade do PHP, e já vimos isso acontecer em casos como o Heartbleed, no OpenSSL, e o Log4Shell, no Log4j.
A PHP Foundation inclusive fez um apelo para que empresas, provedores de hospedagem e governos que dependem do PHP ajudem a financiar o projeto.
Se a sua empresa depende de um projeto open source, vale a pena se perguntar quem está cuidando da segurança dele.
A IA acelerou os dois lados
As falhas foram encontradas com ajuda de inteligência artificial, mas as primeiras ferramentas de exploração que circularam após o vazamento também foram construídas com ajuda dela.
A PHP Foundation relatou ainda que, com o crescimento da pesquisa assistida por IA, o volume de relatos explodiu: foram 15 CVEs desde julho de 2026, além de mais de 100 relatos inválidos, duplicados ou impossíveis de reproduzir.
Ou seja, o intervalo entre a divulgação de uma falha e a sua exploração está cada vez menor, e as equipes de defesa precisam ser cada vez mais rápidas para atualizar seus sistemas.
Você não protege o que não sabe que tem
Muitas organizações passaram os primeiros dias da crise apenas tentando descobrir onde o PHP estava rodando.
Ter um inventário atualizado de sistemas, versões e dependências, algo que é chamado de gestão de ativos, é uma das práticas mais básicas de segurança, e também uma das mais negligenciadas.
O mesmo vale para as versões sem suporte. Quem ainda rodava PHP 7 ou 8.1 descobriu da pior maneira que, quando uma falha grave aparece, não existe correção oficial esperando por você.
Desligar também é uma decisão de segurança
Em segurança da informação, é comum falarmos da chamada tríade CIA: Confidencialidade, Integridade e Disponibilidade (Confidentiality, Integrity e Availability).
Ao tirarem seus sites do ar, os governos e empresas abriram mão da disponibilidade para proteger a confidencialidade e a integridade dos dados.
Não existe uma resposta certa para todos os casos, mas perceba que essa é uma decisão de risco, que precisa ser tomada rapidamente e de maneira consciente, de preferência com um plano de resposta a incidentes definido antes de o incidente acontecer.
A divulgação coordenada é frágil
Um vazamento de identificadores, um vídeo publicado por engano e uma imagem de contêiner publicada antes da hora foram suficientes para transformar uma divulgação planejada em uma corrida contra o tempo.
E a tentativa de ataque registrada pela Amazon antes da divulgação mostra que alguém já tinha informações sobre as falhas antes da hora. Quanto mais pessoas e empresas envolvidas em um embargo, maior a chance de algo dar errado.
Conclusão
O PHP2Shell mostrou como uma falha no núcleo de uma tecnologia tão difundida pode afetar o mundo inteiro em questão de horas.
Bastava uma requisição sem autenticação para que um atacante conseguisse executar comandos no servidor e nem mesmo uma aplicação muito bem desenvolvida estava protegida, pois a falha acontecia antes de o código dela rodar.
Vimos também que o problema não surgiu do nada, pois ele deu sinais por mais de vinte anos, foi identificado em 2024 e não foi corrigido, até que pesquisadores utilizando inteligência artificial conseguiram provar que ele era explorável.
E quando as informações vazaram antes da hora, governos e empresas preferiram desligar seus próprios sites a correr o risco de serem invadidos.
Se você trabalha ou estuda cibersegurança, fica a mensagem: mantenha um inventário dos seus sistemas, não deixe versões sem suporte expostas na internet, tenha um plano de resposta a incidentes e lembre-se de que uma mitigação ajuda, mas não substitui a correção.
E você, como foi o PHP2Shell aí na sua empresa? Quanto tempo vocês levaram para descobrir onde o PHP estava rodando?
Para ir além
Se você chegou até aqui, deve ter percebido que o PHP2Shell não é uma história apenas sobre uma falha no PHP.
Ela envolve quem desenvolve a aplicação e cuida das suas dependências, quem mantém a infraestrutura onde ela roda e quem precisa decidir, em poucas horas, se tira um sistema do ar ou não.
E por trás de cada uma dessas pessoas existe uma carreira em cibersegurança.
Aqui na Alura, você pode seguir dois desses caminhos, do básico ao avançado:
- Carreira AppSec: Desenvolvimento Seguro de Aplicações: para quem quer entender como as vulnerabilidades nascem e como evitá-las durante o desenvolvimento. Você vai estudar o OWASP Top 10, modelagem de ameaças, segurança da supply chain de software e testes de segurança no pipeline de CI/CD, até chegar à gestão de vulnerabilidades e à construção de um programa de AppSec na empresa, justamente a área responsável por decidir o que corrigir primeiro quando um alerta como o do PHP2Shell aparece.
- Carreira Cloud Security: para quem quer proteger a infraestrutura onde essas aplicações rodam. Você vai trabalhar com segurança de contêineres e Kubernetes, Infrastructure as Code, monitoramento e conformidade de ambientes em nuvem e resposta a incidentes em cloud, temas que apareceram o tempo todo neste caso.
As duas carreiras começam pelo mesmo nível base, com fundamentos de cibersegurança, redes, Linux e criptografia, então você não precisa ter experiência prévia na área para dar o primeiro passo.
Conceitos que vimos neste artigo, como a tríade CIA e a análise dos processos de um servidor Linux, estão logo no começo da jornada.
Na próxima vez que uma falha como essa aparecer, você pode estar do lado de quem sabe exatamente o que fazer.
Fontes
Avalie essa notícia
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.