Amadeus Data Exposures: Korean Air, Asiana, Lufthansa and Condor

Two separate exposures at Amadeus, the airline booking technology provider, surfaced in October 2026. Korean Air and Asiana say booking data leaked through misuse of an Amadeus system account between August 2023 and September 2026. Separately, heise online found passenger records for Lufthansa, Condor and others behind an open heap dump. Passengers should expect phishing; operators should check service accounts and management endpoints.

This post keeps the two events apart, because the sources do. Amadeus has spoken publicly about one of them: a "display environment" exposure it confirmed to heise online on 13 October. On the other, the credential misuse that Korean Air and Asiana announced on 23 October, we found no Amadeus statement as of 26 October; everything we know comes from the two airlines. Nobody has said the two events share a cause, and we do not suggest they do. Where a question is open, we say it is open.

Neither event has a CVE, a published list of indicators of compromise or a count of affected people. What there is, and what this post sets out, is enough technical detail for any team running booking, travel or customer data systems to check its own exposure to the same two failure patterns: a long lived system account whose login was used by someone who should not have had it, and a Java management endpoint that handed out a memory image full of secrets.

What happened

Event 1: Korean Air and Asiana, unauthorized access with an Amadeus system account

According to Korean Air's statement and its email to customers, as reported by several Korean outlets on 23 October 2026:

1. Amadeus IT Group formally notified Korean Air at 22:44 Korea Standard Time on Tuesday 20 October 2026 that there were signs personal information had leaked from Amadeus's system.
2. Korean Air says the incident occurred through unauthorized access using login credentials assigned to an account in Amadeus's system.
3. The estimated window runs from August 2023 to September 2026. Korean Air says the exact timing is still under investigation.
4. The only data item Korean Air has confirmed so far is customers' booking reference numbers (PNRs, the six character locators printed on every itinerary). Other items are being verified with Amadeus, and Korean Air says it will notify customers when they are confirmed.
5. Korean Air says it took safety measures immediately on notification and found no signs of compromise of its own systems or databases. In its words, as translated by the Kyunghyang Shinmun: "we have confirmed no signs of compromise to our own systems or databases."
6. According to Korean Air, Amadeus is blocking the unauthorized access and has activated dark web monitoring. Korean Air says it has asked Amadeus for stronger protection and measures to prevent a recurrence, and that it will inspect its contractors more thoroughly.
7. On the evening of 23 October, Korean Air emailed affected customers. It said no secondary damage had been confirmed so far and asked customers not to click links of unclear origin, open attachments or answer requests to enter personal information.

Asiana Airlines confirmed the same day that booking related information about its customers had also leaked through the Amadeus incident. An Asiana spokesperson told the Asia Business Daily that "payment-related information was not included," and said there were no signs of a direct breach of Asiana's internal database. The Korea Times reports Asiana's explanation that payment data was not affected because a separate system handles transactions.

Korean Air also noted, according to MoneyToday, that the incident occurred within Amadeus's area of management. Neither airline has published a number of affected customers.

Event 2: a "display environment" exposed through an unauthenticated heap dump

On 13 October 2026, heise online, the German technology news site, reported a separate problem. Readers had alerted heise to it. heise reported that:

• The heap dump of a Spring Boot application was reachable through an endpoint that required no authentication.
• The dump contained access credentials and authentication tokens. With administrator passwords found in it, read and write access to the global system was possible.
• During heise's check, current booking data could be retrieved, and passengers could be searched by last name.
• Visible records included full names, dates of birth and PNRs, as well as contact, ID and passport data in plain text, plus details of bookings and travel updates.
• A large share of the records heise checked concerned Lufthansa and Condor flights, along with other airlines and partner airlines.
• The data included hundreds of office IDs of travel agencies and booking offices in Germany. heise says further identifiers could be found with automated queries and matched to specific agencies using public information.
• At the time of publication, the vulnerability appeared to have been closed.

Amadeus told heise that it was made aware on 21 September of a potential vulnerability that "affected a display environment for travel bookings." According to Amadeus, certain booking data may have been accessible, payment or financial data could not be accessed, the vulnerability is fixed, monitoring and detection have been strengthened and the investigation is ongoing. Amadeus did not give heise a number of affected people. heise notes that whether and how far unauthorized people accessed data is still open.

