Comentário: Em período eleitoral, manter a tecnologia e a pauta livres de viés partidário já é difícil quando tudo funciona. Imagine quando um invasor consegue publicar em nome do seu veículo. Um texto político plantado na home, a quatro dias do 2º turno, não vai ser lido como ataque hacker, mas como posição editorial. Por isso, segurança da informação também é proteção da isenção jornalística, e este alerta vale para todas as redações, não só para a equipe de TI.
Protocolos de segurança são como o cinto de segurança de um veículo de comunicação: ninguém pensa neles até o dia em que fazem falta. Atualizar sistemas, controlar quem tem acesso ao painel, fazer backups e monitorar o servidor parecem tarefas burocráticas, mas são o que separa um susto de uma crise de credibilidade.
Se isso já era importante, agora ficou urgente. Com a disseminação das IAs, encontrar falhas, escrever o código que as explora e disparar ataques em escala ficou mais rápido e mais barato. Em muitos casos, a janela entre a descoberta de uma brecha e o primeiro ataque já se mede em dias, às vezes em horas. E, uma vez dentro do sistema, o invasor pode usar a mesma IA para produzir conteúdo falso com cara de matéria legítima. Segurança deixou de ser assunto só de TI e passou a ser prioridade de negócio.
O caso desta semana mostra isso na prática.
O que são as falhas PHP2Shell
As vulnerabilidades CVE-2026-109618 e CVE-2026-109619, apelidadas de PHP2Shell, estão no próprio PHP, a linguagem que roda por trás de boa parte da web. Ou seja: o problema não está no código do seu site, mas no motor que faz ele funcionar.
Em termos simples, o invasor envia ao servidor uma requisição preparada para provocar um erro fatal no meio do processamento, como estourar o limite de memória. Nessa pane, o PHP deixa "restos" de dados mal arrumados, e o invasor usa essa bagunça para rodar o próprio código no servidor. Ele não precisa de login nem de senha, e o ataque acontece antes mesmo de o WordPress ou qualquer outro sistema começar a rodar. Uma das falhas também pode vazar trechos da memória do servidor, onde podem estar senhas, chaves de acesso e dados de outros usuários.
- Gravidade: nota 9,2 de 10 na escala CVSS, classificada como crítica.
- Linha do tempo: detalhes vazaram em 20 de outubro, antes da correção; o PHP publicou os pacotes corrigidos em 21 de outubro.
- Alcance: o código vulnerável existe desde o PHP 5.4, de 2012, e configurações padrão são afetadas. A Palo Alto Networks identificou mais de 22,6 milhões de instâncias expostas na internet potencialmente vulneráveis.
- Exploração: a empresa de segurança watchTowr afirma que as falhas já estão sendo exploradas. A Red Hat avalia que a CVE-2026-109618 é mais difícil de explorar em servidores com PHP-FPM, mas o próprio PHP confirmou ataque bem-sucedido contra PHP-FPM pela CVE-2026-109619. Ou seja: nenhuma configuração comum está a salvo.
Para a equipe técnica, as versões que resolvem o problema são estas:
Versão do PHP | Vulnerável até | Corrigida em |
|---|---|---|
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 |
8.1 ou anterior | Todas | Sem correção do projeto PHP; só há saída se a distribuição Linux ou o painel de hospedagem publicar pacote próprio. O caminho seguro é migrar |
O próprio PHP diz que atualizar é a única opção segura. Alguns pontos que costumam enganar até equipes experientes:
- Número de versão nem sempre conta a história. Distribuições como Red Hat, AlmaLinux, Debian e Ubuntu aplicam a correção no pacote sem mudar a versão principal. Confira o aviso de segurança da distribuição, não só o php -v.
- Um servidor pode ter vários PHPs. Painéis como Plesk e cPanel rodam versões diferentes por site, e o PHP do terminal pode não ser o mesmo que atende o site. Todas precisam ser atualizadas.
- Atualizar sem reiniciar não resolve. O PHP-FPM ou o Apache precisam ser reiniciados para carregar a versão nova.
- Container precisa de imagem nova. Em Docker e Kubernetes, é preciso reconstruir a imagem com a versão corrigida e fazer novo deploy.
- Hospedagem compartilhada depende do provedor. Nesse caso, quem atualiza é a empresa de hospedagem; peça confirmação.
- Medidas paliativas não substituem a atualização. O aviso do PHP lista ajustes de configuração e regras de firewall de aplicação (WAF) que reduzem a exposição enquanto a atualização não sai, mas deixa claro que eles não tornam o servidor seguro.
Por que o risco é alto para publishers
Muitos sites de notícias rodam em WordPress, que tem o PHP como base. Pesquisadores da Calif, citados pela Sansec, confirmaram a execução de código sem login no WordPress 7.1.2, além de Drupal, Joomla e outros sistemas populares. Como a falha está no motor, não adianta o site estar com plugins e tema em dia.
Mas o alerta não é só para quem usa WordPress. Vale para todo produto digital do veículo que tenha PHP em alguma camada, mesmo quando a redação não sabe disso:
- Site principal e portais regionais, inclusive os que usam CMS próprio ou Drupal.
- Sites "headless". Mesmo que a parte visível do site seja feita em outra tecnologia, o painel onde a redação escreve pode ser um WordPress exposto na internet.
- APIs dos aplicativos. O app no celular pode ser nativo, mas o servidor que entrega as notícias para ele muitas vezes é PHP.
- Sistemas de assinatura e paywall, lojas virtuais e checkouts, como WooCommerce e Magento.
- Ferramentas internas: intranet, webmail (como Roundcube), phpMyAdmin, wikis da redação e servidores de arquivos (como Nextcloud).
- Hotsites e especiais antigos, como coberturas de eleições passadas, que ficaram no ar e esquecidos. Costumam rodar versões velhas de PHP que nem recebem mais correção.
- Ambientes de teste e homologação expostos na internet.
- Serviços de terceiros: hospedagem, agência, fornecedor do app ou da plataforma de newsletter.
Um detalhe importante: ter uma CDN ou cache na frente do site não protege. O ataque usa requisições de envio de dados, que passam direto pelo cache e chegam ao servidor.
Uma única porta esquecida basta. A partir dela, o invasor pode alcançar banco de dados, credenciais e outros sistemas da empresa.
O que um invasor pode fazer com um veículo de comunicação
O invasor passa a rodar código com as mesmas permissões do PHP no servidor. Na prática, isso costuma bastar para ler a senha do banco de dados, alterar arquivos do site e criar usuários administradores: o mesmo poder de quem administra o site, ou mais. Alguns cenários:
Ataque | O que acontece | Impacto |
|---|---|---|
Pichação (defacement) | A home é trocada por mensagem, imagem ou propaganda do invasor | Exposição pública imediata e prints circulando nas redes |
Alteração silenciosa de conteúdo | Números, citações ou nomes são trocados em matérias já publicadas | Desinformação com o selo do veículo; pode levar dias para alguém notar |
Conteúdo com viés político | Editorial, pesquisa ou "apuração" falsa publicada em nome da redação | Crise de credibilidade e risco eleitoral e jurídico, sobretudo na reta final do 2º turno |
Push e newsletter falsos | A API do app ou a ferramenta de e-mail dispara um "urgente" falso para milhões de pessoas | Alcance maior que o do próprio site, sem como recolher a mensagem |
Roubo da base de assinantes | Nomes, e-mails, CPFs, endereços e histórico de pagamento são copiados | Incidente sob a LGPD, que pode exigir comunicação à ANPD e aos titulares, golpes contra os leitores |
Skimming no checkout | Um script escondido na página de assinatura captura os dados do cartão | Fraude contra o assinante e quebra de confiança no produto pago |
Paywall burlado ou revendido | Contas premium criadas em massa ou conteúdo exclusivo copiado e distribuído | Perda direta de receita de assinatura |
Spam de SEO | Páginas ocultas com links de apostas, remédios ou golpes, ou redirecionamentos maliciosos | Queda no Google, alerta de "site perigoso" no navegador, perda de tráfego |
Ransomware ou queda | Arquivos criptografados ou site derrubado em horário de pico, como a noite da apuração | Prejuízo de audiência e publicidade no momento de maior demanda |
Vazamento de material sensível | Rascunhos, matérias sob embargo e contatos de fontes ficam expostos | Risco para fontes e para investigações jornalísticas |
Troca de tags de anúncio | O invasor insere seus próprios anúncios ou scripts de mineração | Desvio de receita e site mais lento |
O pior cenário para uma redação não é o site fora do ar, que todo mundo percebe. É o site no ar, publicando o que não deveria, sem que ninguém perceba a tempo.
O que a redação deve fazer hoje
Você não precisa entender de código para agir. O passo mais importante é simples: procure hoje o chefe de tecnologia da empresa. Se o site, o app ou o paywall são mantidos por fora, fale com a agência, o desenvolvedor ou a empresa de hospedagem responsável. Encaminhe este texto, se ajudar.
Perguntas para levar à conversa:
- Quais sistemas do veículo usam PHP, incluindo site, APIs do app, paywall, newsletter e ferramentas internas?
- Todos já foram atualizados para as versões corrigidas (8.2.35, 8.3.36, 8.4.27 ou 8.5.12) ou para o pacote corrigido da distribuição, e os serviços foram reiniciados?
- Existe algum sistema em PHP 8.1 ou anterior? Qual é o plano para migrá-lo ou tirá-lo do ar?
- Os fornecedores e a hospedagem confirmaram a atualização por escrito?
- Há hotsites antigos ou ambientes de teste esquecidos na internet?
- Depois de atualizar, alguém procurou sinais de invasão já instalada, como arquivos alterados, usuários administradores novos e tarefas agendadas estranhas? A atualização fecha a porta, mas não expulsa quem já entrou.
- Se houver qualquer suspeita, senhas do banco de dados, chaves de API e chaves de segurança do WordPress foram trocadas?
- Existe backup recente, testado e guardado fora do servidor?
- Se algo acontecer na madrugada do 2º turno, quem a redação aciona e como?
E fique atento a sinais na rotina da redação: matérias com texto diferente do que foi publicado, posts que ninguém lembra de ter criado, usuários administradores desconhecidos, leitores relatando redirecionamentos ou avisos de segurança no navegador. Qualquer um desses sinais deve ir direto para a equipe técnica, sem esperar o dia seguinte.
Segurança não é um projeto com data para acabar. É rotina, como a checagem de uma matéria antes de ir ao ar.
