In May 2026 alone, 47,318 new travel-related domains were registered — a 33% increase from the prior month. One in every 112 was already classified as malicious or suspicious. Three coordinated bulk-registration campaigns were running simultaneously, impersonating American Express, Lloyds Travel Choice, and Fora Travel across hundreds of domains on short-lived TLDs. Check Point Research called it what it is: a deliberate, seasonal intensification targeting an industry that processes enormous volumes of personal and financial data precisely when people are distracted, rushing, and eager to secure a good deal.
The hospitality and travel sector recorded 2,291 average weekly cyberattacks per organization in May 2026 — a 24% year-over-year increase and a 122% cumulative rise since 2023. The global average across all industries over the same period: 2%. This is not a crime of opportunity. It is a crime of infrastructure.
Within this surge, one attack vector remains almost entirely undocumented and undetected at the email layer: the abuse of .pkpass files — the Apple Wallet pass format used by airlines, hotels, event venues, and ticketing platforms to deliver boarding passes, hotel keys, loyalty cards, and event tickets directly to a user's phone. This analysis examines how that format is being weaponized, why it is particularly effective against high-value executive targets, and why current email security tooling has no coverage for it.
A .pkpass file is the format Apple uses for Wallet passes — boarding passes, hotel keys, event tickets, loyalty cards, transit passes, and more. Technically, it is a ZIP archive containing JSON configuration files and PNG images, signed by an Apple Developer certificate. When you receive one in email, iMessage, or Safari, iOS recognizes the MIME type, displays a full-screen Wallet preview, and offers an Add button. The pass syncs to your Apple Watch. It works exactly as expected.
The format is designed for trust. A boarding pass looks like a boarding pass. A concert ticket looks like a concert ticket. The visual presentation — the airline logo, the seat number, the barcode, the gate information — is indistinguishable from a legitimate pass issued by the real airline or venue. And that trust is the attack surface.
Technical note: A .pkpass file cannot execute code on your device. Adding one to your wallet does not install malware. The signature proves which Apple Developer team issued the pass — not that the pass is benign. The attack is not in the file itself. The attack is in the email that delivers it, and in the links the pass and email contain.
The webServiceURL field in a pass tells Apple Wallet to poll a URL for updates. Every time your phone checks for a pass update, it sends your device push token, the pass's authentication token, your IP address, and device metadata to that URL. If the attacker controls the webServiceURL, they have a persistent, legitimate-looking communication channel to your device — one that was opened when you tapped "Add to Wallet" on what looked like your boarding pass.
More practically: the email delivering the .pkpass file almost always contains a link — "Manage your booking," "Update your seat," "Complete check-in," "Your gate has changed." That link is the payload. The pass is the trust mechanism that makes you believe the email is real.
The attachment: A boarding pass with the airline's correct logo, their name, seat number, flight details, and a working barcode. Adds to Wallet instantly. Works on their Apple Watch.
The email: A professional confirmation from what looks like the airline's domain. Correct formatting, correct branding, a link to "manage your booking."
The sender: A display name matching the airline. The email address looks close enough — especially on mobile where the full address is rarely visible.
The attachment: A crafted pkpass file signed with a purchased Apple Developer certificate. The webServiceURL points to attacker infrastructure. Every Wallet update poll leaks device metadata.
The email: The "manage your booking" link goes to a phishing page hosted on a travel-lure domain registered days earlier. The page harvests airline credentials, passport details, or payment information.
The sender: A lookalike domain — one character substituted, a hyphen added, a different TLD — registered during one of the coordinated bulk-registration campaigns identified by Check Point Research.
Attack model based on documented pkpass format capabilities and Check Point Research travel domain campaign analysis, June 2026.
For opportunistic attackers, the pkpass phishing chain is straightforward: register a lookalike travel domain, build a convincing booking confirmation email with a crafted pass attached, and send it at scale during peak travel season. The numbers support the approach — 47,318 new travel domains in May 2026 alone, one in 112 already flagged as malicious. The infrastructure is cheap, the lure is seasonal, and the target pool is enormous.
For targeted attackers pursuing a specific individual — an executive, a government official, a defense contractor — the chain has a more sophisticated upstream stage that has received almost no public analysis. It begins not with a fake email, but with a genuine one.
Key finding: The most effective pkpass phishing attack does not require creating a fake booking. It requires compromising the travel agent, corporate travel management platform, or executive assistant who handles real bookings — and inserting a malicious pass or link into an outgoing confirmation that the victim already expects to receive. The email is legitimate. The sender is legitimate. Only the attachment or the link inside it is not.
.pkpass file abuse as of July 2026. The same rulesets contain 25+ rules for QR code abuse — a related attack vector that receives extensive coverage. The gap is structural: pkpass files are treated as benign attachments by every email security tool that does not specifically analyze their internal structure and embedded URLs. A malicious boarding pass attachment will pass every standard email security check because nothing in those checks looks inside a pkpass file..pkpass attachment arriving from an unsolicited sender, combined with urgency language and a link to a recently registered or suspicious TLD domain, is detectable before delivery. The email security platform sits at exactly the right point in the chain — before the victim sees the pass, before they tap Add to Wallet, before the webServiceURL begins polling. The detection rule does not need to analyze the pass's internal structure. The combination of attachment type, sender profile, and link destination is sufficient signal for a high-confidence detection at the email layer.The pkpass threat operates at the intersection of two gaps: a format that is trusted by default and a detection category that does not exist yet. The following recommendations address both layers.
.pkpass file from an airline, hotel, or event venue that you have an existing relationship with is expected and benign. A pkpass from a sender you have no prior relationship with — or from a domain that does not match the travel company's known infrastructure — should be treated with the same suspicion as any other unexpected attachment. Before tapping Add to Wallet, verify the sender domain character by character. On mobile, where the full email address is often hidden behind a display name, view the full headers before acting..pkpass attachments from unsolicited senders, combined with urgency language and links to newly registered or suspicious TLD domains, catches the opportunistic version of this attack before delivery. The targeted version — where the email comes from a compromised legitimate sender — is harder to detect at the email layer but can be flagged through anomaly detection on sender behavior and booking confirmation patterns. A companion detection rule is in development and will be submitted to Sublime Security's open-source rule feed.| Technique | ID | Stage | Notes |
|---|---|---|---|
| Phishing: Spearphishing Attachment | T1566.001 | Delivery | pkpass attachment as phishing vehicle |
| Phishing: Spearphishing Link | T1566.002 | Delivery | Malicious booking management link in email body |
| Compromise Accounts: Email Accounts | T1586.002 | Initial Access | Travel agent / PA account compromise in targeted variant |
| Gather Victim Identity Information | T1589 | Reconnaissance | Passport details, loyalty numbers, travel schedule |
| Web Service: Dead Drop Resolver | T1102.001 | C2 | webServiceURL as persistent device polling channel |
| Steal Web Session Cookie | T1539 | Credential Access | Airline / hotel credential harvesting via phishing page |
| System Location Discovery | T1614 | Discovery | Real-time IP-based location tracking via webServiceURL polls |
Email security tooling has invested heavily in QR code detection — 25+ rules in major open-source rulesets, computer vision analysis, screenshot-based URL extraction from images. The investment is justified. QR code phishing has been a documented, high-volume attack vector for years. The tooling followed the threat.
The pkpass format shares the QR code's core mechanism — a barcode or QR code embedded in a visually convincing document that the victim trusts implicitly — but adds three capabilities that QR code phishing does not have: a persistent update channel via webServiceURL, a direct path into the most trusted app on a user's phone, and a format that has never been treated as a threat vector by any email security rule.
The travel sector's attack surge in 2026 — 122% cumulative growth, 47,318 malicious domains in a single month, three coordinated bulk-registration campaigns running simultaneously — is the delivery infrastructure for this vector at scale. The opportunistic version is already running. The targeted version, upstream-compromising a travel agent or PA to insert a malicious pass into a legitimate booking confirmation, has not been publicly documented. That absence is not a reason for confidence.
Artificial intelligence is accelerating every layer of this threat. The three coordinated bulk-registration campaigns Check Point identified — 210+ sequential hotel-lure domains, 108 Fora Travel domains across different TLDs — reflect automated infrastructure that would have required significant manual effort two years ago. AI-generated phishing copy makes the emails that deliver pkpass files grammatically perfect and contextually personalized at scale. AI image generation makes convincing fake boarding passes trivial to produce. And AI voice cloning — already documented in travel-sector vishing campaigns in 2025 and 2026 — means the follow-up call confirming a "booking issue" can sound exactly like the airline's real support staff. The human who manages an executive's travel is not failing when they are deceived by this. They are operating against an adversary whose tools have fundamentally changed while the awareness training has not.
The detection window is the email layer — before delivery, before the victim sees the pass, before Add to Wallet is tapped. That window closes the moment the pass lands in the inbox. What happens after that — the webServiceURL polling, the persistent location tracking, the credential harvest if the victim clicks the booking link — is difficult to catch and difficult to undo. The rule that catches this before delivery is simpler to write than the forensics required afterward.
This analysis is based on publicly available information including Check Point Research's June 2026 travel phishing report, Apple's published pkpass format specification, FBI advisory on Scattered Spider aviation sector targeting (2025), and Polyswarm's aviation and aerospace threat landscape report (May 2026). The upstream travel agent compromise attack chain described in Section 3 represents a technically validated but publicly undocumented threat model — it is analytical synthesis, not confirmed incident reporting. A companion Sublime Security detection rule targeting pkpass attachment abuse is in development and will be submitted to the open-source rule feed when complete. This analysis represents independent research produced as a contribution to the security community.
I'm a security researcher in Connecticut. Analysis is the part I love: tracing threat actor behavior, pulling apart supply chain attacks, and following evidence even when it lands on "unknown." When a question needs a tool that doesn't exist, I build it; most of the tools on this site started that way. Before security I spent 15 years designing enterprise software, which is why my tools assume a human will actually have to use them. I contribute detection rules to Sublime Security's open-source production ruleset. Security+ in progress. Everything here is independent work, shared as a contribution to the security community.