In short: If your hotel website has been hacked, it is less about the home page than about everything attached to it: the embedded booking engine, the voucher shop, enquiry forms for celebrations and conferences. Check the patch level and embeddings, preserve logs, and warn guests factually if their data could be affected.
Which PHP systems run in hotels and restaurants
The website of a hotel or restaurant usually runs on WordPress or another PHP CMS. The booking engine often comes from the provider of the hotel software or a channel manager and is embedded via script or iframe. Alongside it, the hotel's own server often runs a voucher shop based on WooCommerce, forms for conference and wedding enquiries, table reservations, newsletter sign-ups and seasonal job offers.
It is precisely the mix of own and third-party building blocks that makes hospitality vulnerable: your own server does not have to contain the booking data to endanger guests. It is enough that it determines where the Book button leads.
Which guest data is at stake
Names, addresses, phone numbers, travel dates and accompanying persons pass through hotel websites. Enquiries often contain special requests such as allergies, accessibility needs or dietary requirements. Such health information belongs to the special categories under Art. 9 GDPR. In the voucher shop, order and invoice data come on top.
Card data is usually with the payment provider or in the hotel software, not on the website. But anyone who can modify JavaScript on your own site can also read entries on forms or send guests to a deceptively genuine payment page.
Conference and event enquiries often come from companies and contain participant lists, schedules and budgets. Wedding enquiries name dates, guest numbers and family names. Such information is rarely perceived as sensitive but is valuable for targeted fraud attempts, such as a forged deposit invoice shortly before the event. Check therefore whether enquiries are stored permanently in the website database and whether that is necessary.
Hotel website hacked: typical consequences for the business
- Fake booking and payment pages: Guests pay fraudsters and hold the hotel responsible.
- Targeted fraud messages: With real travel data, forged payment requests look credible.
- Loss of direct bookings: A Google warning or an outage drives guests to booking portals, for which you pay commission.
- Reviews: Guests who were defrauded describe this publicly, regardless of where the fault lay.
After a patch, also check whether the embedding of your booking engine still points to the correct address. A modified script or a redirected link is hardly noticeable in day-to-day work.
Who is responsible: agency, software vendor, host?
| Building block | Typically responsible | Open question |
|---|---|---|
| Hotel website and voucher shop | Agency and host | PHP patch and restart confirmed? |
| Booking engine | Hotel software provider | Is the embedding unchanged? |
| Hotel software on site | Software vendor or IT support | Connections to the website? |
| Reception mailboxes | Host or IT support | Unknown forwardings? |
With hotel groups and franchise operations, central requirements come on top. Often the head office runs the main site while individual properties maintain their own voucher or event pages that nobody has in view centrally.
Seasonal staff, shared access and vouchers
In hospitality, teams change frequently. Access to the website, the voucher shop and booking platforms is shared at reception and rarely changed when someone leaves. After an incident, all of this access should be renewed and switched to personal accounts where possible.
An underestimated risk is vouchers. Anyone with access to the shop database can read out voucher codes, change values or create their own codes that are redeemed at reception. After a cleanup, have it checked whether vouchers were created or changed that cannot be assigned to an order. A comparison with your bookkeeping usually reveals such anomalies quickly.
The first hours after a warning
- Have the host confirm in writing that PHP is at 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or is patched and that all processes were restarted.
- Without confirmation: replace the website with a notice page showing a phone number and a direct link to the provider's booking engine.
- Preserve logs from 20 October 2026 onward and check the embeddings of the booking engine and payment pages.
- Inform the reception team so that it recognises and documents suspicious queries from guests.
- If there are indications of fraud, warn guests factually. The page on crisis communication offers help with wording.
How does PHP SOS help?
- We check the patch level, restart and operating mode of your web server and coordinate with the agency and host.
- We inspect the website, voucher shop and embeddings for modified JavaScript, foreign redirects and webshells and remove malicious code.
- We check whether mailboxes have received forwarding rules that you do not know about.
- Afterwards, if you wish, we set up security monitoring that reports changes to files and scripts.
Frequently asked questions
Is my booking engine affected by PHP2Shell?
Many booking engines are operated by the provider and only embedded in the hotel website. In that case the provider is responsible for its server. Your own website remains a risk nonetheless, because an attacker there can change the embedding or redirect to a fake booking page.
Guests have received strange payment requests. Is this connected to the website?
It is possible, but it can only be proven after a review. Such messages can also arise via booking platforms or compromised mailboxes. Preserve the messages, warn the guests affected and have the website, mailboxes and platform access checked.
May I switch off the website in peak season?
If PHP is not demonstrably patched, the BSI (German Federal Office for Information Security) recommends taking web servers offline temporarily. A notice page with a phone number and a direct link to the provider's booking engine keeps business going. A site that is compromised without anyone noticing costs more trust in season than a few hours of maintenance.