chavestech
Voltar ao blog
Segurança

PHP, Railway e Node.js: as falhas de segurança desta semana e o que fazer com o seu sistema

Uma falha nota 9,2 de 10 no PHP permite invadir servidores sem senha, a Railway teve chaves de clientes expostas e o Node.js também corrigiu falhas sérias. O que isso significa para o seu negócio e o que perguntar ao seu fornecedor.

Guilherme Chaves8 min de leitura
PHP, Railway e Node.js: as falhas de segurança desta semana e o que fazer com o seu sistema

Ontem o time que mantém o PHP publicou uma correção de emergência para duas falhas que tiraram nota 9,2 numa escala de gravidade que vai até 10. Os governos dos Estados Unidos, do Canadá e do Reino Unido soltaram alertas no mesmo dia pedindo atualização imediata. Naquela mesma quarta-feira o Node.js corrigiu dez falhas de uma vez e a Railway revelou que invasores podem ter lido as chaves de acesso que os clientes guardam na plataforma de hospedagem dela, muito usada por startups.

Quem não programa costuma ler esse tipo de notícia como assunto da equipe de TI. Acontece que o PHP está por trás de cerca de 70% dos sites cuja tecnologia dá para identificar. Todo WordPress e toda loja WooCommerce rodam em PHP, assim como boa parte dos sistemas feitos sob medida no Brasil nos últimos quinze anos. Se o seu site ou o seu sistema interno nasceu em PHP, essa notícia é sobre você.

O que aconteceu com o PHP

Num sistema feito em PHP, o PHP é ao mesmo tempo a linguagem do código e o motor que fica no servidor respondendo a cada visita. As duas falhas estão nesse motor e independem de plugin ou de qualquer erro de quem programou o sistema. Por isso atingem praticamente toda instalação aberta para a internet por mais caprichado que seja o que foi construído em cima.

Na prática, alguém de fora consegue mandar uma requisição preparada e executar comandos no seu servidor sem precisar de usuário ou senha. A tela de login do seu sistema nem chega a ser carregada porque o ataque acontece antes, na camada que recebe a visita.

Com esse acesso a pessoa pode ler o banco de dados inteiro com seus clientes e pedidos. Pode também trocar o conteúdo do site, instalar programas maliciosos ou usar a sua máquina para atacar outras empresas. Para a LGPD o vazamento de dados de cliente continua sendo responsabilidade sua, ainda que a falha tenha vindo do PHP.

Por que dessa vez é urgente

Correção de segurança sai todo mês e a maioria pode esperar a próxima janela de manutenção sem drama nenhum. Esta é diferente por quatro motivos:

  • Não exige senha. As falhas graves costumam depender de o atacante já ter algum acesso ao sistema, e esta dispensa qualquer acesso prévio.
  • Vazou antes da hora. Os identificadores das falhas circularam na internet no dia 20 e o PHP antecipou a correção em um dia por causa disso. Quem queria atacar ficou sabendo praticamente junto com quem queria se defender.
  • Já existem tentativas de ataque. A Amazon registrou tentativas desde o dia 17, quatro dias antes de a correção existir. A Cloudflare também disse estar vendo os primeiros ataques. A agência de segurança americana ainda não tinha casos confirmados quando publicou o alerta mas pediu atualização imediata, enquanto a britânica foi além e recomendou tirar do ar o que não puder ser corrigido logo.
  • A escala é enorme. As estimativas falam em mais de um milhão de servidores expostos. Quem ataca não escolhe a vítima a dedo e simplesmente varre a internet atrás de qualquer servidor desatualizado.

Os pesquisadores que encontraram essas falhas contaram que usaram modelos de IA na investigação. Achar brecha em software ficou mais barato para todo mundo, inclusive para quem ataca. O tempo entre uma falha ser descoberta e alguém tentar explorá-la está encolhendo, e um sistema parado no tempo fica cada vez mais caro de manter.

Antes dava para empurrar um sistema desatualizado por meses. Agora o prazo entre a falha aparecer e alguém tentar usar é contado em dias.

E quem está numa versão antiga?

O PHP corrigiu apenas as versões que ainda recebem suporte. Se o seu servidor estiver na 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 ou em alguma mais nova, a correção já está lá.

Quem ainda roda PHP 8.1, 8.0 ou 7.4 não ganhou uma atualização pronta. O time publicou apenas um remendo em código que um técnico precisa compilar e instalar manualmente. Para o PHP 7.3 e anteriores não vai sair correção nenhuma, e isso inclui o velho PHP 5.

Muita empresa está exatamente nessa situação pelo motivo de sempre. O sistema foi feito há anos, funciona bem e ninguém quer mexer porque atualizar pode quebrar alguma coisa. É a dívida técnica cobrando os juros todos de uma vez. Nesse cenário existem três caminhos honestos: atualizar o PHP e consertar o que quebrar, aplicar o remendo manual enquanto a atualização é planejada ou isolar o sistema da internet até resolver. Deixar como está não é um deles.

Node.js e Next.js também corrigiram falhas

O PHP ficou com a manchete, mas a semana teve outras correções importantes para quem tem produto digital.

O Node.js corrigiu dez falhas no dia 21 e quatro delas foram classificadas como de gravidade alta. A mais séria permite em tese executar código no servidor a partir de um arquivo comprimido malicioso, embora até agora ninguém tenha relatado ataques. As versões corrigidas são 22.23.4, 24.22.1 e 26.12.1, e quem está numa versão fora de suporte ficou sem correção.

