En resumen: si la web de su hotel ha sido hackeada, se trata menos de la página de inicio que de todo lo que depende de ella: el motor de reservas integrado, la tienda de cheques regalo, los formularios de consulta para celebraciones y reuniones. Compruebe el estado del parche y las integraciones, conserve los registros y avise con objetividad a los huéspedes si sus datos pueden haberse visto afectados.
Qué sistemas PHP funcionan en hoteles y restaurantes
La web de un hotel o restaurante suele funcionar con WordPress u otro CMS PHP. El motor de reservas procede a menudo del proveedor del software hotelero o de un channel manager y se integra mediante un script o un iframe. Además, en el servidor propio suelen funcionar una tienda de cheques regalo basada en WooCommerce, formularios para solicitudes de reuniones y bodas, reservas de mesa, suscripciones a boletines y ofertas de empleo para la temporada.
Precisamente la mezcla de componentes propios y ajenos hace vulnerable a la hostelería: el servidor propio no necesita contener los datos de reservas para poner en peligro a los huéspedes. Basta con que decida adónde lleva el botón de reservar.
Qué datos de huéspedes están en juego
Por las webs de los hoteles pasan nombres, direcciones, teléfonos, fechas de viaje y acompañantes. Las solicitudes suelen contener deseos especiales como alergias, accesibilidad o requisitos dietéticos. Estas indicaciones de salud pertenecen a las categorías especiales del art. 9 del RGPD. En la tienda de cheques regalo se añaden datos de pedidos y de facturación.
Los datos de tarjeta suelen estar en el proveedor de pagos o en el software hotelero, no en la web. Pero quien puede modificar el JavaScript de la propia página también puede leer lo que se escribe en los formularios o enviar a los huéspedes a una página de pago de apariencia muy auténtica.
Las solicitudes de reuniones y eventos suelen venir de empresas y contienen listas de participantes, programas y presupuestos. Las solicitudes de bodas indican fechas, número de invitados y apellidos de familias. Esta información rara vez se percibe como sensible, pero es valiosa para intentos de fraude dirigidos, por ejemplo una factura falsa de anticipo poco antes del evento. Compruebe, por tanto, si las solicitudes permanecen de forma permanente en la base de datos de la web y si eso es necesario.
Web de hotel hackeada: consecuencias típicas para el negocio
- Páginas falsas de reservas y de pago: los huéspedes pagan a estafadores y responsabilizan al hotel.
- Mensajes de fraude dirigidos: con datos de viaje reales, los requerimientos de pago falsificados resultan creíbles.
- Pérdida de reservas directas: una advertencia de Google o una caída empuja a los huéspedes hacia portales de reservas por los que usted paga comisión.
- Valoraciones: los huéspedes que han sido estafados lo cuentan en público, con independencia de dónde estuviera el fallo.
Tras un parche, compruebe también si la integración de su motor de reservas sigue apuntando a la dirección correcta. Un script modificado o un enlace redirigido apenas se nota en el día a día.
¿Quién es responsable: agencia, proveedor de software o proveedor de hosting?
| Componente | Responsable habitual | Pregunta abierta |
|---|---|---|
| Web del hotel y tienda de cheques regalo | Agencia y proveedor de hosting | ¿Confirmados el parche de PHP y el reinicio? |
| Motor de reservas | Proveedor del software hotelero | ¿Está sin cambios la integración? |
| Software hotelero en el establecimiento | Proveedor de software o responsable de TI | ¿Conexiones con la web? |
| Buzones de recepción | Proveedor de hosting o responsable de TI | ¿Redirecciones desconocidas? |
En las cadenas hoteleras y los negocios de franquicia se suman normas centrales. A menudo, la central opera la web principal, mientras que cada establecimiento mantiene sus propias páginas de cheques regalo o de eventos que nadie vigila de forma centralizada.
Personal de temporada, accesos compartidos y cheques regalo
En la hostelería los equipos cambian con frecuencia. Los accesos a la web, a la tienda de cheques regalo y a las plataformas de reservas se comparten en la recepción y rara vez se cambian cuando alguien se va. Tras un incidente, todos estos accesos deberían renovarse y pasar a cuentas personales siempre que sea posible.
Un riesgo infravalorado son los cheques regalo. Quien tiene acceso a la base de datos de la tienda puede leer los códigos de cheques, modificar importes o crear códigos propios que se canjean en la recepción. Tras una limpieza, haga comprobar si se han creado o modificado cheques que no puedan asignarse a ningún pedido. Un cotejo con su contabilidad suele mostrar enseguida esas anomalías.
Las primeras horas tras un aviso
- Hacer confirmar por escrito al proveedor de hosting que PHP está en 8.5.12, 8.4.27, 8.3.36 u 8.2.35 o está parcheado y que se reiniciaron todos los procesos.
- Sin confirmación: sustituir la web por una página informativa con teléfono y enlace directo al motor de reservas del proveedor.
- Conservar los registros desde el 20/10/2026 y revisar las integraciones del motor de reservas y de las páginas de pago.
- Informar al equipo de recepción para que reconozca y documente las consultas sospechosas de los huéspedes.
- Si hay indicios de fraude, avisar con objetividad a los huéspedes. La página sobre comunicación de crisis ofrece ayudas de redacción.
¿Cómo ayuda PHP SOS en concreto?
- Comprobamos el estado del parche, el reinicio y el modo de ejecución de su servidor web y nos coordinamos con la agencia y el proveedor de hosting.
- Controlamos la web, la tienda de cheques regalo y las integraciones en busca de JavaScript modificado, redirecciones ajenas y webshells, y eliminamos el código malicioso.
- Comprobamos si los buzones han recibido reglas de reenvío que usted no conoce.
- Después, si lo desea, configuramos una monitorización de seguridad que avise de los cambios en archivos y scripts.
Preguntas frecuentes
¿Afecta PHP2Shell a mi motor de reservas?
Muchos motores de reservas los opera el proveedor y solo se integran en la web del hotel. En ese caso, el proveedor es responsable de su servidor. Su propia web sigue siendo un riesgo, porque un atacante puede modificar allí la integración o redirigir a una página de reservas falsa.
Unos huéspedes han recibido requerimientos de pago extraños. ¿Está relacionado con la web?
Es posible; solo puede demostrarse tras una revisión. Estos mensajes también pueden originarse en plataformas de reservas o en buzones comprometidos. Conserve los mensajes, avise a los huéspedes afectados y haga revisar la web, los buzones y los accesos a las plataformas.
¿Puedo desactivar la web en plena temporada alta?
Si no está demostrado que PHP esté parcheado, el BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda desconectar temporalmente los servidores web de la red. Una página informativa con teléfono y enlace directo al motor de reservas del proveedor mantiene el negocio en marcha. Una web comprometida sin que nadie lo note cuesta más confianza en temporada que unas horas de mantenimiento.