資安
資安新手入門 07|照理說應該沒問題:技術回答裡的四種模糊說法
當你問工程師或廠商系統有沒有備份、漏洞有沒有影響時,如果聽到「應該、理論上、正常來說、照理說」這四個詞,代表對方還沒打開系統看過。本文教你怎麼把模糊推論換成查證過的事實。
這是恩梯科技資安週報的第三期,涵蓋 2026 年第 45 週(11 月 2 日起),資料讀取到 11 月 6 日為止(出刊前 11 月 8 日另外補查了兩項,補查結果就寫在對應的段落裡)。這一週的三件事可以用一句話串起來:修補版號對了,不代表那個洞真的補完了。
最急的一件先講:如果你的網站是 WordPress,而且還沒更新到 7.1.4,現在就去更新。上一期報過的那個「升級過程中的遠端程式碼執行」漏洞,11 月 3 日被美國 CISA 列進「已知遭利用」清單,而 CISA 給聯邦機關的處理期限就是 11 月 6 日——也就是本期開工的這一天。更要緊的是,CISA 這一筆把「需要事後鑑識」標成 Yes,那個標記不是每一筆都有。
第二件是這一週真正的大批次:Symfony 在 11 月 4 日一次公布 21 則安全公告,散在 13 個元件上,修補版依元件而異(多數是 5.4.56、6.4.50、7.4.23、8.1.11)。數量本身不是重點,重點是其中六則的官方標題逐字寫著「Incomplete Fix」——前一次的修補沒有把問題解決完,而且每一則都點名自己補的是哪一個舊編號;另外還有一則更直接,它是前一次修補造成的退行。上一期我們才報過 Symfony 承認五月那句「已修補」是錯的,這一期同一個形狀出現了七次。
第三件是 Chrome 157(11 月 3 日晉升穩定版),官方那句逐字是「This update includes 213 security fixes.」。213 這個數字看起來嚇人,但它是大版本晉升累積下來的,不能直接拿去跟上一期「Chrome 156 修 21 項」比——這一點下面第三節會講清楚。
〔官方:美國 CISA〕CVE-2026-119977 於 11 月 3 日進入 CISA 的「已知遭利用漏洞」清單(Known Exploited Vulnerabilities,KEV)。我們讀的是 CISA 自己發布的資料檔,版本為 2026.11.04,當時全清單共 1768 筆。CISA 對這個漏洞的描述逐字是:WordPress 核心含有一個 time-of-check time-of-use(TOCTOU)競態條件漏洞,可能讓未經驗證的攻擊者在升級的那段時間窗內在伺服器上執行程式碼,原因是全套件核心升級過程中使用了可預測、而且可從網路存取的暫存路徑。
三個細節值得單獨看:
〔官方:WordPress〕WordPress 7.1.4 的官方公告把這一條列在安全修補清單的第一項,逐字是:「A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window, reported by Umut Bayram.」同一版還修了多個 Interactivity API 的儲存型 XSS、Customizer 選擇性刷新的 XSS、分類區塊的 XSS,以及一個儲存型阻斷服務問題。官方公告的用語是「Because this is a security release, it is recommended that you update your sites immediately.」
官方公告沒有給 CVE 編號,也沒有給受影響的版本範圍。那兩件事是我們另外去查的:編號來自 CISA 與 NVD,而 NVD 對這個漏洞的評分是 CVSS 3.1 的 8.1(HIGH),列出的受影響範圍從 4.7 一路往上涵蓋各個分支。所以「我只看官方公告」在這一條上會少掉嚴重度與範圍,這不是官方失職,是兩種來源各自負責不同的事。
〔官方:Symfony〕Symfony 在 2026 年 11 月 4 日一次公布 21 則安全公告。兩個官方管道的數字一致:symfony.com 的 2026 年 11 月封存頁上有 21 篇公告文章,Packagist 的安全公告 API 查 symfony/symfony,回報日期為 2026-11-04 的也是 21 則。
先說一個我們自己踩進去的坑,因為你很可能用同一個方法追公告:這 21 篇的網址分成兩種寫法。16 篇的網址是 /blog/ghsa-…,另外 5 篇是 /blog/cve-…。我們第一次數的時候只比對了 ghsa 那個寫法,於是數成 16 篇,還以為官方部落格比 Packagist 少了 5 則。那個結論是錯的,是我們自己的比對方法漏掉了另一種網址。
這個坑值得寫下來,因為它不是只會發生在我們身上:只要你是用網址樣式、RSS 標題前綴或關鍵字在過濾公告,同一個廠商換一種命名就會讓你少看到一批,而畫面上不會有任何東西變紅——你只會看到「這週就這些」。
重數之後我們繼續往下查,結果比「數字對不對」更有用:這 21 則在四個官方管道裡長得不一樣,而你用哪個工具掃,看到的就是哪一個版本。
| 資料集 | 這批有幾則 | 有 CVE 編號的 | 有沒有嚴重度 |
|---|---|---|---|
| symfony.com 的公告文章 | 21 | 5(寫在標題裡) | 沒有 |
| Packagist 安全公告 API | 21 | 5 | 沒有(severity 欄是空的) |
| GitHub 上 symfony/symfony 的 repo 公告 API | 21 | 9 | 每一則都有 |
| GitHub 的「全域」公告 API | 0 | — | — |
逐列說明,因為每一列的意思都不同:
Received——已登錄、NVD 還沒分析完,所以當時四個都還沒有 CVSS 分數;出刊前 11 月 8 日再查一次,四個都有分數了(狀態已變成 Awaiting Analysis):CVSS 4.0 依上面的順序是 5.3、2.3、2.3、6.3,其中 CVE-2026-121949 與 CVE-2026-123125 另有 CVSS 3.1 的 5.4 與 6.5。兩套分數不要混著比:CVE-2026-121949 在 4.0 是 2.3(LOW)、在 3.1 是 5.4(MEDIUM),同一個洞在兩套系統裡連級別都不同。給分的來源也不是同一個,而 NVD 的回應只給來源識別碼、沒有給機構名稱,所以我們不替它命名。而 symfony.com 與 Packagist 到我們查的時候都還沒有這四個編號。這一節想講的不是「哪個資料集才對」——四個都是官方的,而且四個都沒有說謊,它們只是各自記錄了不同的欄位、各自的更新速度不同。要記的是這一句:真正能對帳的是「兩個以上的來源總數一不一樣」,而不是「我有沒有訂閱」。而如果你的掃描工具只接一個來源,它給你的嚴重度與編號就是那一個來源的版本,不是全貌。
這一批不是同一個元件連續出問題,而是一次大掃除。逐篇讀下來的分布是:HTTP Foundation 3 則、Serializer 3 則、HTML Sanitizer 3 則、HTTP Client 2 則、Security HTTP 2 則,再加 Config、JSON Path、YAML、HTTP Kernel、Filesystem、Routing、Validator 各 1 則,以及 1 則同時屬於 Framework Bundle 與 HTTP Foundation。
修補版不是每一則都一樣,這一點很容易看漏。多數公告寫的是 5.4.56、6.4.50、7.4.23、8.1.11 四個版本;但 HTML Sanitizer 那三則是從 6.4.50 起才有修補(5.4 那條線沒有這個元件),JSON Path 那則只在 7.4.23 與 8.1.11。所以「我們升到最新的修補版了」要對著自己實際用到的元件看,不是看一組通用版號。
這一批裡最值得非技術決策者讀的不是數量,是下面這六則的性質。它們不是新發現的功能缺陷,而是先前那一次修補沒有把問題收乾淨——而且 Symfony 把這件事寫在標題裡,不是藏在內文:
access_control 與防火牆的 methods 選項。標題逐字標為 Incomplete Fix for CVE-2026-45075。pcre.backtrack_limit 在每次比對前後調低到 10000,但那個上限是「每一個起始位置」而不是「每一次呼叫」,所以成本會隨著字串長度一再累加。第七則不是「沒補完」,是前一次修補造成的退行(GHSA-3h27-hjv7-fqjx,HTTP Foundation):路徑規則可以靠在腳本名稱後面接字串來繞過。官方說明逐字:自從 CVE-2025-64500 的修補之後,Request::getPathInfo() 會把腳本名稱從網址開頭去掉,而且在腳本名稱只是某個較長路徑片段的開頭時也會去掉。於是當 SCRIPT_NAME 是 /index.php 時,請求 /index.phpadmin 會被當成 /admin 來路由。受影響的範圍也因此不是「所有舊版」,而是從 5.4.50、6.4.29、7.3.7 起——也就是說,升得比較勤的人才會中這一條。
七則放在一起,是一句對老闆有用的話:「我們上個月已經更新過了」不足以回答「這個洞補好了嗎」。修補本身也會有 bug,而且修補造成的退化通常只影響已經更新的人。這也是為什麼巡檢要有固定節奏,不是更新一次就結案。
其中一則修的是「程式化登入會跳過使用者檢查器的 checkPostAuth()」(GHSA-8f57-m8wj-x65w,Security HTTP)。官方在「Resolution」那一段明說了副作用:修好之後,checkPostAuth() 丟出的例外會從 Security::login() 與 authenticateUser() 冒出來。另一則修 inline fragment 的那一條,也提到了「在子請求進行中讀取主請求的程式碼」行為會變。所以這一批不適合直接在正式環境按下升級就走——有自動化測試的話先跑一輪,特別是註冊、密碼重設、email 驗證那幾條會程式化登入的路徑。
〔官方:Google〕11 月 3 日的桌機穩定版公告逐字寫著「The Chrome team is delighted to announce the promotion of Chrome 157 to the stable channel for Windows, Mac and Linux.」版本是 157.0.8103.38/.39,而安全修補那一句逐字是「This update includes 213 security fixes.」
嚴重度分布是我們自己數的,官方沒有給彙總:Critical 7 項、High 77 項、Medium 75 項、Low 54 項。加起來剛好 213,與官方那句話一致,這就是我們敢把這組數字寫出來的唯一理由。
不要把 213 跟上一期的「Chrome 156 修 21 項」直接比。157 是大版本晉升,它一次清掉的是整個開發週期累積的項目;156 那一次是同一個大版本裡的小更新。兩個數字量的不是同一段時間,拿來比會得到「Chrome 一週內變差十倍」這種不存在的結論。
另外兩件可以直接拿去用的事:
還有一個細節,因為它是官方公告的原文、而且與我們這一行的轉變有關,所以照實列出來:這 213 項裡有 14 項的報告者,官方標註為 Anthropic 的研究員,而且逐字寫著「assisted by Claude」(Xinyang Ge 與 Vlad Stolyarov 兩人),其中包含 7 項 Critical 裡的一項(CVE-2026-121035,Prerender 的 use-after-free)。同一週 WordPress 7.1.4 的致謝名單裡也有一條 XSS 標著「reported by Anthropic」。這是兩個獨立的官方來源在同一週記下同一件事:找漏洞這件工作,已經有 AI 參與在裡面了。我們不替這件事下結論——它既不代表以後漏洞會變少,也不代表攻擊會變多,但它確實表示公告的數量往後可能只會更多,而「有沒有人固定在看」這件事會更吃人力的節奏,不是吃熱情。
〔官方:Next.js〕11 月 3 日發布 16.4.5 與 15.5.29,兩個版本的發行說明第一句都是「This release contains security fixes for the following advisories:」,而且全部列在 Moderate 之下,沒有更高的等級。
16.4.5 修 7 則,15.5.29 修 3 則(後者是前者的子集)。看標題就看得出它們是同一類問題——快取把不該跨越的界線跨過去了:use cache 透過 unstable_cache 呼叫時的跨租戶資訊洩漏、巢狀 use cache 在不同 root 參數值之間的快取洩漏、Cache Components 裡共用 fallback shell 被請求帶進來的佔位路由參數汙染、帶二進位參數時的跨使用者快取洩漏與汙染。另外三則(15.x 也有的那三則)是自架環境轉送抓取回應時的跨客戶端注入與洩漏、圖片最佳化的 SVG 拒絕機制被繞過,以及 Edge runtime 路由上 HttpOnly cookie 透過內部回應標頭外洩。
其中一則的官方標題結尾逐字是「(follow-up)」——跨 root 參數值的快取洩漏,是先前那一次修補的後續。這一週第三個廠商出現同一個形狀了。
一句實務上的話:這幾則的共同前提是你的系統有「不同使用者看到不同內容」而且開了快取。純靜態的行銷網站受影響的機會低;有登入、有會員、有多租戶的,這一批要排。
這兩筆都不是「現在要動手」,但它們是可以提前排的——而巡檢真正會被犧牲的原因,從來不是沒時間,是沒排進行事曆。
這一節的價值和上面幾節一樣:說得出哪些看過了而且沒事,才知道剩下的是什麼。以下每一條都是我們這一週實際讀過的,括號裡是我們讀到的最後一筆。
laravel/framework 最近一筆安全公告是 10 月 23 日。這一節是刻意留著的。一份週報如果只寫看到的東西,讀者會以為「這週就這些」——而漏掉什麼,只有寫週報的人知道。
repos/symfony/symfony/security-advisories 這個 repo 專屬的端點——我們自己打了一次,四個編號全部核到,而且順手拿到了只有那個資料集才有的嚴重度。所以第二節那張對照表是這一來一往的結果,不是我們單方面查出來的。(3) 另一則據稱影響 Laravel 13.x 的公告編號,仍然核不起來(GitHub 的全域公告 API 回 Not Found、Packagist 的 laravel/framework 沒有 11 月紀錄),所以沒有寫進結論。這一段留在這裡是因為它示範了一件事:「查不到」要寫成查不到,但也要把出處問清楚再下結論——我們第一輪的「查不到」是對的,第二輪的「核到了」也是對的,中間差的只是一個正確的端點。還有一個結構性的缺口,每一期都成立:這份清單不是從「我們維護的系統實際用了哪些套件」反推出來的,而是從兩條線的經驗長出來的。要讓它對你家的系統真的有覆蓋,得先有一份你自己的技術清單——那是系統健檢會做的第一件事。
恩梯科技是客製化開發出身的系統軟體公司,現在做的是 AI 系統的長期維護。這份週報每週整理,而長期維護要顧的正是這一節講不完的那部分:安全更新有固定節奏、緊急漏洞另外處理、升級前後有人驗。如果你不確定手上的系統用了哪些技術、有沒有人替你盯著對應的公告,可以從一次系統健檢開始:預約系統健檢
第 1 層(官方):CISA 已知遭利用漏洞清單資料檔 https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json ;WordPress 7.1.4 官方公告 https://wordpress.org/news/2026/10/wordpress-7-1-4/ ;WordPress 版本檢查端點 https://api.wordpress.org/core/version-check/1.7/ ;NVD 的 CVE-2026-119977 https://nvd.nist.gov/vuln/detail/CVE-2026-119977 ;Symfony 安全公告分類頁 https://symfony.com/blog/category/security-advisories ;Symfony 2026 年 11 月封存頁 https://symfony.com/blog/archives/2026/11 ;Packagist 安全公告 API https://packagist.org/api/security-advisories/ ;Chrome 桌機穩定版公告 https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop.html ;Next.js 16.4.5 https://github.com/vercel/next.js/releases/tag/v16.4.5 與 15.5.29 https://github.com/vercel/next.js/releases/tag/v15.5.29 ;Node.js 2026 年 11 月安全釋出預告 https://nodejs.org/en/blog/vulnerability/november-2026-security-releases ;Oracle 安全公告總頁 https://www.oracle.com/security-alerts/ ;PHP 2026 年新聞封存 https://www.php.net/archive/2026.php ;Laravel 13.40.0 https://github.com/laravel/framework/releases/tag/v13.40.0 ;GitLab 修補釋出 feed https://docs.gitlab.com/releases/patch-releases.xml ;Mozilla 安全公告 https://www.mozilla.org/en-US/security/advisories/ ;Go 版本歷程 https://go.dev/doc/devel/release ;Electron 釋出 https://github.com/electron/electron/releases 。
第 2 層(研究/媒體):本期沒有引用任何第二層來源,因為這一週一家都沒讀(見第七節)。
只與少數值得深入合作的夥伴建立長期關係。
需要協助嗎?
用 LINE 直接問我們