這是這週資安圈最該立刻處理的一條。Palo Alto Networks 在 2026 年 5 月 13 日發布安全公告，警告 CVE-2026-0257：一個遠端、未經認證的攻擊者，可以偽造「authentication override」認證 cookie，透過 GlobalProtect 閘道建立未授權的 VPN 連線。更糟的是，這不是理論風險——它已經被實際利用，CISA 已於 5 月 29 日將其納入 KEV（已知遭利用漏洞）目錄。
一、技術根因
技術上，問題出在一個非預設啟用的功能「authentication override」：它讓 GlobalProtect 入口網站與閘道發給已認證使用者一個類似 bearer token 的 session cookie，省去每次重新登入。漏洞的觸發條件很關鍵——只有當用來加解密這個認證 cookie 的憑證，被拿去和其他功能（例如入口／閘道的 HTTPS 服務）共用時，攻擊者才能偽造出有效 cookie。換句話說，這是一個「組態與金鑰隔離」層級的設計陷阱，而不是單純的程式 bug。
二、攻擊時間軸
Rapid7 MDR 的觀測讓時間軸更具體：最早的利用可追溯到 5 月 17 日，第一波攻擊來自 Vultr 託管的 IP；5 月 18 日偵測到針對本地管理員帳號的可疑 cookie 認證；5 月 21 日出現第二波，這次部分受害者在 cookie 認證後甚至被分配到完整的 VPN IP，等於攻擊者拿到了直連內網的入場券。緩解方式有兩條：停用 authentication override 功能，或為該功能產生一張專用、不與任何其他服務共用的憑證。
我的觀點
這個案例對我們做網站與系統的人，啟發遠不只「快去更新 Palo Alto」。它示範了一個一再重演的模式：為了使用者體驗而設計的便利功能（不用重複登入），一旦與「金鑰共用」這種看似無害的組態偷懶結合，就會變成繞過整套認證的破口。把它對應到我們天天碰的 Laravel／Nginx 環境，教訓是一模一樣的：JWT 或 session 的簽章金鑰，絕不能跨服務、跨環境共用；同一張憑證不要既當對外 TLS、又拿去簽 API token；APP_KEY 與各種 signing secret 要嚴格隔離、定期輪替，並確保測試／正式環境用不同的金鑰。我會把這次事件當成一次免費的紅隊演練提醒：回去盤點自己系統裡有沒有「一把鑰匙開很多門」的地方。便利與安全的拉扯永遠存在，但「憑證／金鑰隔離」這條線，是少數不該為了省事而退讓的底線。
資料來源
- CVE-2026-0257 PAN-OS: GlobalProtect Authentication Bypass — Palo Alto Networks Security Advisory
- Rapid7 Observed Exploitation of PAN-OS GlobalProtect Auth Bypass (CVE-2026-0257) — Rapid7
- PAN-OS GlobalProtect Authentication Bypass Under Active Exploitation — The Hacker News
- Hackers are exploiting Palo Alto GlobalProtect VPN auth bypass (CVE-2026-0257) — Help Net Security
- Palo Alto GlobalProtect VPN auth bypass flaw now exploited in attacks — BleepingComputer