Palo Alto Networks has warned that ransomware crews are continuing to exploit an authentication bypass flaw in PAN-OS and Prisma Access to open unauthorised VPN sessions and sidestep multi-factor authentication — five months after the vendor shipped a fix. The company attributes the activity to the Qilin and INC Ransomware groups, according to The Hacker News, which reported the disclosure on 15 October.
The vulnerability, CVE-2026-0257, carries a CVSS base score of 7.8 and was patched in May 2026. Exploitation has nonetheless run on into October. That timeline is the story: for internet-facing perimeter appliances, a fix sitting available but unapplied is a recurring, measurable exposure rather than an edge case.
MFA bypass by omission
The detail defenders need to grasp is where in the connection flow the attack lands. The flaw lets an unauthenticated party establish a VPN session on the affected appliance at a point in the exchange where the second-factor challenge is never triggered.
The control does not fail; it is simply never reached. Nothing is cracked, no token is stolen, and no cryptographic weakness in the authenticator is involved — the challenge never fires, so MFA is bypassed by omission rather than broken. Any authentication checks configured on downstream applications inherit the same gap, because those applications are trusting a session the VPN already considers legitimate.
The implication for architecture is straightforward: MFA that sits behind the tunnel only protects traffic the tunnel has already admitted. On an exposed VPN gateway, MFA remains necessary but is not sufficient on its own.
The patch exists — the exposure persists
A CVSS 7.8 authentication bypass remediated in May is in the hands of named ransomware crews in October. The relevant question for any organisation running PAN-OS firewalls or Prisma Access is therefore not whether a fix exists — it does — but whether the firmware running in production reflects it.
Predictable organisational mechanics fill that gap. Change-approval queues and maintenance freezes delay deployment; network and security teams split ownership of the same appliance; and branch, remote or overflow devices are missed entirely by remediation sweeps that assume the estate is what the CMDB says it is. For Hong Kong enterprises running Palo Alto Networks gear at the network edge, these are familiar conditions rather than hypothetical ones — and the interval between shipped and deployed firmware is a risk factor that can be counted in days, not hand-waved as bureaucratic overhead.
Where to start
Palo Alto Networks' official advisory is the authoritative source for affected versions, fixed releases and detection guidance, and teams should work from that document directly rather than from secondary summaries. In the meantime, a reasonable response sequence looks like this:
- Inventory every appliance — including branch and remote devices — and compare running versions against the vendor's fixed releases.
- Examine VPN session logs for connections whose source addresses, timing or account activity don't match known users.
- Check whether VPN services are exposed more broadly than necessary; retire unused tunnels and overly permissive rules.
- Confirm authentication, tunnel-establishment and configuration-change events are logged and retained long enough to support investigation.
- Re-check MFA enforcement downstream of the VPN for exceptions, legacy paths and skip rules.
- Hunt beyond this single CVE — credential collection, lateral movement and ransomware staging associated with Qilin and INC.
Why it resonates
Patch latency on internet-facing infrastructure is not a bureaucratic footnote; it is a measurable risk factor, and this incident puts a number on it. The same principle applies well beyond Hong Kong deployments or Palo Alto hardware — any team that cannot answer "who connected from where, and when" will discover the gap in its VPN gateway instrumentation during an incident rather than during a readiness review. The log aggregation and session-analysis work required to answer that question is the same work required to detect this kind of access at all.
The vendor has stated that exploitation is ongoing. For teams still running affected builds, the practical takeaway is a deadline, not a warning: the fix has existed since May, and the attackers are not waiting for the change window.
Palo Alto Networks 已發出警告，指勒索軟件組織持續利用 PAN-OS 及 Prisma Access 的身份驗證繞過漏洞，開設未經授權的 VPN session，從而避開 multi-factor authentication（MFA）——而供應商早在五個月前已發布修補程式。據 The Hacker News 報道，該公司將此行為歸因於 Qilin 及 INC Ransomware 兩個勒索軟件組織，相關披露於 10 月 15 日報道。
該漏洞編號為 CVE-2026-0257，CVSS 基本評分為 7.8，並已於 2026 年 5 月修補。然而，針對該漏洞的攻擊活動一直持續至 10 月。這個時間線正是問題所在：對於面向互聯網的邊界設備而言，修補程式雖然已經存在卻從未套用，這不是罕見的例外情況，而是反覆出現、可量化的風險暴露。
因疏漏而導致的 MFA bypass
防禦人員需要掌握的關鍵，在於攻擊發生在連線流程的哪一個環節。該漏洞令未經身份驗證的一方可以在受影響的設備上建立 VPN session，而攻擊觸發的位置正是第二重驗證挑戰（second-factor challenge）從未發出的階段。
該項防禦機制並非失效，而是從未被觸發。沒有任何加密被破解、沒有 token 被盜取，驗證器本身亦不存在任何密碼學弱點——因為挑戰從未發出，MFA 是因疏漏而被繞過，而非被攻破。下游應用程式上設定的任何身份驗證檢查都會繼承同一個缺口，因為這些應用程式所信任的 session，VPN 已經視為合法。
對系統架構而言，其含意相當直接：位於隧道後方的 MFA，只保護隧道已經放行的流量。對於暴露在外的 VPN gateway，MFA 仍然必要，但單靠它並不足夠。
修補程式已存在——風險暴露仍在持續
一個 CVSS 7.8 的身份驗證繞過漏洞，早在 5 月已獲修補，到了 10 月卻落在具名勒索軟件組織手中。因此，任何運行 PAN-OS 防火牆或 Prisma Access 的機構，相關問題並非修補程式是否存在——它確實存在——而是生產環境中運行的韌體是否已反映該修補。
可預期的機構運作因素填補了這段落差。變更審批（change-approval）佇列及維護凍結期拖延了部署；網絡團隊與安全團隊對同一台設備的權責劃分不清；而分支機構、遠端或備用設備，則完全被假設網絡資產等同 CMDB 記錄的修補程序掃描所遺漏。對於在香港網絡邊緣部署 Palo Alto Networks 設備的企業而言，這些並非假設情況，而是熟悉的現實——而已發布韌體與已部署韌體之間的時間差，是一項可以按日計算的風險因素，不應以「官僚流程開支」一句帶過。
從何著手
Palo Alto Networks 的官方公告是了解受影響版本、已修復版本及檢測指引的權威來源，團隊應直接依據該文件行事，而非依賴二手摘要。與此同時，合理的應對次序大致如下：
- 盤點每一台設備——包括分支機構及遠端設備——並比較運行版本與供應商已修復版本之間的差異。
- 檢查 VPN session 日誌，找出來源地址、連線時間或帳戶活動與已知用戶不符的連線。
- 檢查 VPN 服務的暴露範圍是否超出實際需要；停用不再使用的隧道及權限過寬的規則。
- 確認身份驗證、隧道建立及配置變更事件均有記錄日誌，且保留足夠時間以支持調查。
- 重新檢查 VPN 下游的 MFA 強制執行情況，留意例外情況、舊有路徑及 skip rules。
- 追查範圍不應局限於此單一 CVE——包括與 Qilin 及 INC 相關的憑證收集（credential collection）、橫向移動（lateral movement）及勒索軟件部署活動。
為何值得關注
面向互聯網基礎設施的修補延遲並非官僚流程的註腳；它是一項可量化的風險因素，而此次事件為此提供了一個具體數字。同一原則並不僅限於香港部署或 Palo Alto 硬件——任何無法回答「誰從哪裡、在何時連線」的團隊，都會在事故發生期間而非準備程度檢討期間，才發現其 VPN gateway 監測 instrumentation 的缺口。要回答這個問題所需的日誌匯聚及 session 分析工作，與偵測此類未授權存取所需的工作，其實是同一件事。
供應商已聲明攻擊仍在持續。對於仍在運行受影響版本的團隊而言，實際的結論不是警告，而是一個限期：修補程式自 5 月起已經存在，而攻擊者並不會等待變更窗口（change window）。