Without throwing any companies under the bus, we must all have heard the recent news in short-term rentals: tech companies in our space being hacked, guests being asked for money, and their booking and private information being accessed: PMS systems, channel managers, third party add ons and more are one of the sources, but so are human beings!
The messages are convincing because they are real. They quote the guest’s name, the property and the dates of stay, then ask for a card “verification” or a payment to avoid cancellation. For the guest, it looks like it came from us. For the operator, the first sign of trouble is often a confused guest on the phone.
Here’s the rub: why do we find out last?
You would think you’d be told, and warned to be careful. In practice, most operators only find out when the chaos starts: guests phoning about strange WhatsApp messages, or a reservation team fielding refund requests for payments that never reached them.
There are a few reasons:
- Investigations take time. A vendor may spend days or weeks working out what was taken before it says anything.
- Breaches are often found by outsiders. A researcher, a customer or a scammed guest may spot it before the company does.
- Reports to the regulator aren’t public. A breach can be reported properly and still never make the news.
- The duty to tell guests sits with the operator, not the software company. If the vendor’s notice is slow, vague or lands in a generic inbox, nobody tells the guest.
That last point is where most of the confusion lies, so it’s worth setting out the rules and we have taken advice from the UK’s leading STR Association on the positon of managers and owners.
PASCUK – UK Association Advice
Other countries please ask your own local associations.
This is an update covering the UK from the STR Association. Members can access this document.
Even if the attack happens at a supplier, you may still have legal responsibilities as the Data Controller for your guests’ information. We have produced alongside Stephens Scown and their Intellectual Property, Data Protection & Technology Team, a PASC UK Members Guidance Paper explaining what owners need to do when notified of a cyberattack or data breach.
This includes their responsibilities under UK GDPR, when they must report an incident to the Information Commissioner’s Office (ICO), the critical 72-hour reporting deadline and how to communicate with affected guests, along with a template to help you with this communication.
If Members reading this paper are unsure as to where a specific situation sits on the scale of risk, they should contact the team at [email protected] who will be happy to help advise, and if necessary, put you in touch with additional resources.
We also explain why owners should check whether they need to be registered with the ICO in the first place. Please take the time to read this paper whether you are currently affected or not.
Members can access the paper HERE.
AI is speeding up both sides
In a world of AI, we can expect to see a lot more hacks, and last week gave us a clear example of how they happen.
On 20–21 October, security researchers and the PHP project disclosed two critical vulnerabilities in PHP, nicknamed “PHP2Shell”. PHP (Hypertext Preprocessor) is an open-source, back-end programming language that runs on web servers. It dates from the mid-1990s and still powers a large share of the web, including Wikipedia, online shops and WordPress, the system behind roughly 40% of all websites.
The two flaws let an attacker take control of a web server without logging in. They affected PHP versions going back to 5.4 and had sat in the code for over a decade. Security firm Calif found one of them using an OpenAI model, and Wiz independently found both, also with AI help. Governments in the Netherlands, Finland, France and Australia took some services offline while they patched, and hosting companies rushed out updates. Cloudflare reported thousands of exploit attempts in the hours before the official announcement.
OpenAI said the incident “highlights how AI can uncover security flaws with internet-scale impact, but the same capabilities can also help attackers rapidly develop offensive tools and exploits.” Put simply, the gap between a flaw existing and someone being able to exploit it is closing fast. The same capabilities can also help attackers rapidly develop offensive tools and exploits.” Put simply, the gap between a flaw existing and someone being able to exploit it is closing fast.
Plugins and add-ons multiply the risk
WordPress and PHP are probably no more vulnerable than other systems. But third-party additions such as plugins add risk:
- Uneven code quality: each plugin brings in another developer’s security practices.
- Maintenance: abandoned plugins and delayed updates leave weaknesses exposed.
- Broad permissions: a compromised plugin can potentially access customer data, change content or take over the site.
- Dependencies: plugins may contain third-party code that also needs updating.
The same applies to code written by contractors, and increasingly to code written by AI. With tools like Claude writing millions of lines of code a day, security testing and quality control matter more than ever, not less.
When the breach is in the PMS or its connections
Most modern operators don’t run one system. They run a PMS connected by API to a channel manager, an online check-in and ID tool, guest messaging, smart locks, payments and a website. Each connection is useful, and each one is another door.
The warning has to pass through every link in the chain. The scammer only needs one. Integrated systems create particular challenges. A single system allows much faster analyis of the breach:-
• The weak point may not be the PMS itself. Attackers often log in with a customer’s stolen username and password, then use the API to pull data in bulk. The vendor may argue its systems weren’t “hacked”, but if one account can download thousands of guest records without triggering an alarm, its controls deserve scrutiny.
• It’s hard to tell which system leaked. When guests receive scams quoting their bookings, the data could have come from the PMS, the channel manager, the check-in tool or an OTA extranet. Every vendor may say “not us” while the investigation runs.
• Data is copied everywhere. The same booking sits in five or six systems. Deleting it from one doesn’t remove it from the rest.
• Notices go to the wrong place. A vendor’s breach email may go to an account admin who has left, a billing contact or a shared inbox nobody reads.
• Contracts are often silent. Many standard software terms don’t commit the vendor to a notification deadline, the level of detail it will give, or help with notifying guests.
• The clock starts with the vendor’s notice. If that notice is late or vague, the manager can’t meet its own 72-hour deadline or warn guests in time.
• Small operators may not know they’re controllers. Many hosts using these tools don’t realise the reporting duty is theirs, or aren’t registered with the ICO.
None of this means operators should stop using connected tools. It means the connections need managing like suppliers, not just like features.
How to test a system for security flaws
No test can prove a system has zero flaws. PHP2Shell sat in some of the most scrutinised code on the internet for over a decade. What testing can do is find the common, avoidable flaws before an attacker does, and show that a supplier takes security seriously. Good testing works in layers, each catching what the others miss:
- Design review (threat modelling). Before building, ask what data the system holds, who should see it, and how someone might get at it. Most serious flaws are design mistakes, not typos.
- Code review. A second person, or a second tool, reads every change before it goes live, looking specifically at logins, permissions and data access.
- Automated code scanning. Tools read the source code and flag known dangerous patterns, such as unsafe database queries or missing input checks.
- Dependency scanning. Most apps are built largely from other people’s code: libraries, plugins, frameworks. Scanners check them against lists of known vulnerabilities and flag what needs updating.
- Secrets scanning. Checks that passwords, API keys and access tokens haven’t been left in the code, where anyone with access to it can find them.
- Testing the live system. Automated scanners probe the running website or API from the outside, the way an attacker would.
- Penetration testing. Qualified human testers try to break in, usually once a year and after major changes. This is where flaws in business logic get found, such as one guest being able to see another guest’s booking.
- Ongoing monitoring and a way to report problems. Alerts for unusual activity, such as one account downloading thousands of records, plus a published way for outside researchers to report flaws (a vulnerability disclosure policy, or a paid bug bounty).
Vibe-coded systems need more checking, not less
“Vibe coding” means building software mainly by describing it to an AI and accepting what it produces. It’s fast and powerful, and in our industry it’s already producing guest apps, owner portals, booking widgets and internal tools. The evidence so far is that it also produces more security flaws:
• “Veracode’s” testing of more than 100 AI models found 45% of AI-generated code samples introduced the Top 10 vulnerabilities, with no improvement from 2025 into 2026.
• One scan of over 1,400 vibe-coded live apps found 58% had at least one critical vulnerability, including exposed passwords, keys and personal data.
• An August 2026 scan of nearly 31,000 vibe-coded apps found 57% of those built on Supabase allowed anyone to read database tables without logging in.
• Georgia Tech researchers counted 35 published vulnerabilities traced to AI coding tools in March 2026 alone, more than in all of 2025.
The same flaws come up again and again:
• Missing access controls. The app works, but doesn’t check that the person asking for a booking is allowed to see it.
• Databases left open. Hosted databases such as Supabase or Firebase shipped without the rules that stop the public reading them.
• Secrets in the code. API keys and passwords written into the app, sometimes visible in the browser.
• Made-up or outdated packages. AI can suggest software libraries that don’t exist, which attackers then register under that name, or old versions with known holes.
• No logging. Nobody would notice a mass download.
What a vibe-coded system needs before it touches guest data:
• A human developer who understands the code reviews it, with logins, permissions and data access checked line by line.
• Automated scanning on every change, not just at launch.
• A specific test that one user can’t see another user’s data, and that the database can’t be read without logging in.
• An independent penetration test before go-live.
• Clear ownership: someone must be responsible for patching it in a year’s time.
AI can help on the defence side too. The same tools that write code can review it for security flaws, and that’s worth doing, but it adds to human review rather than replacing it. The tools are only half of it. They need to run automatically on every change, and someone needs to act on what they find. An operator doesn’t need to run these personally, but should ask suppliers and developers which they use, how often, and what happens when something is flagged.
For any supplier handling guest data, also ask:
• Is MFA available and enforced for all users, including API access?
• Do you alert customers to unusual activity, such as bulk downloads?
• Do you use AI to write code, and how is that code reviewed and tested?
• How quickly will you notify us of a breach, and what will you tell us?
• Who are your sub-processors, and where is our guests’ data stored?
A supplier that can answer these clearly, with documents to back them up, is far more reassuring than one with a badge on its website and nothing behind it.
What to do now
The operators who handle this well are the ones who prepared before it happened. A short checklist:
Your contracts
• ☐ For every vendor holding guest data, check the contract commits it to notify you within a set time (24–48 hours is reasonable), with enough detail to file an ICO report.
• ☐ Make sure breach notices go to a named person and a monitored inbox, not just the account admin.
• ☐ In management agreements, state who is the controller, who tells guests and the ICO, and how fast the manager tells the owner.
• ☐ Make sure your guest privacy notice names the right company.
• ☐ Ask each supplier holding guest data for the accreditations and evidence above, and check again every year.
Your systems
• ☐ Turn on two-factor login for every PMS, channel manager, check-in tool and OTA extranet.
• ☐ Remove logins for staff and contractors who have left, and review API keys and connected apps.
• ☐ Keep only the data you need. ID scans in particular should not sit in systems for years.
• ☐ If you have a website, keep PHP, WordPress and plugins updated, and ask your developer or host to confirm they’ve applied the October PHP patches.
• ☐ Make sure code from contractors, and code written with AI tools, is security-tested before it goes live.
Your response plan
• ☐ Keep a ready-made guest message: no links, no payment requests, and a clear line that you will never ask for card details by WhatsApp or text.
• ☐ Brief reservations and front-desk staff so they can reassure guests and spot scams.
• ☐ Know how to report to the ICO and keep an internal breach log, including decisions not to report.
• ☐ When a vendor reports an incident, ask in writing: were our guests affected, what data, since when, and what you’ve done.
The tech will keep changing, and AI will keep speeding up both attack and defence. What protects guests is still basic: knowing who is responsible, getting the warning to them before the scammer does, and making sure every link in the chain knows its part.
Note: This article is general information, not legal advice.