Uma semana antes o Next.js, muito usado em sites e plataformas mais modernas, já tinha corrigido duas falhas críticas com nota 9,5 que também permitem executar código no servidor em certas configurações. A correção saiu no dia 14 nas versões 15.5.28 e 16.4.1.

Se o seu produto foi construído nos últimos anos em JavaScript, há uma boa chance de ele rodar em Node.js e talvez em Next.js. A gravidade é menor que a do PHP, mas a pergunta que você precisa fazer ao fornecedor é a mesma.

O incidente da Railway: quando o problema é a própria hospedagem

Das notícias da semana esta é a que mais me preocupa para quem tem produto digital, porque aqui não existe atualização que resolva. A Railway é uma plataforma onde muita startup sobe o sistema para não ter que cuidar de servidor. No dia 21 ela avisou que alguém sem autorização pode ter acessado as variáveis de ambiente dos clientes e conseguido ler parte delas já descriptografada.

Variável de ambiente é o nome técnico do lugar onde o sistema guarda as chaves que usa para conversar com o mundo. É ali que ficam a senha do banco de dados e a chave do gateway de pagamento, junto com os acessos ao serviço de e-mail, à nuvem e às APIs de inteligência artificial como OpenAI e Anthropic. Quem tem essas chaves não precisa invadir o seu sistema, porque consegue entrar pela porta da frente se passando por ele.

A Railway diz que o impacto atinge apenas uma parte dos clientes e que eles serão avisados por e-mail. Mesmo assim recomendou que todos troquem imediatamente as chaves guardadas lá e revisem os registros dos serviços ligados a elas. A empresa também pausou os deploys durante a investigação e na prática deixou muita gente sem conseguir publicar correção nenhuma, nem mesmo a do PHP. Segundo ela, o ataque faz parte de uma série de investidas contra plataformas desse tipo com o objetivo de chegar às contas de serviços de IA. Faz sentido, porque uma chave de IA roubada vira consumo pago por você e a fatura pode chegar antes de qualquer alerta.

Em abril a Vercel passou por um incidente parecido. Plataformas que guardam as chaves de milhares de empresas no mesmo lugar viraram alvo, e terceirizar a hospedagem tira de você o trabalho de manter o servidor sem tirar a responsabilidade pelo que está guardado nele.

Se o seu produto roda na Railway a troca de chaves precisa ser feita agora. Comece pelas mais sensíveis como banco de dados, pagamentos e IA e fique de olho na conta dos provedores de IA nos próximos dias.

"Mas a minha hospedagem não cuida disso?"

Às vezes cuida e às vezes não, e esta semana deixou isso bem claro. A Laravel Forge é uma das ferramentas mais usadas para gerenciar servidores PHP e avisou os próprios clientes que a atualização automática de segurança dela não atualiza o PHP. Cada um precisa fazer isso manualmente. Várias hospedagens compartilhadas desligaram a configuração usada pelo ataque conhecido, só que o próprio PHP avisa que isso apenas reduz o risco e que a única solução completa é atualizar. Por isso a resposta que interessa quando você pergunta se o sistema está protegido é uma versão e uma data.

O que fazer esta semana

Resolver isso não exige entender a parte técnica. Basta fazer as perguntas certas a quem cuida do seu site ou sistema e cobrar respostas objetivas, seja agência, freelancer, time interno ou a própria hospedagem:

  1. "O nosso site ou sistema roda PHP? E Node.js?" Se ninguém souber responder com segurança, isso por si só já é um sinal de alerta.
  2. "Qual versão está em produção hoje?" A resposta precisa ser um número como 8.3.36 e não algo vago como "a mais recente".
  3. "Quando a correção do dia 21 foi aplicada?" Tem que vir uma data. Vale confirmar também que os serviços foram reiniciados depois, porque sem isso a correção não entra em vigor.
  4. "Se estamos no PHP 8.1 ou anterior, qual é o plano e em quanto tempo?" Remendo manual, atualização ou isolamento são respostas aceitáveis e "vamos ver" não é.
  5. "Vocês olharam os registros do servidor desde o dia 17?" Como houve tentativas antes de a correção existir, atualizar não desfaz uma invasão que já tenha acontecido. Uma checagem de acessos estranhos é o mínimo.
  6. "Usamos a Railway? Se sim, quais chaves já foram trocadas?" A resposta boa é uma lista com cada chave marcada como trocada e não a promessa de que vão ver isso depois.

Se a resposta vier rápida e com números você tem um fornecedor atento. Se vier enrolada ou se você descobrir que ninguém está cuidando disso, vale buscar quem cuide antes que o problema apareça por conta própria.

Se você não sabe como está o seu sistema ou ninguém conseguiu responder essas perguntas, peça um orçamento para a ChavesTech. A gente avalia a sua situação e responde de forma direta com o que precisa ser feito e os próximos passos, mesmo quando a conclusão é que o sistema é antigo e vai dar trabalho. Como você fala direto com quem resolve, a decisão de como agir fica com você.

Fontes

Tem um projeto em mente?

Fale direto com quem desenvolve. Sem intermediários, sem surpresas.

Iniciar Projeto