回顧過去的重大事故，不去重現攻擊，而是聚焦於『對當下你的維運真正有用的教訓』。
發生了什麼：寫入一行日誌成了攻擊途徑
Log4j 是承擔日誌輸出這一極其常見處理的函式庫，在 Java 應用程式中被非常廣泛地使用。問題在於，這個函式庫會把日誌所含字串中的特定寫法解釋為『參照外部進行解析』的功能，結果導致執行由外部指定的程式碼。
也就是說，攻擊者只需在『會被記入日誌的位置』（使用者名稱、HTTP 標頭等）放入經過構造的字串，就有可能在伺服器端導致程式碼執行。日誌輸出這種被動的處理竟然可能成為攻擊途徑，這讓許多人大感意外。
為什麼難以判斷自己是否受影響
許多應用程式並沒有直接引入 Log4j。是框架或 SDK 在內部使用了它。這就是 傳遞性相依（transitive dependency）。相依套件的相依套件，再往下還有相依套件。如果手裡沒有自己的『物料清單』，連是否受影響都無從判斷。
最大的問題是不知道自己是否在用
在『不知道是否在用』的狀態下，連處置的優先順序都無從排定。是否掌握自己的物料清單（SBOM），在很大程度上決定了能多快應對。
時間軸
2021-12-09〜10
漏洞被廣泛知曉，全世界一齊奔走確認『我們是否受影響』。緊隨其後
緊急修補與臨時緩解措施陸續展開。攻擊嘗試也急劇增多。此後
修補此前修復不足的後續 CVE 接連公布。『修過一次』並沒有就此結束。
至今依然有效的教訓
擁有 SBOM（物料清單）
把自己的應用程式在內部使用了什麼可視化出來。用 npm ls、鎖定檔與 SBOM 產生工具掌握『實際在運行的相依套件』。只看『直接引入的東西』是不夠的。
用機器監控相依套件
在 CVE 公布的那一刻，自動判定是否受影響（Dependabot / osv-scanner）。能連同傳遞性相依一起檢查，正是機器監控的強項。靠人工檢查必然會有遺漏。
加快修補的維運
平時就固定練習「升級、驗證、上線」的流程，以便在緊急時刻能迅速完成。也請參閱 相依套件跟進的機制。
追蹤後續 CVE
Log4Shell 之後，對修復的再修復出現了多次。不要在『修過一次』就收手；要持續追蹤後續報導。
接下來閱讀
- 術語：什麼是 RCE / 什麼是 CVE
- 框架：Spring Boot 資安對策（相依套件 CVE、Actuator、反序列化）
- 對策：把相依套件的機器監控納入維運
- 事故：放任已知 CVE 導致 1.47 億人資訊外洩的故事
- 事故：Heartbleed——OpenSSL 的重大缺陷
來源與確認範圍
以下原始資料支持上文的設定、影響範圍或應對措施，連結於2026年10月23日確認。請核對資料中的版本與設定條件。清單優先順序及經驗是本站的整理，不代表全文重新核驗或安全保證。