Spirit Airlines is dead. Its attack surface isn't.
The security story isn't that an airline went bankrupt. It's what happens to 132 APIs, years of customer PII, and a cloud footprint when a company dies overnight and nobody is left to decommission it.
Spirit Airlines ceased all operations at 3:00 AM ET on May 2, 2026. Seventeen thousand employees. Thirty-four years of operations. The first major US airline to go out of business due to financial problems in twenty-five years, killed by its second bankruptcy in under a year after an Iran war jet fuel price surge destroyed what remained of its restructuring plan. When Trump administration bailout talks collapsed on May 1, there was nothing left to negotiate with.
The coverage has focused on passengers scrambling for refunds and workers losing jobs. Those are the visible consequences. The less visible one is what happens to a modern airline’s digital infrastructure when there is no one left to turn it off.
The obvious read
A company goes bankrupt, its websites display shutdown notices, its apps stop working. This happens regularly. Toys “R” Us, Bed Bath & Beyond, Silicon Valley Bank. The bankruptcy estate handles asset disposition, creditors get what they can, the domain eventually expires or gets sold.
That reading misses the operational reality of how modern cloud infrastructure actually fails. It does not fail cleanly. It decays. Services stop being paid for but don’t stop resolving. DNS records point to resources that no longer exist. API endpoints time out instead of being formally decommissioned. And each of those dangling references is a potential entry point for anyone who knows how to claim the orphaned resource on the other end.
What Spirit actually built
Spirit was not running a static website and a reservation system. According to MuleSoft case studies, Spirit built an API-led architecture on MuleSoft and Azure comprising 132 reusable APIs connecting 60 applications. That is a substantial cloud footprint: flight operations, crew scheduling, loyalty programs, payment processing, partner integrations, mobile apps, kiosks. Each API endpoint has a hostname. Each hostname has DNS records. Each DNS record points to a cloud resource.
When the money stops, some of those cloud resources get terminated by providers for non-payment. But DNS records don’t automatically clean themselves up. The domain names have been transferred to a bankruptcy-remote SPV in the Cayman Islands as part of the brand IP disposition. The domains keep resolving. The CNAME records still point to Azure resources that may no longer be provisioned under Spirit’s account.
That gap between “the cloud resource is gone” and “the DNS record still points to it” is where subdomain takeover attacks live.
The threat is documented, not theoretical
A threat actor tracked as Hazy Hawk has been exploiting exactly this pattern since at least December 2023. Infoblox documented Hazy Hawk hijacking abandoned cloud resources at the US Centers for Disease Control, Deloitte, PricewaterhouseCoopers, Ernst & Young, MIT, Harvard, and Stanford. The technique: find a subdomain with a CNAME record pointing to a deprovisioned cloud resource, provision a new resource at the same cloud address, and inherit the subdomain’s traffic and reputation. CDC subdomains ranked high in search results because of accumulated domain trust. Hazy Hawk used that trust to host scam URLs and malware delivery pages.
In February 2024, researchers uncovered SubdoMailing, a campaign that had hijacked over 8,000 domains and 13,000 subdomains by registering expired domains and injecting IPs into orphaned DNS records. The scale was staggering, but the mechanic was simple: find abandoned DNS infrastructure, claim the other end, inherit the trust.
Spirit’s architecture is a textbook target for this class of attack. A company with 132 API endpoints on Azure, now in full liquidation, means 132 cloud resources that will stop being paid for on different timelines. Some will lapse in days. Others may have prepaid commitments that run for months. The DNS records pointing to all of them will outlive every one of those resources unless someone actively removes them. And the bankruptcy estate’s incentive is to maximize asset recovery, not to audit CNAME records.
The data problem is worse
Spirit held years of passenger data. Names, addresses, email addresses, payment card information, passport numbers, travel itineraries. We know this because Spirit has already demonstrated it cannot protect this data. In 2021, the Nefilim ransomware group stole over 40 GB of data from Spirit, including customer financial information spanning 2006 to 2021. A credential-stuffing incident followed in 2023.
During liquidation, customer data becomes an asset. Creditors want to maximize recovery. In 2015, RadioShack attempted to sell 117 million customer records during its bankruptcy proceeding. The FTC intervened, requesting that the bankruptcy court impose restrictions on how the data could be used by any buyer. The restrictions were ultimately adopted, but the FTC had to actively petition the court. The protections did not exist by default.
Whether a similar intervention will occur for Spirit’s passenger data is an open question. Airlines hold data categories that retailers do not: passport numbers, travel itineraries, Known Traveler Numbers, Global Entry identifiers. The sensitivity floor is higher, but the regulatory mechanism is the same as it was in 2015. There is no automatic data-destruction requirement triggered by a company’s liquidation.
The exposure surface is wide, and the mitigations are manual
The operational concern extends beyond Spirit’s customers to any organization that had an integration, a partnership, or an API connection with the airline. The exposure categories are familiar: dangling DNS records, orphaned API endpoints still receiving authentication tokens, OAuth credentials pointed at domains entering uncontrolled ownership transitions, SPF and DKIM records referencing infrastructure nobody is maintaining, and TLS certificates that anyone with control of a DNS record can reissue through domain validation.
What makes this structurally hard is that every one of those mitigations is manual. There is no automated process that inventories your CNAME records pointing at a defunct partner and removes them. There is no system that revokes API credentials when the counterparty stops existing. Each integration was built by a specific team for a specific purpose, and that team has to remember the integration exists, understand that Spirit’s infrastructure is now a liability rather than a service, and take action before someone else claims the other end.
The bankruptcy estate has no incentive to help. Its mandate is asset recovery, not infrastructure hygiene. The SPV holding Spirit’s brand IP controls the domain names but may have neither the technical staff nor the legal mandate to audit CNAME records pointing to Azure resources it does not own. The gap between “this company no longer exists” and “this company’s DNS records no longer resolve” is filled by manual labor that nobody is contractually obligated to perform.
What to watch
Two questions are worth tracking.
First, who is responsible for decommissioning Spirit’s cloud infrastructure? The bankruptcy estate has a legal obligation to maximize creditor recovery, which creates an incentive to sell assets, including domains and possibly data, not to methodically tear them down. The SPV holding the brand IP controls the domain names, but it is unclear whether that entity has the technical staff or the mandate to audit and clean DNS records pointing to Azure resources that the SPV does not own.
Second, how long until the first subdomain takeover? Spirit’s domains carry years of accumulated search engine trust, inbound links, and email reputation. That trust is valuable to threat actors for exactly the same reason it was valuable to Spirit. PatchDay Alert will track any certificate issuance or DNS changes on Spirit-associated infrastructure as they surface in the daily feed.
The structural lesson is not specific to airlines. Any organization with a substantial cloud footprint can die faster than its infrastructure can be decommissioned. The controls that prevent abandoned infrastructure from becoming attack infrastructure are manual, labor-intensive, and misaligned with the incentives of a bankruptcy proceeding. The gap between “this company no longer exists” and “this company’s attack surface no longer exists” is measured in months, sometimes years. For the 132 APIs Spirit built and the data they carried, that clock started at 3:00 AM on Friday.
Sources
- Spirit Airlines ceases all operations (NPR)
- Spirit Airlines shuts down (CNBC)
- Spirit Airlines canceled all flights (CNN)
- Spirit Airlines API-led architecture (MuleSoft case study)
- Hazy Hawk exploits DNS records to hijack CDC, corporate subdomains (The Hacker News)
- Hazy Hawk threat actor profile (Infoblox)
- 8,000+ subdomains of trusted brands hijacked for spam (SubdoMailing)
- FTC requests bankruptcy court protect RadioShack consumer data (FTC)
- Don't abandon that domain name (CSO Online)
- Abandoned domains as cyber threats (Terranova Security)
- Safeguarding against subdomain takeover (SecurityScorecard)
Share
Related field notes
-
Three hours was the good outcome: npm's trust model and the Axios compromise
A DPRK threat actor backdoored two Axios versions on npm. Socket flagged the malicious dependency in six minutes. Nothing stopped the downstream publish fifteen minutes later. The system worked exactly as designed.
-
50 CVEs in 18 months is not a growing pain. It's a design choice the industry keeps making.
MCP went from unknown to default AI integration in under two years. The vulnerability count, the OWASP Top 10, and the simultaneous client failures tell a story about what happens when adoption is the only metric.
-
The Vercel breach is the Heroku/Travis CI playbook, rerun through an AI tool
A compromised OAuth token at a small AI productivity company gave attackers a path into Vercel's internal systems. The structural pattern is four years old. AI tools are making it worse.