Em resumo: se o site do seu hotel foi hackeado, trata-se menos da página inicial do que de tudo o que dela depende: o motor de reservas incorporado, a loja de vales, os formulários de pedido para festas e conferências. Verifique o nível de patch e as incorporações, guarde os registos e avise os hóspedes de forma objetiva se os seus dados puderem estar afetados.
Que sistemas PHP correm em hotéis e restauração
O site de um hotel ou restaurante corre normalmente em WordPress ou noutro CMS PHP. O motor de reservas vem muitas vezes do fornecedor do software hoteleiro ou de um channel manager e é incorporado por script ou iframe. A par disso, correm frequentemente no servidor próprio uma loja de vales baseada em WooCommerce, formulários para pedidos de conferências e casamentos, reservas de mesas, inscrições em newsletters e ofertas de emprego sazonais.
É precisamente a mistura de componentes próprios e alheios que torna a hotelaria vulnerável: o servidor próprio não precisa de conter os dados das reservas para pôr os hóspedes em risco. Basta que determine para onde leva o botão de reservar.
Que dados de hóspedes estão em jogo
Pelos sites dos hotéis passam nomes, moradas, números de telefone, dados de viagem e acompanhantes. Os pedidos contêm muitas vezes desejos especiais, como alergias, acessibilidade ou requisitos alimentares. Essas indicações de saúde pertencem às categorias especiais nos termos do Art. 9 do RGPD. Na loja de vales juntam-se dados de encomendas e de faturação.
Os dados dos cartões ficam, em regra, no prestador de pagamentos ou no software hoteleiro, e não no site. Mas quem consegue alterar JavaScript na própria página consegue também ler as entradas nos formulários ou enviar os hóspedes para uma página de pagamento com aparência genuína.
Os pedidos de conferências e eventos vêm muitas vezes de empresas e contêm listas de participantes, programas e orçamentos. Os pedidos de casamento indicam datas, números de convidados e apelidos de famílias. Estas informações raramente são percecionadas como sensíveis, mas são valiosas para tentativas de fraude dirigidas, por exemplo uma fatura de sinal falsificada pouco antes do evento. Verifique por isso se os pedidos ficam guardados de forma permanente na base de dados do site e se isso é necessário.
Site de hotel hackeado: consequências típicas para o negócio
- Páginas de reserva e de pagamento falsas: os hóspedes pagam a burlões e responsabilizam o hotel por isso.
- Mensagens fraudulentas dirigidas: com dados de viagem reais, os pedidos de pagamento falsificados parecem credíveis.
- Perda de reservas diretas: um aviso do Google ou uma falha empurra os hóspedes para portais de reservas, pelos quais paga comissão.
- Avaliações: os hóspedes que foram burlados relatam-no publicamente, independentemente de onde esteve a falha.
Depois de um patch, verifique também se a incorporação do seu motor de reservas ainda aponta para o endereço correto. Um script alterado ou uma ligação redirecionada quase não se nota no dia a dia.
Quem é responsável: agência, fornecedor de software, fornecedor de alojamento?
| Componente | Normalmente responsável | Questão em aberto |
|---|---|---|
| Site do hotel e loja de vales | Agência e fornecedor de alojamento | Patch do PHP e reinício confirmados? |
| Motor de reservas | Fornecedor do software hoteleiro | A incorporação está inalterada? |
| Software hoteleiro no próprio hotel | Fornecedor de software ou responsável de TI | Ligações ao site? |
| Caixas de correio da receção | Fornecedor de alojamento ou responsável de TI | Redirecionamentos desconhecidos? |
Nos grupos hoteleiros e nas operações em franchising juntam-se diretrizes centrais. Muitas vezes, a central opera o site principal, enquanto cada casa mantém páginas próprias de vales ou de eventos, que ninguém tem centralmente à vista.
Pessoal sazonal, acessos partilhados e vales
Na hotelaria, as equipas mudam com frequência. Os acessos ao site, à loja de vales e às plataformas de reservas são partilhados na receção e raramente alterados quando alguém sai. Depois de um incidente, todos estes acessos devem ser renovados e, sempre que possível, passados para contas pessoais.
Um risco subestimado são os vales. Quem tem acesso à base de dados da loja pode ler códigos de vales, alterar valores ou criar códigos próprios que são resgatados na receção. Depois de uma limpeza, mande verificar se foram criados ou alterados vales que não correspondam a nenhuma encomenda. Uma comparação com a sua contabilidade mostra normalmente depressa essas anomalias.
As primeiras horas após um aviso
- Pedir ao fornecedor de alojamento a confirmação escrita de que o PHP está em 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou tem o patch aplicado e de que todos os processos foram reiniciados.
- Sem confirmação: substituir o site por uma página de aviso com telefone e ligação direta ao motor de reservas do fornecedor.
- Guardar os registos desde 20/10/2026 e verificar as incorporações do motor de reservas e das páginas de pagamento.
- Informar a equipa da receção, para que reconheça e documente perguntas suspeitas dos hóspedes.
- Havendo indícios de fraude, avisar os hóspedes de forma objetiva. Ajuda na formulação oferece a página sobre comunicação de crise.
Como ajuda concretamente a PHP SOS?
- Verificamos o nível de patch, o reinício e o modo de operação do seu servidor web e articulamo-nos com a agência e o fornecedor de alojamento.
- Controlamos o site, a loja de vales e as incorporações quanto a JavaScript alterado, redirecionamentos estranhos e webshells e removemos o código malicioso.
- Verificamos se as caixas de correio receberam regras de reencaminhamento que desconhece.
- Depois, se desejar, configuramos uma monitorização de segurança que comunica alterações em ficheiros e scripts.
Perguntas frequentes
O meu motor de reservas está afetado pelo PHP2Shell?
Muitos motores de reservas são operados pelo fornecedor e apenas incorporados no site do hotel. Nesse caso, o fornecedor é responsável pelo seu servidor. O seu próprio site continua, ainda assim, a ser um risco, porque um atacante pode aí alterar a incorporação ou redirecionar para uma página de reservas falsa.
Hóspedes receberam pedidos de pagamento estranhos. Isso tem a ver com o site?
É possível, mas só uma verificação o pode comprovar. Essas mensagens podem também surgir através de plataformas de reservas ou de caixas de correio comprometidas. Guarde as mensagens, avise os hóspedes afetados e mande verificar o site, as caixas de correio e os acessos às plataformas.
Posso desligar o site na época alta?
Se não estiver comprovado que o PHP tem o patch aplicado, o BSI recomenda desligar temporariamente os servidores web da rede. Uma página de aviso com telefone e ligação direta ao motor de reservas do fornecedor mantém a atividade a funcionar. Um site comprometido sem se dar por isso custa mais confiança na época alta do que algumas horas de manutenção.