I reported this on March 3rd, 2026. It is now June 16th. 105 days later. The critical vulnerabilities are still live. Frontier fixed the least important one and ghosted me on the rest. Your passport number is still leaking.
It Started With a Tweet
Someone posted their Frontier Airlines boarding pass on X. Unblurred. PNR and last name right there. But even if they'd blurred it, it wouldn't matter because the BCBP barcode on every boarding pass contains the PNR and last name in cleartext. Any barcode reader can decode it.
A real Frontier boarding pass posted publicly on X. The original poster blacked out their name and confirmation code, but left the barcode visible. I added the pink redactions.
Here's what most people don't know: the barcode on your boarding pass isn't just a random scanner thing. It's a BCBP (Bar Coded Boarding Pass) format defined by IATA. It contains your full name, PNR (booking confirmation code), flight details, and more, all in plaintext. Any barcode reader app on your phone can decode it in seconds. So even if you black out your name and confirmation number like this person did, the barcode gives it all away. Most people think they're being careful by hiding the text. They're not.
I wondered what you could do with just a PNR and a last name.
Turns out: everything. And I mean everything. Passport numbers, home addresses, credit card details, your kid's birthday. The full internal booking object, served raw like gas station sushi.
Vulnerability 1: The Mobile API That Returns Everything
Frontier's mobile app API has an endpoint that returns the entire raw internal booking object. The only authentication? A PNR and a last name. That's it. That's the security. Two pieces of information printed on every boarding pass in existence.
https://mtier.flyfrontier.com/bookingssv/GetBookingbyParams?lastName={LAST_NAME}&recordLocator={PNR}
The response includes, for every passenger on the booking (including children):
- Full home address (street, city, state, zip)
- Email address
- Phone number
- Full date of birth (including minors)
- Full unmasked passport number, issuing country, and expiration date
- Nationality
- Known Traveler Number (TSA PreCheck)
- Frontier Miles / loyalty program number
- Credit card last 4 digits, BIN (first 6), expiration date, cardholder name, and billing IP address
- Full payment history with authorization codes
- Internal system comments showing every email and SMS notification sent
- Baggage tag numbers, booking agent IDs, fare breakdown
- Gender and passenger type (adult/child)
The website masks passport numbers as XXXXX8151. The API returns the full number. No filtering. No masking. The complete internal booking object, dumped straight to the client.
Travel Documents (Passport Data)
The KTN (Known Traveler Number) document. documentTypeCode "K". Full name, date of birth, gender. All in the API response.
The passport document. documentTypeCode "P". Full passport number (redacted), nationality "IT", issued by "IT", expiration date 2034. The website masks this. The API doesn't.
Why the KTN Leak Matters
Your Known Traveler Number is what gives you TSA PreCheck. It's tied to your identity and lets you skip the long security line at US airports. If an attacker has your KTN, they can add it to their own booking and fraudulently gain PreCheck status, skipping enhanced security screening. You know, the screening that exists to stop bad things from happening on planes. TSA's own guidance says KTNs should be treated as sensitive and never exposed in client-side applications. Frontier dumps it in a JSON response to anyone with a 6-character code and a last name. Thanks Frontier, very cool.
Payment Data
Credit card details: accountNumber "XXXXXXXXXXXX7586" (last 4), expirationDate, BIN range, cardholder name, billing address including street/city/state/zip, billing email, billing IP address, authorization code, and payment amount ($609.88). All from one API call.
The binRange field in the JSON is the first 6 digits of the credit card number (the Bank Identification Number). Combined with the last 4 visible in accountNumber, that's 10 of 16 digits known. The 16th digit is deterministic (it's a Luhn check digit, calculated from the other 15). That leaves 5 unknown digits in the middle, which is ~100,000 possible combinations. That's not a theoretical attack, that's a for-loop.
Internal System Comments
Internal system comments logging every SMS and email notification sent to the passenger. "SMS Sent to [phone number]", "Email notify-gate-change sent to [email]@gmail.com". The API leaks contact info again through the notification logs even if you somehow missed it in the passenger data.
These comments are internal system logs. They re-expose the passenger's email and phone number in plaintext, embedded in notification text strings. Even if Frontier masked the contact fields (they don't), the comments would leak them anyway. It's like putting a privacy screen on your monitor but leaving the screen mirrored to a projector in the lobby.
In the booking I tested (from a publicly posted boarding pass on X), there was a 3-year-old child whose full name, date of birth, and gender were fully exposed.
Vulnerability 2: The Website Leaks Your Email Too
The Manage My Booking page at flyfrontier.com displays your email address and phone number as masked. Great, right?
Except the full unmasked email is sitting right there in the HTML source. And it has been through two different versions of the code.
How it used to leak:
The old page had two leaks: window._mfq JavaScript variables and hidden <span> elements. Both exposed the email.
window._mfq.push(["setVariable", "email", "[email protected]"]) alongside the PNR and last name.
<span class="js-email" hidden aria-hidden="true">[email protected]</span> and <span class="js-name" hidden aria-hidden="true">xxxxx</span>. Invisible on the page. Fully present in the source.
How it leaks now:
They removed both of those. Great, right? No. They replaced them with two new leaks that expose even more data. The old version only leaked your email. The new version also leaks your phone number.
window.NOIBUJS.addCustomAttribute('EmailAddress', '[email protected]') and addCustomAttribute('PhoneNumber', 'xxxxx'). Your email and phone number, in plaintext, in client-side JavaScript.
And the email also appears in a second place in the current page: an emailItinerary config object that includes currentEmail in plaintext:
"currentEmail":"[email protected]" sitting in a JavaScript config blob. Because one leak wasn't enough.
So to recap: the old page leaked your email in two places. They updated the code, removed those two leaks, and replaced them with two new leaks that also expose your phone number. They didn't fix the leak. They upgraded it.
Vulnerability 0: PNR Enumeration (The One They Actually Fixed)
I also found an endpoint that returned booking data for any valid PNR with no last name required:
POST https://booking.flyfrontier.com/F9Loyalty/Booking
Just a PNR. No last name. 200 OK. Full booking details, flight numbers, passenger names, seats, bags, miles. 4KB of data for a 6-character code.
PNRs are 6-character alphanumeric codes. They can be brute-forced. I confirmed this by pulling three separate bookings with PNRs that appeared to be incrementing. Three different passengers, three different bookings, zero authentication. This meant an attacker could enumerate bookings at scale with zero prior knowledge, harvest passenger names, then feed those into the mobile API for the full PII dump.
The complete attack chain requiring zero initial information:
- Brute-force PNRs against
/F9Loyalty/Booking - Get passenger names and booking details back
- Feed PNR + last name into the mobile API for the full dump (passport, address, KTN, payment details, everything)
This is the only vulnerability Frontier fixed. They closed the front door and left every window wide open. You just need a PNR + last name from a boarding pass photo instead of brute-forcing it. Progress!
Vulnerability -1: The Passengers/Edit Page
The Passengers/Edit page in the Manage My Booking flow just... shows everything. No masking.
First name, last name, email, phone number, country, zip code. All pre-filled, all unmasked.
Date of birth, gender, Known Traveler Number. Right there in form fields.
Here's the thing that kills me: the page before this one masks the passport number as XXXXX8151 and hides the email. Then you click "Edit Passengers" and the next page shows everything unmasked. Same booking. Same session. Same user. It's like locking the front door but leaving a sticky note on it that says "key is under the mat." If it's intentional masking, why does the edit page undo it? Did two different teams build these pages and never talk to each other? Is this a cry for help?
The server-rendered HTML also embeds a JSON blob containing:
- Full passport number (unmasked)
- Passport expiration date
- Passport issuing country
- Nationality
- Date of birth
- Known Traveler Number
- Frequent flyer number
- Email address
The full passport number, nationality, issuing country, and expiration date. Just sitting in the HTML source of the page.
The KTN exposure is particularly bad. Per TSA handling guidance, Known Traveler Numbers should not be exposed to client-side rendered pages at all. An attacker with someone's KTN could fraudulently use it to gain TSA PreCheck status.
The Credit Card Math (It's Bad)
As explained above, with the BIN (first 6), last 4, and the Luhn check digit (deterministic), only 5 digits are unknown. ~100,000 combinations. That's not a theoretical attack. That's a for-loop that runs in seconds. Add the cardholder name, expiration date, and full billing address (which satisfies AVS for card-not-present transactions), and the only missing piece is the CVV.
Any PCI-DSS qualified assessor would rate this critical. At minimum, this is a reportable cardholder data exposure event to the acquirer under PCI-DSS 12.10.1.
The Reporting Timeline (A Masterclass in Being Ignored)
| Date | What |
|---|---|
| March 3 | Initial disclosure: Vulns 1 and 2 reported to Frontier |
| March 5 | Follow-up: Found Vuln 0 (PNR enumeration), reported with urgency |
| ~March | Vuln 0 fixed. Vulns 1 and 2 remain live. They sent me a model plane. Cool? |
| April 9 | Follow-up with attack chain summary |
| April 21 | Follow-up: Retested, confirmed Vulns 1 and 2 still live. Reported new Passengers/Edit finding. Raised compensation discussion |
| May 13 | Follow-up: Still live. Set 30-day disclosure deadline (June 12). Pinky promise this time |
| June 12 | Deadline passed. Frontier: 🦗🦗🦗 |
| June 16 | Public disclosure. 105 days. Vulns 1 and 2 still live. You're reading this |
They sent me a model plane though. So there's that.
What's Still Live Right Now
As of June 16, 2026. Yes, really. I just checked again while writing this:
- Vulnerability 1 (mobile API full PII dump): STILL LIVE. Full passport numbers, home addresses, children's DOB, KTNs, credit card details. All of it.
- Vulnerability 2 (email leak in HTML): STILL LIVE. Full unmasked email in page source.
- Passengers/Edit page leak: STILL LIVE. Passport numbers, KTNs, DOB in server-rendered JSON.
- Vulnerability 0 (PNR enumeration): Fixed.
If you've ever flown Frontier and someone has your PNR and last name (from a boarding pass photo, a social media post, a discarded boarding pass, an airport trash can), your passport number, home address, and payment details are accessible right now. If you traveled with children, their dates of birth and full names are exposed too.
To Frontier Airlines
I gave you 105 days. I set a 30-day deadline. You let it pass. You had more time than it takes to grow a tomato from seed.
You fixed the easiest vulnerability (the enumeration endpoint) and left the ones that actually leak passenger PII wide open. That's like fixing a broken window on a house that has no walls.
Your passengers deserve better. Their children deserve better.
- Filter your API responses. The mobile app does not need the full internal booking object.
- Mask passport numbers in the API the same way you mask them on the website.
- Remove KTNs from client-side HTML entirely.
- Remove unmasked emails from page source.
- Report the cardholder data exposure to your acquirer per PCI-DSS 12.10.1.
- Respond to security researchers. 105 days of silence is not a vulnerability management strategy. It's not even a strategy. It's just vibes.
So long and thanks for all the fish.
Thanks for the model plane though. It's sitting ontop of my wardrobe. The wheels broke, just like your security. (The wings didnt fall off but I took one off for the blog header for added comedic effect.)