Echte Buchungsdaten. Falsche Zahlungslinks.

Name, Hotel und Reisedaten stimmen. Die Nachricht wirkt wie ein regulärer Teil der Buchung. Doch der Link zur angeblichen Zahlungsbestätigung führt zu Betrügern. Gerade korrekte Geschäftsdaten können einer falschen Forderung Glaubwürdigkeit verleihen.

Was im Fall HotelNetSolutions bestätigt wurde

HotelNetSolutions beschreibt eine ausgenutzte Schnittstellenlücke zwischen HotelControl und einem angebundenen Hotelsystem. Manipulierte Anfragen ermöglichten den Abruf von Buchungsdaten über den vorgesehenen Umfang hinaus. Die Lücke wurde am 19. September 2026 geschlossen. Der Anbieter nennt unter anderem Namen, Kontaktdaten, Hotel, Buchungsnummer, Reisedaten und Buchungsbetrag als betroffene Informationen. Hinweise auf abgeflossene Kreditkarten- oder sonstige Zahlungsdaten lagen laut Anbieter nicht vor. Sicherheitshinweis und datierte Updates.

Der Anbieter weist außerdem auf vergleichbare Phishingfälle bei Hotels hin, die seine Systeme nicht verwenden. Die breitere Angriffswelle lässt sich deshalb nicht vollständig einem Anbieter oder einem einzigen technischen Angriffsweg zuordnen.

Der Datenabfluss liefert den Kontext

Reservierungsdaten und später erbeutete Zahlungsdaten sind unterschiedliche Ebenen. Der erste Zugriff kann die Informationen liefern, mit denen sich eine Nachricht überzeugend personalisieren lässt. Eine anschließende Phishingseite soll weitere Angaben erfassen oder eine Zahlung auslösen.

Für Geschäftsreisende und Reiseorganisationen ist deshalb wichtig: Korrekte Daten authentifizieren keinen Absender. Auch HTTPS bestätigt nicht die Berechtigung einer Zahlungsforderung. Unerwartete Forderungen sollten über bereits bekannte Hotelkontakte oder das Travel-Management geprüft werden.

APIs müssen pro Datenobjekt entscheiden

Eine erfolgreich authentifizierte Anfrage ist noch kein berechtigter Zugriff auf jede Buchung. Das Zielsystem muss prüfen, ob Identität, Mandant und angefordertes Objekt zusammengehören. Das betrifft einzelne Datensätze ebenso wie Listen und Exporte.

Diese allgemeinen Schutzprinzipien finden sich im OWASP API Security Top 10. Sie sind hier eine technische Ableitung und keine bestätigte Klassifizierung der konkreten HotelNetSolutions-Lücke.

Drei Prüfpunkte für Unternehmen

• Berechtigungen testen: Mit freigegebenen Testkonten prüfen, ob Zugriffe auf fremde Mandanten oder Datensätze zuverlässig verweigert werden. Listen und Exportfunktionen einbeziehen.
• Abrufe auswertbar machen: Identität, Endpunkt, Autorisierungsentscheidung und Ergebnisumfang erfassen. Auffällige Exportmengen und Zugriffe auf viele unterschiedliche Datensätze mit dem normalen Betriebsprofil vergleichen.
• Folgebetrug berücksichtigen: Eine geschlossene Lücke entwertet bereits kopierte Daten nicht. Betroffene benötigen eine konkrete Warnung und einen unabhängig erreichbaren Kontaktweg.

Schwellenwerte müssen zum Geschäftsbetrieb passen. Auch geringe Abrufraten über längere Zeit können auffällig sein. IP-basierte Rate Limits ergänzen die Zugriffskontrolle, ersetzen sie jedoch nicht.

Meine Einordnung

Der Missbrauchswert von Geschäftsdaten gehört in die Sicherheitsbewertung. Eine Reservierung wirkt vielleicht weniger kritisch als eine Kreditkartennummer, kann aber den entscheidenden Kontext für einen Betrugsversuch liefern. Das gilt auch für Angebote, Rechnungen, Bestellungen und CRM-Daten.

Ihr nächster Prüfpunkt: Können Ihre Mitarbeitenden unerwartete Zahlungsforderungen über einen bekannten, unabhängigen Kanal verifizieren? Und verhindern Ihre Schnittstellen den Zugriff auf Daten anderer Kunden oder Mandanten?