Hotres Data Breach: Lessons for Hotels and Their Technology Providers

At the beginning of July 2026, reports emerged that guest data had leaked from Hotres, a booking system used by more than two thousand Polish hotels and accommodation providers. The property where you spent a weekend did not necessarily make the technical mistake. The failure occurred at a software provider shared by many properties.

This is one of the most common and underestimated breach scenarios. Attackers do not compromise “your” hotel directly. They compromise a common platform trusted by thousands of hotels at once.

What reportedly happened and which data was exposed

According to Polish security reporting, the attacker exploited SQL injection, one of the oldest and best-documented classes of web-application vulnerability. Importantly, the attack was reportedly performed from an authenticated user account. The attacker did not have to bypass the login page; legitimate access to the panel was enough to reach a vulnerable database query.

The reported data included:

• guest names,
• email addresses,
• telephone numbers,
• stay dates,
• booking costs.

The exact number of affected records has not been made public. Because the platform serves more than 2,000 properties, however, the potential scope is substantial. These are not payment-card or identity-document details, but they give a fraudster the context needed to build a convincing attack.

SQL injection without the jargon

A web application communicates with a database by sending queries. SQL injection occurs when user-controlled input is treated not as data but as part of the database command. Instead of looking up the booking number supplied by a user, the database also executes an instruction hidden inside that input — for example, an instruction to return bookings belonging to every hotel.

The main defence has been understood for two decades: never construct a query by concatenating untrusted text. Use parameterised queries that strictly separate the command from its data. This is an application-security foundation, which makes SQL injection in a production system in 2026 particularly painful. Injection has remained a core risk in the OWASP Top 10 for years.

Why an authenticated account is not a mitigating circumstance

Incident statements sometimes imply that a system was secure because an attack came from a logged-in account. That is not a defence. It describes a second security failure.

A fundamental application-security rule is that every input is untrusted, including input from an authenticated user. Authentication says “we know which identity is using this session.” It does not say “we trust everything this identity sends.” A legitimate user may be malicious, an account may be compromised, or someone may deliberately probe the system’s boundaries.

In a multi-tenant system, where one database stores information for thousands of hotels, a third issue appears: tenant isolation. A user belonging to one hotel must never be able to retrieve another hotel’s records. The reported scale suggests that this boundary may have been crossed. That is among the most serious SaaS failures because one flaw can expose data belonging to every customer.

A supplier breach is still a hotel risk

For an individual property, this is a classic case of third-party risk. The hotel entrusted guest data to an external booking platform and that platform reportedly failed. The hotel nevertheless retains responsibilities to guests and under data-protection law as the controller selecting and managing its processor.

Choosing a software provider is therefore a security decision, not merely a pricing decision. Reasonable due diligence should ask about:

• the results and frequency of independent penetration tests,
• the technical design used to isolate customer data,
• breach-notification procedures and response times,
• GDPR obligations and the data-processing agreement.

Our third-party risk management guide explains how to turn those questions into a repeatable process.

If you may be an affected guest

A name, telephone number, email address and stay date will not by themselves empty a bank account. The risk comes from combining them into a credible story. That is ideal material for targeted phishing and vishing:

• Be suspicious of messages “about your booking.” A criminal who knows your name, hotel and stay dates can send a convincing request for an additional payment or card confirmation. A genuine hotel should not ask you to enter card details through an unexpected SMS link.
• Verify through an independent channel. Call the telephone number on the hotel’s official website, not the number or link in a suspicious message.
• Do not pay urgent “booking surcharges” from a message link. Urgency and a familiar booking reference do not prove that the sender is genuine.
• Check whether your address appears in known breaches. Our guide explains how to check whether your data has leaked.

It is also sensible to provide only the data required for a booking and, where practical, use a separate email alias for reservations. That makes later abuse easier to identify and contain.

If you operate a hotel or build a booking platform

Hotels should treat this incident as a reason to review who processes guest information and under what controls. They also need a tested data-breach response plan. A GDPR notification to the supervisory authority is generally required within 72 hours when the breach is likely to create a risk to people’s rights and freedoms; the decision must follow a documented risk assessment.

For booking-platform developers and any SaaS provider handling personal data, the engineering lessons are direct:

• Use parameterised queries without exceptions. SQL injection is a solved engineering problem. Its presence points to a missing baseline control, not an unusually advanced attacker.
• Treat all input as untrusted, including authenticated input. Validation and authorisation must apply to every request and every object.
• Enforce tenant isolation. A customer must be technically unable to retrieve another customer’s data. Test this boundary with negative authorisation cases instead of assuming it works.
• Run regular penetration tests. A passive configuration scanner cannot discover SQL injection hidden in application logic. That needs controlled manual penetration testing. Our comparison of scans, audits and penetration tests explains the difference.
• Treat GDPR as a technical requirement too. Compliance is not only a privacy notice. It includes effective technical safeguards for personal data.

Summary

The reported Hotres breach illustrates two truths. For guests, data often leaks not from the business where it was provided but from an unseen supplier, so messages referring to a real reservation still require verification. For companies, serious breaches frequently result from missing basics rather than extraordinary exploits: parameterised queries, tenant isolation and regular testing.

SQL injection in 2026 is not bad luck. It is the kind of defect that a competent penetration test should identify before a criminal does.

If your system processes customer data and you want it assessed before an attacker tests it, contact us — web and API penetration testing is one of our core services.

Frequently asked questions

If I stayed at a hotel using Hotres, did my data definitely leak? Not necessarily. The exact scope and complete list of affected properties have not been made public. It is safer to assume the data may have been exposed and be especially cautious with messages that refer to the reservation. You can also check your email address with reputable breach-monitoring services.

Only my name, email address and telephone number leaked. Is that dangerous? The context matters. Those fields alone do not provide direct access to a bank account, but combined with real booking information they can support highly credible payment fraud. Targeted messages about a reservation are the most immediate practical risk.

Is the hotel responsible when an external system caused the breach? Under GDPR, a hotel acting as data controller remains responsible for selecting processors and defining how data is entrusted to them. Software procurement is therefore also a security and compliance decision, and due diligence should include evidence that the provider tests its applications.

Why would a security scanner miss this vulnerability? A passive scanner checks observable configuration such as HTTPS, headers and exposure. SQL injection exists in how the application constructs database queries. Discovering it requires a controlled manual test that submits malicious input and verifies the application’s behaviour within an authorised scope.

---

Sources and further reading: Niebezpiecznik, Sekurak, CERT Polska, Hotres security guidance.