heise also asked Germany's Federal Office for Information Security (BSI) for comment. At publication, the BSI had not answered.

Are the two events connected?

We do not know, and neither do the public sources. The facts that can be stated side by side are these:

• Event 2 involved a memory dump containing credentials and tokens, which heise says included administrator passwords with access to a global system.
• Event 1 involved login credentials assigned to an Amadeus system account, used without authorization over a window ending in September 2026.
• Amadeus told heise it learned of the Event 2 exposure on 21 September 2026.

Amadeus has not commented publicly on the Korean Air and Asiana case. Korean Air has not said how the credentials were obtained. heise has not said which credentials were in the dump beyond describing them as access credentials, tokens and administrator passwords. No source states that the credentials in the heap dump were the credentials used in the Korean case, or that they were not. The overlap in timing is the only link anyone can point to, and timing alone does not establish a cause. It is a fair question to put to Amadeus. It is not an answer.

A third, earlier item in heise's report

heise also mentions a recent incident at Maritim Hotels involving Amadeus's hotel reservation service iHotelier, reported by the trade outlet Hotel vor9: according to heise, Maritim emailed 8,716 affected guests on 17 September and was still clarifying the cause with the provider. It is a hotel system, and no source links its cause to either event above.

Timeline

Times are given only where a source gives them.

Who is affected

Lufthansa and Condor have not, as far as we found, issued statements about Event 2. The airlines named here are the subjects of the reporting and the operators whose passengers are affected; none is described as having had its own systems breached.

Technical details

There is no CVE for either event, no affected or fixed version of a named product, no hashes and no IOCs from an official advisory. What follows is everything concrete the primary sources publish, plus the documented behaviour of the open source component heise names, so defenders can check their own systems.

Event 1: what is on record

Some outlets give the end of the window as "last month" and others as September 2026. Both describe the same Korean Air statement, published in October. We use Korean Air's wording.

Why a PNR matters even without payment data: at many carriers, a booking reference and the passenger's surname are enough to open "manage booking" pages online. That is a general property of airline booking flows, not something any source says was abused here. It is the reason Korean Air's phishing warning is the most practical advice in its notice: a message that quotes a real booking reference looks far more convincing than one that does not.

Event 2: what heise describes

heise does not give the URL path of the endpoint, and we do not assume it. What we can explain is how heap dumps work in Spring Boot, because that behaviour is documented.

How Spring Boot heap dumps work

Spring Boot Actuator adds production management endpoints to an application. One of them, heapdump, returns a heap dump of the running JVM. According to the Spring Boot documentation:

• A GET request to /actuator/heapdump retrieves the dump when the endpoint is available and exposed.
• On a HotSpot JVM the format is HPROF; on OpenJ9 it is PHD. The response is binary and can be large.
• "By default, only the health endpoint is exposed over HTTP and JMX." Exposure is controlled by management.endpoints.web.exposure.include and management.endpoints.web.exposure.exclude, and the exclude list wins.
• When Spring Security is on the classpath and no other SecurityFilterChain bean is present, Spring Boot's auto configuration secures all actuators other than /health. If you define a custom SecurityFilterChain, that auto configuration backs off and your rules decide access to the actuators.
• The base path can be moved with management.endpoints.web.base-path, so an endpoint does not have to live under /actuator.

A heap dump is a snapshot of every object in memory. In a service that talks to databases, queues and other APIs, that usually includes connection strings, passwords read from configuration, OAuth client secrets, bearer tokens held in session objects and fragments of whatever records were being processed. Spring Boot's own env and configprops endpoints sanitize values by default, replacing them with asterisks, but a heap dump is raw memory and has no such filter. That is why an exposed heapdump is usually far worse than an exposed env.

The same documentation lists other sensitive endpoints, including threaddump, env, configprops, logfile, shutdown and sbom.

Scanning for exposed heap dumps is routine

A diary entry published on 27 July 2026 by a well known internet threat monitoring service (linked in Sources) describes requests seen in the wild for /admin-api/actuator/heapdump. This is general activity, not activity linked to Amadeus or to either event in this post. The details it published are useful for anyone checking their own logs:

