Em resumo: se a sua loja online foi hackeada ou corre numa versão do PHP sem patch, estão em jogo três coisas ao mesmo tempo: os dados dos clientes, o checkout e as suas vendas. Coloque a loja de forma controlada em modo de manutenção, guarde os registos desde 20/10/2026 e esclareça quem atualiza e reinicia o PHP no seu servidor.
O que está em jogo numa loja online
Uma loja é mais do que um site. Gere contas de clientes com hashes de palavras-passe, moradas de entrega e de faturação, históricos de encomendas, vales e, muitas vezes, também interfaces com a gestão de mercadorias, transportadoras e marketplaces. Quem consegue executar código no servidor chega, em regra, à base de dados e às chaves de API aí guardadas.
Os dados dos cartões não ficam, em regra, consigo, mas no prestador de pagamentos. Isto só tranquiliza em parte: um atacante pode introduzir no processo de encomenda JavaScript que lê as entradas no navegador. Estes scripts de skimming passam quase despercebidos na operação da loja, porque as encomendas continuam a decorrer normalmente.
A isto juntam-se as interfaces. Uma loja que transmite encomendas à gestão de mercadorias, às transportadoras e aos marketplaces guarda as chaves de acesso a esses sistemas, na maioria dos casos, em ficheiros de configuração no servidor. Quem as copia pode gerar etiquetas de envio em nome do comerciante, alterar stocks ou abusar de contas de marketplaces.
Sistemas de loja habituais e por que razão o PHP2Shell os atinge
Os sistemas de loja mais difundidos nas médias empresas alemãs correm em PHP: Shopware 6, WooCommerce, Magento, OXID, PrestaShop e muitas instalações Shopware 5 mais antigas. O PHP2Shell (CVE-2026-109618 e CVE-2026-109619, cada uma com CVSS 9,2) está no próprio PHP. Os atacantes não precisam de conta de cliente nem de acesso de administrador.
Para os comerciantes, isto significa: a atualização mais recente da loja não protege. O que conta é se o PHP no servidor está em 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou se o fornecedor de alojamento instalou um backport, e se depois todos os processos PHP foram reiniciados. No caso de lojas antigas em PHP 8.1 ou anterior, já não há atualizações oficiais do projeto PHP. Então, além da emergência, impõe-se uma migração que não convém fazer sob pressão de tempo na época alta.
Loja online hackeada: o que significa concretamente um incidente
Uma loja comprometida causa danos a vários níveis, que se reforçam mutuamente:
- Vendas: cada hora em modo de manutenção custa encomendas. Uma loja que continua a funcionar sem que se note pode, contudo, sair bastante mais cara.
- Dados de clientes: moradas e encomendas extraídas são usadas para e-mails de phishing dirigidos, que parecem genuínos porque mencionam encomendas reais.
- Visibilidade: se o Google deteta código malicioso, aparece um aviso nos resultados de pesquisa. Como o eliminar, explica-o o guia Remover o aviso do Google.
- Parceiros: os prestadores de pagamentos e os marketplaces têm regras próprias para incidentes de segurança. Quem comunica tarde arrisca problemas na liquidação.
Quem é responsável: agência, fornecedor de alojamento ou comerciante?
Em muitas lojas, a questão do PHP cai entre todas as cadeiras. A agência construiu a loja e mantém os plugins, o fornecedor de alojamento opera o servidor e o comerciante parte do princípio de que um dos dois trata do assunto. No alojamento gerido, o patch costuma ser aplicado pelo fornecedor; num vServer próprio, ninguém o faz automaticamente.
| Tarefa | Normalmente responsável | Verifique |
|---|---|---|
| Atualizar o pacote PHP | Fornecedor de alojamento ou administrador do servidor | Confirmação escrita com o estado do pacote |
| Reiniciar os processos PHP | Quem gere o servidor | Hora do reinício |
| Loja e plugins | Agência | Contrato de manutenção e acessos |
| Informar o prestador de pagamentos | Comerciante | Obrigações contratuais de notificação |
Um patch do PHP não prova que nada aconteceu antes. Se a loja foi atacada entre 17/10 e o momento do patch, o código introduzido pode continuar a correr. Mande verificar isso antes de dar o alerta por terminado.
As primeiras horas: sequência para comerciantes
- Colocar a loja em modo de manutenção ou, se isso não for possível, desligá-la temporariamente da rede.
- Guardar os registos do servidor web, do PHP e da loja desde 20/10/2026, antes que a rotação os apague.
- Pedir ao fornecedor de alojamento a confirmação escrita do estado do pacote PHP e do reinício.
- Renovar as palavras-passe de administrador, as chaves de API de pagamento, envio e marketplaces e os acessos à base de dados, e fazê-lo só depois da limpeza.
- Verificar alterações no checkout, nos plugins de pagamento e nos scripts incorporados.
Se houver indícios de fuga de dados, aplica-se o prazo de 72 horas do RGPD. A avaliação jurídica faz-se com o seu encarregado da proteção de dados e, se necessário, com o seu advogado.
Como ajuda concretamente a PHP SOS?
- Verificamos remotamente o estado real do pacote PHP, o modo de operação (por exemplo mod_php ou PHP-FPM) e se todos os workers foram reiniciados.
- Examinamos os ficheiros da loja, a base de dados e o checkout quanto a webshells, código de skimming e novas contas de administrador e removemos o software malicioso encontrado.
- Articulamo-nos com a sua agência e o seu fornecedor de alojamento, para que a manutenção da loja e a operação do servidor não corram em paralelo sem se encontrarem.
- Documentamos as conclusões e as medidas de forma a poder apresentá-las ao prestador de pagamentos, à seguradora e ao encarregado da proteção de dados.
- Depois, reforçamos o servidor e, se desejar, assumimos a vigilância contínua.
Perguntas frequentes
Tenho de desligar a minha loja da rede por causa do PHP2Shell?
O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda desligar temporariamente os servidores web da rede quando a atualização do PHP não é possível de imediato. Para uma loja, o modo de manutenção com uma página de aviso é muitas vezes melhor do que uma mensagem de erro. Assim que o PHP tiver o patch aplicado e todos os processos tiverem sido reiniciados, a loja pode reabrir.
Os dados de cartões de crédito na minha loja estão em risco?
Na maioria das lojas, os dados dos cartões não ficam no próprio servidor, mas no prestador de pagamentos. O perigo está, porém, em código manipulado no checkout que capta as entradas antes de chegarem ao prestador. Por isso, o checkout faz parte de qualquer verificação após um ataque.
Basta atualizar o Shopware ou o WooCommerce?
Não. O PHP2Shell afeta o próprio PHP, não o sistema de loja. Uma atualização da loja não fecha a vulnerabilidade, e um patch do PHP não remove código malicioso já introduzido.
Quem tenho de informar após uma fuga de dados?
No caso de dados pessoais, entra em consideração a notificação à autoridade de proteção de dados no prazo de 72 horas e, consoante o risco, também a informação dos titulares dos dados. A isto juntam-se obrigações contratuais perante o prestador de pagamentos e a seguradora. A avaliação em cada caso concreto faz-se com o seu encarregado da proteção de dados e um advogado.