零日漏洞利用是使用軟件、韌體或硬件弱點的方法或程式碼，在相關情況下有效修復尚未可用。弱點本身是漏洞，使用弱點的方法是利用，針對目標的實際嘗試則是攻擊。NIST 的零日攻擊定義着重利用此前未知的漏洞。［1］

不同來源會着眼於發現、披露或修補可用性，讀報告時先確認它指哪個階段，不假設所有「零日」說法都一樣。本文配合數碼私隱基本框架，協助判斷暴露風險，不提供攻擊重現步驟。

關鍵要點

漏洞、利用方法與實際攻擊是不同事實，證明其中一項不代表其餘。

披露可能先於修補，發佈修補亦不等於裝置已安裝。

臨時防護限制指定途徑，要在自己的環境確認。

官方公告及實際受影響版本，比驚人的標籤更能指導行動。

零日漏洞利用與漏洞、攻擊為何要分開？

假設廠商發現某功能不能正確處理不可信輸入，這是漏洞；有人找出藉此取得非預期能力的方法，這是利用；把方法用於目標才是攻擊。這只是概念次序，真正發現可以在攻擊已開始後才發生。

公告可能確認弱點，卻未確認攻擊者已使用。研究示範可證明某些條件下可行，不等於大規模濫用。已在野利用的報告提高緊迫性，但仍不證明你的裝置被攻擊。分清可以避免大意，也避免無根據聲稱感染。

Cloudflare 以尚無修補的弱點解釋零日利用。［2］應結合時間線看：弱點最初是零日，後來即使公開，未更新設備仍可能受影響。標題不再稱零日，不會自動修好已安裝軟件。

名稱或公告	它說明甚麼	它未證明甚麼
漏洞被發現	受影響元件有弱點	你的版本受影響或已失守
利用方法被示範	方法在指定條件下可行	每項配置都可被利用
已有實際攻擊報告	攻擊者曾使用弱點	所有用戶被針對
修補已發佈	指定版本有修復	你的裝置已成功安裝
臨時措施建議	控制可限制某條途徑	底層弱點已移除

零日如何經過披露和修補？

研究者、廠商、防禦人員或攻擊者都可能先找到問題。廠商核查版本和條件，準備修復及指引。開發期間可以私下披露，也可能在修補準備好前公開，沒有統一時限；公開報告不保證立即有安全更新。

有用公告會列出元件、版本、前提、修復方法及是否觀察到攻擊。記下日期，指引可能更新。早期資料不足時，不用同產品另一漏洞的條件填補。

修補發佈後仍須部署。下載不等於安裝，安裝可能需要重啟裝置或服務。瀏覽器、路由器、作業系統與應用各有更新途徑，應透過支援界面核對最終版本。一個程式顯示「最新」不代表全部元件。

組織部署或需相容檢查和停機安排，但不宜無限延後。按風險指定負責人與期限，記錄臨時防護並確認關鍵系統真正完成。個人設備檢查自動更新與待重啟狀態，不只看舊通知。

出現公告後應查核甚麼？

從已知官網或支援渠道進入廠商公告。突然出現的「緊急更新」也可能散播惡意軟件，不因附件提到真漏洞便安裝。新聞有識別編號時，用它找到原公告並比對說法。

配對實際產品、版本、系統和配置。有些問題需要特定功能開啟、服務外露或用戶打開指定內容，有些所需互動較少。把條件轉成實際問題：元件在不在，誰可接觸，現在有甚麼控制？

修補與事件應變要分開。只使用受影響版本時，更新或減少暴露；若另有可信失守證據，保存紀錄並求助。更新能關閉途徑，卻不能證明過去是否被利用；沒有明顯症狀亦不能回答歷史問題。

惡意程式碼概覽解釋可能的後果，不把每個漏洞視為惡意軟件。鍵盤記錄器擷取輸入，殭屍網絡涉及遙控裝置；它們可能伴隨攻擊，但零日名稱不證明其存在。

未有修補時可以做甚麼？

採用廠商或負責保安團隊為該配置建議的措施，例如停用弱點功能、限制服務存取或暫停使用產品。控制可能有運作代價，尤其受管理或關鍵設備，先核對哪些功能會停止。