The diary's point is that scanners already assume management endpoints may be moved off the default path and protected only by weak passwords. Moving the base path is not access control.

What is not in the record

• No CVE, no affected or fixed versions of any Amadeus product, and no indication that a Spring Boot vulnerability was involved. As heise describes it, Event 2 was an exposed feature, not a flaw in Spring Boot's code.
• No IOCs from Amadeus, Korean Air, Asiana or any regulator.
• No statement that Event 2 was exploited by anyone other than the people who reported it, and no statement that it was not.
• Neither event appears in any known exploited vulnerability catalogue, because neither is a product vulnerability with a CVE.

How a shared booking platform turns into a shared exposure

Airlines do not run every piece of their reservation stack themselves. The Korea Times describes how carriers share booking, ticketing and passenger information with travel agencies, partner carriers and other providers in real time, and why building all of that in house would be expensive. Global providers sit in the middle of those flows. ZDNet Korea reports that about 200 airlines use Amadeus.

That arrangement creates two kinds of shared risk, and the two events this month are one example of each.

The first is identity risk. A provider's system accounts can reach data for many customers at once, and if one login is misused, those customers learn of it only when the provider tells them. Korean Air, by its account, found out from a formal notice at 22:44 on a Tuesday night.

The second is configuration risk. A non production or "display" environment that carries real booking data is, from a data protection point of view, production. If it exposes a management endpoint, the secrets in that environment's memory become the attacker's starting point. heise's description, that administrator passwords in the dump gave read and write access to a global system, shows how a single exposed debugging feature can widen into much broader access.

Neither pattern is specific to aviation, so the checks below are written for any team.

What to do now

If you are a passenger

1. Read any email from your airline about this carefully and check the sender address. Korean Air says no secondary damage has been confirmed, but asks customers not to click unclear links, open attachments or enter personal data on request.
2. Treat any message that quotes your booking reference and asks for card details, a "verification" payment or passport scans as suspicious, even if the reference is correct. Go to the airline's app or type its address yourself.
3. If you are not sure, call the airline using the number on its official site. heise, reporting a separate warning from the North Rhine-Westphalia data protection commissioner about fraud with stolen hotel data, gives the same advice: be suspicious of any request to verify card details by email or messenger.
4. If a booking has been changed without your knowledge, contact the airline directly and ask for the change history.

If you run a travel agency or booking office

1. Review which staff and system accounts can sign in to every booking, ticketing or GDS tool you use. Remove anyone who has left and any shared logins.
2. Ask your provider for sign in history for your office IDs, covering at least August 2023 onward if you work with any Amadeus product. Ask what it can tell you about access in that window.
3. Brief staff that customers may receive convincing phishing that quotes real booking details. Agree on a script for verifying requests that come in by phone or email.

If you run Spring Boot services

1. Find every service that includes Actuator.

# Maven
mvn -q dependency:tree -Dincludes=org.springframework.boot:spring-boot-actuator

# Gradle
./gradlew dependencyInsight --dependency spring-boot-actuator --configuration runtimeClasspath

# Across many repositories
grep -rl --include=pom.xml --include=build.gradle --include=build.gradle.kts \
  "spring-boot-starter-actuator" .

2. Find the configuration that exposes or moves endpoints.

grep -rnE "management\.(endpoints\.web\.(exposure\.(include|exclude)|base-path)|endpoint\.heapdump|server\.port)" \
  --include=*.properties --include=*.yml --include=*.yaml .

Look for include=*, include: "*", any list that contains heapdump, and any base-path change. Also check environment variables in deployment manifests, such as MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE, because those override files.

3. Check what each running service actually exposes, from outside your network, without downloading a dump. The discovery page lists the endpoints that are exposed.

# Replace with your own hostname and any custom base path
curl -s https://your-service.example.com/actuator | jq '._links | keys'
curl -s -o /dev/null -w "%{http_code}\n" https://your-service.example.com/actuator/env

You want a 401, 403 or 404 from the internet. If the discovery page lists heapdump, env or threaddump without asking for credentials, treat it as an incident, not a ticket.

4. Close the exposure. A conservative baseline:

# Expose only what load balancers and dashboards need
management.endpoints.web.exposure.include=health,info
management.endpoints.web.exposure.exclude=heapdump,threaddump,env,configprops,logfile,shutdown

