As reported by SecurityAffairs, the extortion group FulcrumSec claims to have stolen 86GB of data from Manchester Airports Group (MAG) by exploiting Iterable API credentials left exposed in client-side JavaScript. The breach, disclosed on August 27, 2026, affects customers across Manchester, London Stansted, and East Midlands airports. MAG states 8.7 million customers were impacted—mostly with email addresses exposed—while FulcrumSec's samples suggest far richer data: booking histories, travel itineraries, marketing profiles, and nearly 200,000 records tied to upcoming 2026 travel.

Key Takeaway: As reported by SecurityAffairs, the extortion group FulcrumSec claims to have stolen 86GB of data from Manchester Airports Group (MAG) by exploiting Iterable API credentials left exposed in client-side JavaScript.

The Real Story: Secrets in the Browser Are Not Secrets

What makes this breach notable isn't the attacker's sophistication. It's the opposite. FulcrumSec reportedly didn't need a zero-day, a supply chain compromise, or an advanced persistent threat toolkit. They opened browser developer tools and read API credentials that MAG's website was serving to every visitor.

Any credential that exists in client-side JavaScript is, by definition, public. It is only a matter of who decides to look.

This is a failure pattern Shield53 sees repeatedly across industries. Development teams embed third-party API keys—marketing platforms, analytics SDKs, payment integrations—directly into front-end code because it's the path of least resistance. The Iterable platform, a customer engagement and email marketing service, uses API keys that can access customer data, trigger campaigns, and export subscriber lists. Placing those keys in JavaScript means anyone loading the webpage can extract them with a single view-source or a glance at the Network tab.

Disclosure Gap: 8.7 Million Emails vs. 86GB of Data

The delta between MAG's disclosure and FulcrumSec's claims is itself a security story. MAG's public statement describes a limited exposure surface: car park bookings, lounge reservations, Fast Track purchases, and WiFi registrations. FulcrumSec's shared samples, which BleepingComputer partially validated against a real traveler's booking history, suggest the actual compromise may be significantly broader.

This gap matters for several reasons:

Disclosure Gap: 8.7 Million Emails vs. 86GB of Data
Regulatory exposure: Under UK GDPR and the Data Protection Act 2018, breach notification obligations are tied to actual data scope. If the 86GB claim holds, MAG's initial disclosure may be materially incomplete.
Customer risk: Nearly 200,000 records tied to upcoming travel create targeted phishing and physical security risks. An attacker knowing a traveler's flight date, terminal, and booking details can craft highly convincing lures.
Trust erosion: When a breach disclosure is later shown to understate impact, the reputational damage compounds—often exceeding the cost of the breach itself.

Third-Party API Risk Is the Under-discussed Attack Surface

Iterable is not the culprit here. The failure is in how MAG's development team integrated the platform. But this incident underscores a broader issue: SaaS and marketing platforms that expose powerful APIs with keys designed for server-to-server use are routinely misconfigured into client-side deployments. The industry needs to shift accountability toward platforms that make it technically difficult to misuse their credentials—through scoped tokens, referer-based restrictions, or server-side proxy requirements.

Shield53 Recommendations

Immediate Actions

  • Audit all client-side code for embedded API keys, tokens, or secrets. Use automated scanners like gitleaks, truffleHog, or browser-based inspection across all public-facing properties. Any credential found in JavaScript must be treated as compromised.
  • Rotate all exposed credentials immediately. Revoke and reissue any API key that has ever been deployed to client-side code. Assume it has been accessed.
  • Implement a server-side proxy pattern for all third-party API calls. The browser should never hold credentials with data access privileges. Front-end calls should route through your backend, which holds secrets server-side and enforces authorization.

Structural Fixes

  • Adopt a secrets management policy that explicitly prohibits any credential in client-side code. Enforce with CI/CD pipeline checks that scan build artifacts for known secret patterns before deployment.
  • Scope API keys to least privilege. If a key only needs to trigger event tracking, it should not have export or list permissions. Many SaaS platforms support scoped keys—use them.
  • Apply IP allowlisting and rate limiting on third-party API keys where supported. A key stolen from JavaScript becomes useless if it can only be used from your server infrastructure's IP range.
  • Conduct third-party API configuration reviews as part of regular security assessments. The integration point between your application and a SaaS vendor's API is a high-value, often-overlooked attack surface.

For Organizations in Travel, Hospitality, and Critical Infrastructure

This breach should prompt an urgent review of how customer booking and travel data flows through marketing and engagement platforms. The combination of personal identifiers with upcoming travel dates creates elevated risk profiles that demand stronger access controls than generic PII alone.

The FulcrumSec claim is a reminder that attackers are actively browsing public websites for low-hanging fruit. The barrier to entry is a browser and curiosity. Defenders must ensure that nothing worth taking is sitting in plain sight.