The Travelport Case: How Did an API Error Cause a Data Breach Affecting 73 Thousand People?

Updated: 3 September 2026 · Category: AI, Data Security and Breaches

The Travelport Case: How Did an API Error Cause a Data Breach Affecting 73 Thousand People?

The KVKK’s Travelport data breach announcement of 27 August 2026 stated that 73,958 people may have been affected and that reservation and travel information had been accessed without authorization. The official announcement explicitly identifies the technical cause as an API configuration error in the ViewTrip application.

Contents

Short answer
Why does it matter?
What should companies do?
How should it be measured?
Sources
Frequently asked questions

Short Answer

The KVKK’s Travelport announcement of 27 August 2026 explicitly identifies an API configuration error in ViewTrip as the technical cause. Access should normally have required both a PNR number and a surname, but records could be viewed using the booking reference alone. The data controller reported 73,958 affected people; this figure is based on PNR records created by travel agencies in Türkiye and does not directly represent the number of unique people residing in Türkiye.

Why Does It Matter?

The Travelport case shows that data breaches do not always result from a complex attack chain. According to the official announcement, ViewTrip’s API configuration allowed access with only the booking reference instead of the two expected pieces of information. This enabled an unidentified third party to access limited reservation information.

Potentially affected data included passenger names, PNR information, reference numbers, and flight, hotel, car and rail itinerary details; contact information may also have been affected in some cases. The incident occurred on 6–7 August 2026 and was detected on 20 August. On 26 August, the Board decided to announce it publicly in decision 2026/1797.

How Should the Figure of 73,958 Be Interpreted?

The figure of 73,958 should not be interpreted as 73,958 unique residents of Türkiye. The Authority explicitly states that it is based on PNR records created by travel agencies in Türkiye. Because there was no country-of-residence field and duplicate bookings could not be distinguished, the number of people residing in Türkiye is likely to be lower.

Is this a BOLA case?

The KVKK announcement does not classify the incident as BOLA in OWASP terminology. However, inadequately restricting access to another record through a user-supplied booking reference is a scenario that calls for assessment of object-level authorization controls. OWASP also recommends checking whether the user is actually authorized to access the relevant object in API functions that accept an object ID.

What Should Companies Do? 9 Technical and KVKK Lessons from the Travelport Case

Maintain an API endpoint inventory. Include web, mobile, partner and legacy endpoints in the same inventory.
Distinguish authentication from authorization. Knowing a piece of information should not automatically mean that a user is authorized to access the record.
Test object-level authorization. Use negative tests to verify that users cannot gain access by substituting other object IDs or references.
Do not rely on unpredictable identifiers alone. A complex or random booking reference does not replace authorization checks.
Apply response minimization. An endpoint should return only the fields needed for its function.
Set up rate and anomaly monitoring. Detect unusual behavior, such as access to many different booking references.
Integrate authorization regression tests into CI/CD. A configuration change must not disable an existing control.
Design logs to serve as incident evidence. It must be possible to analyze afterward which object was accessed, when and through which client.
Link the KVKK incident process to the technical incident. Data categories, the affected-person count and the incident timeline should be based on verified technical findings.

What is a Negative Authorization Test?

A normal functional test asks whether a record opens with the correct booking reference. A security test also checks scenarios that should fail: can a record be opened using another user’s reference, what happens if the surname is missing, and can one session access many records?

For configuration-based access rules in particular, these negative tests should run automatically in the release pipeline. This can flag weakened access control before release when an environment or gateway setting changes, even if the code does not.

Proposed Measurement Model for B10

API control	KPI	Risk
Inventory	Known endpoint coverage	Shadow or legacy API
Authorization	Negative authorization test pass rate	Access to another object
Response	Sensitive-field exposure count	Unnecessary data
Detection	Abnormal object-access detection	Undetected scanning
Logging	Object-access traceability	Missing incident evidence
Release	Authorization regression coverage	Configuration regression

These indicators measure both pentest results and the traceability of API access control throughout the product life cycle.

Expert Assessment

The main lesson from Travelport is to distinguish authentication from authorization. Knowing a booking reference does not by itself prove a user’s right to view that booking. The API must apply the relevant access policy whenever a sensitive object is accessed.

Technical classification must also distinguish the official announcement from security methodology. “API configuration error” is the official finding; mapping it to object-level authorization or BOLA is a technical risk analysis.

Digital Risk and Compliance Analysis

B10 can map the API inventory, object-level authorization tests, sensitive response fields, logging coverage and KVKK incident evidence needs onto a shared Privacy & API Exposure Matrix.