# Turn the heap dump endpoint off completely (Spring Boot 3.4 and later)
management.endpoint.heapdump.access=none

# Serve management endpoints on a separate port that is not routed publicly
management.server.port=8081

On older Spring Boot lines that predate the access property, use management.endpoint.heapdump.enabled=false instead. If you use a custom SecurityFilterChain, make sure it requires authentication and a specific role for the actuator request matcher, because Spring Boot's default protection backs off once you define your own chain.

5. Search your logs for past requests.

grep -E "/actuator/(heapdump|env|threaddump|configprops|logfile)|/heapdump" access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -50

Add any custom base path to the pattern. Any successful (200) response to heapdump from an address you do not recognise means every secret the service held at that moment should be treated as exposed.

6. Find stray dump files. Heap dumps also end up on disk from -XX:+HeapDumpOnOutOfMemoryError and from manual troubleshooting.

find / -xdev \( -name "*.hprof" -o -name "heapdump*" \) -size +1M 2>/dev/null

Check object storage buckets and shared drives used for support tickets too. A dump attached to a ticket is as sensitive as the service's password file.

7. Rotate. If an endpoint was exposed, rotate the database passwords, API keys, OAuth client secrets and signing keys the service used, then invalidate sessions and tokens it issued. Rotating only the obvious one is the common mistake.

If you are a provider whose platform holds many customers' data

1. Inventory service accounts. List every non human account that can read customer data across tenants: what it can reach, who holds its credentials, when they were last rotated and whether it requires a second factor or a workload identity.
2. Shorten credential lifetime. Replace static passwords on system accounts with short lived tokens issued to a workload identity where your platform allows it. Where it does not, rotate on a schedule and on every staff change.
3. Alert on unusual use. A system account should behave like a machine. New source networks, new hours, new query shapes or a jump in distinct records read should page someone.
4. Keep logs long enough to answer questions. An estimated window of more than three years, as in Event 1, is only answerable with logs that go back that far. Decide what retention you need to scope an incident, not only to debug.
5. Treat any environment with real customer data as production. Display, demo, staging and support environments that hold live records need the same management endpoint rules, the same secrets handling and the same external testing as production.

If you buy from such a provider

Questions worth asking any booking, payroll or SaaS provider this week:

• Which of your system accounts can read our data, and how are their credentials issued, stored and rotated?
• Do any non production environments hold our real data? How are they tested from outside?
• How many days of access logs do you keep for our data, and can you give us sign in history on request?
• What is your notification commitment to us, in hours, after you confirm unauthorized access?
• Which of your services expose management or debugging endpoints, and how are they restricted?

In Korea, ZDNet Korea notes that under the Personal Information Protection Act the data controller must notify users without delay once it learns that a processor it entrusted with data has leaked personal information, which is what Korean Air and Asiana did. Under the EU GDPR, a processor must inform the controller without undue delay after becoming aware of a breach, and the controller must notify its supervisory authority within 72 hours where the breach is likely to create a risk. Your contract should say how the provider will help you meet those clocks.

What changed since first reports

• 13 October: heise's report described Event 2 and carried Amadeus's statement. At that point, nothing public mentioned Korean carriers.
• 23 October: Korean Air and Asiana disclosed Event 1. Early headlines in several outlets combined both airlines with one sentence on payment data; the airlines' own statements are more precise. Korean Air confirmed PNRs and said other items are still being verified; Asiana said payment data was not included.
• As of 26 October: no affected count for either event, no statement from Amadeus on Event 1, and no answer from the BSI to heise.

Open questions

1. How many passengers are affected in each event, and in which countries?
2. Which data fields beyond PNRs were exposed in Event 1?
3. How were the system account credentials in Event 1 obtained, and whose account was it?
4. Was the Event 2 environment accessed by anyone other than the people who reported it to heise?
5. Are the credentials in Event 1 related to the secrets exposed in Event 2? No source says either way.
6. Are other Amadeus airline customers affected by Event 1? ZDNet Korea raises the possibility; no airline or Amadeus has confirmed it.
7. Will Korea's Personal Information Protection Commission or a European data protection authority open an inquiry? We found no announcement.

What would have helped