個人有時可暫停相關活動，改用未受影響的替代方案，但不能假設任何替代品都安全。查核是否共用同一受影響元件，及官方指引是否支持，並記下改動理由與覆查時機。

網絡過濾、隔離及監察在某些環境有用，效果取決於利用途徑。過濾不能保證攔截全部加密請求或裝置內發動的攻擊，偵測規則可能只看見已知樣式。每項控制應按具體緩解作用描述，不當成萬能防線。

不要複製社交平台上未核實的設定指令。停用功能亦可能破壞存取或削弱另一項防護；目的不明時停止並諮詢官方支援。臨時措施要有退出方案：修補可用時安裝及驗證，只在更新指引允許後移除限制。

一般習慣能防範未知弱點嗎？

它們減少暴露，不保證阻擋所有未知漏洞。保持支援中的軟件更新、減少不必要服務，只授予任務所需權限。處理不可信內容的設備限制敏感資料可及範圍；功能較少可縮小攻擊面，不代表剩餘功能毫無弱點。

備份是復原工具，並非阻止利用的方法。測試重要檔案能還原，盡可能令備份不受同一失守存取影響。系統映像可帶回有漏洞版本或錯誤設定，因此恢復危險活動前仍要更新。

黑客防護的能力界線區分連接加密與軟件修復。針對裝置或應用的攻擊，不會因流量改路而自動被阻止。

起底指南提醒並非所有傷害都需要技術入侵，公開資料可以直接被聚合。定向間諜軟件則可能使用複雜利用；Pegasus 指南解釋高風險通知為何要專業支援，不能只靠掃描沒有結果判定安全。

如何確認眼前風險已處理？

訂下具體驗收：受影響系統已識別、廠商措施已套用、最終版本已查核、所需重啟完成、臨時控制已覆查。組織報告應對應真正裝置，不只說已安排更新；單一電腦應在重啟後查版本。

繼續看公告修訂，首個修復或只覆蓋部分條件，亦可能要再更新。一次安裝成功不代表所有風險解決。曾懷疑失守時繼續獨立應變，處理帳戶、資料曝光及證據。

合理結論是「受影響瀏覽器已運行廠商修復版本」，具體而可查證；「裝置不會再被入侵」缺乏依據，也不應成為驗收條件。

總結

分清弱點、利用方法與實際攻擊。
將公告配對真實版本、功能及暴露情況。
未有修復時用受支援臨時措施。
查核安裝結果，並分開處理疑似失守。

常見問題

零日一定對所有人都未知嗎？

不是，攻擊者或研究者可能早於廠商或公眾知道。報告的發現和披露時間線決定未知對象。

零日表示完全沒有防護嗎？

不是，受支援措施可減少某些途徑，但不移除弱點，也無法保證覆蓋所有利用方法。

發佈修補後漏洞仍有危險嗎？

有，未安裝相關修復的裝置仍可能脆弱。修補可用和成功部署是兩件需要分開查核的事。

裝置變慢能證明零日攻擊嗎？

不能，效能變化有很多原因，無法識別利用。疑似失守要依具體保安發現及專業調查。

應安裝緊急電郵裏的修補嗎？

自行進入廠商官方更新渠道，真實漏洞名稱也可令惡意附件或連結看來更可信，卻不會令它安全。

更新會消除先前攻擊的全部影響嗎？

不會，關閉漏洞未必撤銷被盜工作階段、移除持續控制或解決資料外洩，仍須額外應變。

為何不應試不明臨時指令？

效果未必符合配置，還可能影響服務或削弱保護。用有清楚查核和撤回方案的官方措施。

**免責聲明：**本文是一般風險管理資訊，並非取證評估。按設備所有者流程處理；關鍵系統、敏感工作或疑似定向失守應向合資格人士求助。

來源:

NIST CSRC - zero-day attack — https://csrc.nist.gov/glossary/term/zero_day_attack
Cloudflare - What is a zero-day exploit? — https://www.cloudflare.com/learning/security/threats/zero-day-exploit/

Sources checked 2026 年 10 月 5 日。

延伸閱讀:

甚麼是零日漏洞利用？分清漏洞與攻擊並評估修補前的風險