FulcrumSec宣稱竊取MAG約86GB資料，樣本顯示內容超出先前公告，疑與暴露的Iterable API憑證及客戶端JavaScript有關，但整體規模與入侵手法尚未獲獨立證實。
英國曼徹斯特機場集團（Manchester Airports Group，MAG）資料外洩事件再度升溫，資料勒索團體 FulcrumSec 向 BleepingComputer 宣稱對其發動攻擊，並聲稱竊取約 86GB 資料。BleepingComputer 檢視部分疑似遭竊樣本後指出，內容不僅包含 MAG 先前已公布的電子郵件、電話、車牌與郵遞區號，還出現旅客預訂、行程與交易相關資訊，顯示外流內容可能比官方初步揭露更完整。
根據報導，MAG 先前已對外表示，受影響資料涉及 Manchester、London Stansted 與 East Midlands 等機場的車位、貴賓室、Fast Track 預訂，以及機場 Wi-Fi 註冊資料。FulcrumSec 另聲稱外洩內容包含近 20 萬筆尚未成行的旅遊預訂紀錄，並指稱攻擊者是透過暴露在用戶端 JavaScript 中的機場專用 Iterable API 憑證取得存取權。不過，BleepingComputer 也明確指出，目前僅能確認樣本看似真實，尚無法獨立驗證 86GB 規模、近 20 萬筆記錄的說法，以及完整入侵路徑與範圍。
從已公開資訊來看，這起事件的核心風險不只在於資料量，而在於資料粒度。若外流樣本確實包含預訂狀態、交易關聯、旅客識別資訊與行程內容，攻擊者就能把看似零散的資訊拼接成可直接利用的情資，進一步提高針對性釣魚、詐騙與身分冒用的成功率。
FulcrumSec 宣稱的入侵方式也值得關注。若 Iterable API 憑證真的被硬編碼或暴露於 client-side JavaScript，代表敏感憑證已進入可被終端使用者直接取得的範圍。這類設計常見的問題是，前端程式碼本質上可被瀏覽器端檢視，任何放入前端的密鑰、Token 或存取參數，都可能在不經意間被逆向、抓取或濫用。
此外，若該 API 憑證確實可存取旅客服務或行銷資料庫，則風險不僅是單一帳號或單一介面的失守，而可能延伸為資料匯出、查詢權限過大、權限控管鬆散，甚至是供應商整合流程中的信任邊界失效。換言之，真正需要檢討的未必只是「哪一把鑰匙外洩」，而是「這把鑰匙為何能接觸到如此廣泛的資料」。
目前最重要的技術判讀是：BleepingComputer 已確認樣本具有相當真實性，代表事件不是單純的恐嚇貼文，但對於整體資料集大小、完整欄位、實際存取路徑，仍缺乏獨立佐證。因此，後續調查應聚焦於三個方向：前端程式碼是否暴露敏感憑證、API 權限是否過度授權，以及資料匯出與第三方整合是否缺乏稽核軌跡。
已知影響對象涵蓋 Manchester、London Stansted 與 East Midlands 機場相關客戶。MAG 先前公布的資料類型包括電子郵件、電話、車牌與郵遞區號；而 BleepingComputer 看到的樣本則顯示，外流資訊可能進一步延伸到預訂、旅程與交易層級的細節。
若 FulcrumSec 所稱近 20 萬筆未成行旅遊預訂紀錄屬實，受影響範圍將不只是已知聯絡資訊，而是包含未來出行計畫。這意味著攻擊者可能掌握旅客何時、何地、以何種服務往返機場，這類資訊對社工攻擊、假冒客服、行程釣魚郵件與精準詐騙都具有高度價值。
另一個值得警惕的重點，是 BleepingComputer 曾將其中一筆旅客資料與其過往在曼徹斯特機場的消費紀錄比對，結果發現多項預訂與交易資訊相符。這表示樣本不只是「看起來合理」，而是可能包含與真實消費紀錄相互對應的資料片段，讓事件的實際敏感度進一步升高。
就營運層面而言，這類事件也會削弱旅客對機場數位服務的信任。只要車位預訂、貴賓室服務、Fast Track 與 Wi-Fi 註冊等常見資料流被視為可能外洩，後續所有依賴數位預訂與會員整合的機場服務，都可能面臨更高的合規、品牌與客服壓力。
對於機場營運業者與同類型交通運輸組織，首先應立即盤點所有前端程式碼、靜態資源與第三方整合模組，確認是否存在可被直接讀取的 API 憑證、Token 或測試金鑰。任何出現在 client-side JavaScript 中、且可存取後端資料的敏感資訊，都應視為高風險設計缺陷。
其次，應重新檢查 API 權限邊界與最小權限原則。若單一憑證能查詢大量旅客資料、匯出預訂清單，或跨服務讀取行銷與交易欄位，就必須縮小可見資料範圍，並以分權、分環境、分用途方式拆解存取能力。
第三，應強化稽核與異常行為偵測。像是大量查詢、批次匯出、異常來源地請求、短時間內高頻 API 存取，都應觸發警示。若這些活動未被記錄或未被告警，事後就很難釐清資料外流的時間軸與影響範圍。
第四，應加強資料分級與去識別化處理。對外可被重組出行程、交易與身分關聯的欄位，應避免在非必要場景中完整暴露。尤其是郵遞區號、車牌、預訂編號、購買參考碼與行程狀態等欄位，單獨看似零碎，組合後卻可能形成高可利用性情資。
最後，企業應把第三方服務納入同等級的安全管理。若資料流經行銷平台、預訂系統或客戶互動平台，供應商存取權限、密鑰管理、前端植入方式與事件應變流程，都應定期審查，不可因外包或 SaaS 身分而降低標準。