None of this is a judgement on Amadeus, Korean Air, Asiana, Lufthansa or Condor. The airlines notified customers within about three days of receiving formal notice. Amadeus says it fixed Event 2 and strengthened monitoring. The question for everyone else is what makes the same classes of event smaller on their own platforms and in their own supply chains.

Practices any team can use

• Know which vendors hold which data. Keep a register of every provider that stores or processes customer records, with the data fields, the environments and the contact for incident notices. When a notice arrives at 22:44, you should not be looking up who your account manager is.
• Put service accounts on a short leash. Scope them per tenant where possible, give them workload identities instead of passwords, require a second factor where a human can sign in, and rotate on a schedule.
• Make machine behaviour boring and alert on change. Baseline what each system account reads and from where. Alert on deviations, not only on failed logins.
• Never expose management endpoints publicly. Use a separate management port that is not routed from the internet, require authentication and a role, and turn heapdump off where nobody needs it.
• Test every environment that holds real data from the outside. Display, staging and support environments included. An external scan of a host's paths would have shown an open management endpoint in minutes.
• Treat misconfiguration as a vulnerability class. OWASP's Top 10 lists security misconfiguration, including unnecessary features and debugging endpoints left enabled, as its own category.
• Patch the frameworks you run. Spring Boot's documentation page lists several supported lines (4.1.2, 4.0.9 and 3.5.16 among the stable releases shown when we checked). Staying on a supported line keeps both security fixes and current defaults.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API.

To be plain about the limits: neither event in this post is a vulnerability in an open source package. Event 1 is misuse of a valid login. Event 2, as heise describes it, is an exposed management feature, not a flaw in Spring Boot's code. Zero-Day Discovery would not apply to either, there is no CVE to look up in Gold Open Source, and Safeguard has no advisory and no patched build related to either event. Where these capabilities help is the layer under services like these: keeping the Spring Boot, Spring Security and other open source components current and rebuilt quickly when an advisory lands, so that the work after an incident can focus on identity and configuration.

Where Safeguard fits

Honest scope first: Safeguard would not have prevented either event. It does not manage another company's service accounts, does not watch how a provider's system account is used and does not see inside a provider's environments.

What Safeguard does cover, and where it is relevant to these two patterns:

• DAST tests running web applications from the outside. Registering every internet facing host of a Java service that you own and have verified, including display and staging hosts, as a DAST target is the kind of external check that surfaces exposed endpoints you did not know about. Pair it with the curl checks above.
• Dependency and image scanning of the repositories and container images behind those services: safeguard scan --dir . for a repository, safeguard scan --image <name> for an image and safeguard scan --sbom <file> for an SBOM, with JSON results under ./output. That gives you a list of every service that ships spring-boot-actuator and which Spring Boot line it is on.
• Component search across projects: the platform shows which projects contain a given component and version, so you can find every place a framework ships.
• Vulnerability matching and reachability analysis, to rank the vulnerable code paths your application actually calls first.
• Policies and gates evaluated in the platform, so a build that falls behind a supported framework line can be held for approval.
• Autonomous remediation with tested fix pull requests, which ships off by default.
• The Safeguard CLI assistant, which can edit code and configuration and run commands with your approval; since CLI v11.10.0 it asks before any command that changes something, and you can tighten that under /permissions with modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to find every application.yml that exposes heapdump, change each to the baseline above and add a test that the actuator discovery page returns 401 without credentials.

Where Safeguard does not help: it does not replace identity governance for service accounts, does not rotate credentials for you, does not monitor production traffic or a provider's logs, and cannot tell you whether a third party's environment was accessed.

Common mistakes and troubleshooting

• Moving the base path and calling it fixed. /admin-api/actuator is still found by scanners, as the July diary shows. Require authentication and a role.
• Defining a custom SecurityFilterChain without actuator rules. Spring Boot's default protection backs off when you define your own chain. Add an explicit matcher for actuator endpoints.
• Excluding heapdump in one profile only. Check every profile and every environment variable override. The production profile is not the only one that reaches the internet.
• Rotating one secret. A heap dump holds every secret in memory at that moment. Rotate all of them and invalidate tokens.
• Treating a PNR leak as harmless because cards were not included. A real booking reference makes phishing far more convincing. Warn customers anyway.

FAQ

What happened to Korean Air and Asiana customers?

Amadeus notified Korean Air on 20 October that customer data may have leaked through unauthorized access using login credentials assigned to an Amadeus system account, between August 2023 and September 2026. Korean Air confirmed booking reference numbers were exposed. Asiana confirmed booking related information was exposed and said payment data was not included.

What happened with Lufthansa and Condor passenger data?

heise online reported on 13 October that a Spring Boot heap dump in an Amadeus booking system was reachable without authentication and held credentials that gave wide access. Passenger records it saw, many for Lufthansa and Condor flights, included names, dates of birth, PNRs, contact, ID and passport data. Amadeus says it fixed the issue.

Are these the same incident?

No source says so. They involve different access methods, different airlines in the reporting and different disclosure dates. Amadeus has commented only on the heap dump exposure. Whether the credentials used in the Korean case relate to the heap dump is an open question.

Was payment data exposed?

Amadeus told heise that payment or financial data could not be accessed in the display environment exposure. Asiana says payment information was not included in its case. Korean Air has confirmed PNRs and is still verifying other fields.

How many people are affected?

Nobody has published a number for either event.

Is there a CVE or a patch to install?

No. Neither event is a vulnerability in a product you install. There is nothing for passengers or agencies to patch. Teams running their own Spring Boot services should review Actuator exposure as described above.

What should passengers do?

Expect phishing that quotes real booking details. Do not click links in unexpected messages, never send card details or passport scans in reply to an email, and check bookings through the airline's official app or website.

Would Safeguard have prevented this?

No. Safeguard does not manage a provider's service accounts or environments. It can help teams find their own exposed endpoints through external testing, keep frameworks current and fix configuration with approved changes, which reduces the chance of the same patterns in their own systems.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Amadeus, any airline or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a team running Java services that hold customer or booking data.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a Spring Boot service, you would run /scan . in its repository, then ask the assistant to find every Actuator exposure setting, apply the baseline from this post and add a test that /actuator returns 401 without credentials, approving each change.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform team could pick the folder that holds its booking or customer API, ask for every application.yml and deployment manifest to be checked for heapdump exposure and a moved base path, and approve or deny each proposed edit itself.

Click through it at your own pace, or open it full screen.

This session connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. A security lead preparing vendor questions after a notice like Korean Air's could ask Claude which of the team's own projects ship spring-boot-actuator and on which Spring Boot line, with Claude reading only the tools the lead allowed.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For another incident at a provider many companies depend on, read our post on the IDCF Cloud ransomware incident and third party risk. For finding every affected product fast, see SBOM incident response, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• heise online: Security vulnerability in flight booking system (13 Oct 2026, English)
• heise online: Sicherheitslücke in Flugbuchungssystem (13 Oct 2026, German edition)
• Kyunghyang Shinmun: Personal data of Korean Air customers leaked via overseas partner Amadeus (23 Oct 2026)
• MoneyToday: Even reservation numbers leaked, Korean Air subcontractor data exposed (23 Oct 2026)
• Seoul Economic Daily: Korean Air, Asiana report data breach at booking system operator (23 Oct 2026)
• Financial News: Personal data leaked from Korean Air and Asiana at reservation system partner (23 Oct 2026)
• Asia Business Daily: Korean Air, Asiana customer information leaked through IT service provider (23 Oct 2026)
• ZDNet Korea: Korean Air and Asiana confirm personal data leak via IT partner (24 Oct 2026, Korean)
• Korea Times: Korean Air breach exposes blind spot in airline cybersecurity (25 Oct 2026)
• Spring Boot documentation: Heap Dump (heapdump) endpoint
• Spring Boot documentation: Actuator endpoints, exposure and security
• Internet Storm Center diary: Java Spring Boot heapdump scans (27 Jul 2026)
• OWASP Top 10: A05 Security Misconfiguration
• The Points Guy: Amadeus PNR flaw and statement (January 2019, context)
• Personal Information Protection Commission of Korea (English site)
• Amadeus newsroom (checked 26 Oct 2026 for a statement on the Korean case; none found)

Last reviewed: 26 October 2026. This is a developing story; check the linked advisories for the latest status.