跳到主要內容
所有文章

資安週報 2026-W45:Symfony 一次 21 則

分類 資安 日期 2026-11-08

Author
恩梯科技
28 次閱讀 22 分鐘閱讀

這是恩梯科技資安週報的第三期,涵蓋 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 項」比——這一點下面第三節會講清楚。

怎麼讀這份週報

一、WordPress 的升級漏洞,這一週被官方認定正在被利用

〔官方:美國 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)競態條件漏洞,可能讓未經驗證的攻擊者在升級的那段時間窗內在伺服器上執行程式碼,原因是全套件核心升級過程中使用了可預測、而且可從網路存取的暫存路徑。

三個細節值得單獨看:

  • 處理期限是 2026 年 11 月 6 日。KEV 的期限只拘束美國聯邦機關,不是法律義務落在台灣企業身上;但它是一個可以借用的判斷——官方給自己人的時間只有三天,那代表官方認為這件事不能排到下個月。
  • 這一筆的「需要事後鑑識」(forensicTriage)標成 Yes。同一週另一筆新增的 Apple 漏洞(CVE-2024-27834,11 月 4 日列入,期限 11 月 18 日)這一欄是 No。差別在於:前者的處理建議不只是「更新就好」,還包括回去確認有沒有已經被打過。
  • 修補版就是 7.1.4,10 月 28 日發布,而且到 11 月 6 日為止它仍然是最新版。我們向 WordPress 官方的版本檢查端點讀回來的現行版本是 7.1.4,沒有更新的修補版,所以不必等下一版。

〔官方: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 一次 21 則,其中七則在處理「上一次的修補」

〔官方: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 則,四個官方資料集給的答案不一樣

重數之後我們繼續往下查,結果比「數字對不對」更有用:這 21 則在四個官方管道裡長得不一樣,而你用哪個工具掃,看到的就是哪一個版本。

資料集這批有幾則有 CVE 編號的有沒有嚴重度
symfony.com 的公告文章215(寫在標題裡)沒有
Packagist 安全公告 API215沒有(severity 欄是空的)
GitHub 上 symfony/symfony 的 repo 公告 API219每一則都有
GitHub 的「全域」公告 API0——

逐列說明,因為每一列的意思都不同:

  • CVE 編號 5 則 vs 9 則,差的 4 則是真的存在。GitHub 的 repo 公告資料集對這一批多標了四個編號:CVE-2026-121373(HtmlSanitizer 的 meta refresh)、CVE-2026-121949(HtmlSanitizer 的 srcset)、CVE-2026-123119(NoPrivateNetworkHttpClient)、CVE-2026-123125(Ip 驗證規則)。我們去 NVD 逐一查過,四個都在(11 月 4 日與 5 日登錄)。11 月 6 日我們讀到的狀態都是 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 到我們查的時候都還沒有這四個編號。
  • 嚴重度只有 GitHub 那個資料集有,而且這件事對排程很實際。它標的分布是:high 5 則、medium 10 則、low 6 則、critical 0 則(加總 21)。這一批沒有任何一則被標成 critical——那是「要排,但不是今天放下手邊所有事」的依據,而這個依據在官方部落格與 Packagist 上都讀不到。
  • GitHub 的「全域」公告 API 一則都查不到,連逐一用編號去問都回 Not Found。它與 repo 自己那份公告不是同一個資料集(我們實測時 composer 生態系在全域那一份的資料停在 10 月底)。所以「我用 GitHub 的公告 API 查過了、沒有」這句話,要看你問的是哪一個。
  • 還有一個小陷阱:那 5 則在部落格上用 CVE 當標題的,在 GitHub 上另外還有自己的 GHSA 編號(例如 CVE-2026-118513 是 GHSA-5w3m-mfwg-9f8r),而那組編號 symfony.com 完全沒有顯示。同一個漏洞在兩個地方有兩個名字,對帳時很容易算成兩筆。

這一節想講的不是「哪個資料集才對」——四個都是官方的,而且四個都沒有說謊,它們只是各自記錄了不同的欄位、各自的更新速度不同。要記的是這一句:真正能對帳的是「兩個以上的來源總數一不一樣」,而不是「我有沒有訂閱」。而如果你的掃描工具只接一個來源,它給你的嚴重度與編號就是那一個來源的版本,不是全貌。

21 則散在 13 個元件上

這一批不是同一個元件連續出問題,而是一次大掃除。逐篇讀下來的分布是: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。所以「我們升到最新的修補版了」要對著自己實際用到的元件看,不是看一組通用版號。

六則官方自己標成「Incomplete Fix」,而且各自點名補的是哪一個舊編號

這一批裡最值得非技術決策者讀的不是數量,是下面這六則的性質。它們不是新發現的功能缺陷,而是先前那一次修補沒有把問題收乾淨——而且 Symfony 把這件事寫在標題裡,不是藏在內文:

  • CVE-2026-118513(Security HTTP):X509 驗證器把 DN 值在轉義逗號與裸斜線處切開。標題逐字標為 Incomplete Fix for CVE-2026-45063。
  • CVE-2026-118514(HTTP Foundation):HEAD 請求可以繞過 access_control 與防火牆的 methods 選項。標題逐字標為 Incomplete Fix for CVE-2026-45075。
  • CVE-2026-118517(HTML Sanitizer):主機白名單可被格式不正確的網址 authority 繞過。標題逐字標為 Incomplete Fix for CVE-2026-45066。
  • GHSA-c7hm-wqwp-f9v8(HTTP Client):NoPrivateNetworkHttpClient 沒有把已快取主機的 IP 釘住。標題逐字標為 Incomplete Fix for CVE-2024-50342——補的是 2024 年那一個。它原本的設計是先解析網域、檢查 IP 是不是私有位址,再把那個 IP 交給底層連線;問題是只有第一次解析時才交,之後同一個網域的請求又重新解析一次,於是檢查過的 IP 和實際連上的 IP 可以不同。
  • GHSA-cpww-5vpx-72x7(JSON Path):查詢可以把一個 PHP 行程卡住。標題逐字以 Incomplete Fix for CVE-2026-45756 開頭。官方說明寫得很具體:前一次的修法是把 pcre.backtrack_limit 在每次比對前後調低到 10000,但那個上限是「每一個起始位置」而不是「每一次呼叫」,所以成本會隨著字串長度一再累加。
  • GHSA-wm2w-4mgj-vw33(HTML Sanitizer):meta refresh 的處理只涵蓋瀏覽器實際接受的語法的一部分。標題逐字標為 Incomplete Fix for CVE-2026-48761。

第七則不是「沒補完」,是前一次修補造成的退行(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 驗證那幾條會程式化登入的路徑。

三、Chrome 157:官方說 213 項,但這個數字要會讀

〔官方: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 一週內變差十倍」這種不存在的結論。

另外兩件可以直接拿去用的事:

  • 這一篇公告裡沒有提到任何「已在野外被利用」。我們在整篇內文裡找過 in the wild、exploit exists、actively exploited 三種官方慣用語,一次都沒有出現。所以它急,但不是那種要半夜起來處理的急。
  • Chrome 的更新不是你按了就生效。公告自己寫「This will roll out over the coming days/weeks.」——分批推送。公司裡要確認的是「大家的瀏覽器有沒有真的重開過」,而不是「官方有沒有發」。

還有一個細節,因為它是官方公告的原文、而且與我們這一行的轉變有關,所以照實列出來:這 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 也在同一天修快取洩漏,其中一則是前一次的後續

〔官方: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 參數值的快取洩漏,是先前那一次修補的後續。這一週第三個廠商出現同一個形狀了。

一句實務上的話:這幾則的共同前提是你的系統有「不同使用者看到不同內容」而且開了快取。純靜態的行銷網站受影響的機會低;有登入、有會員、有多租戶的,這一批要排。

五、下週有兩批已經公告的更新,可以先排進行事曆

  • 〔官方:Node.js〕Node.js 已經預告安全釋出,時間是「2026 年 11 月 11 日(週三)當天或稍後」,涵蓋 26.x、24.x、22.x 三條線。官方逐字寫明三條線各自的最高嚴重度都是 HIGH。官方還特別寫了一句值得抄給所有人看的話:「It's important to note that End-of-Life versions are always affected when a security release occurs.」——已經終止支援的版本,每次安全釋出都一定中,因為根本不會有人替它出修補版。公告沒有說會修幾個問題。
  • 〔官方:Oracle〕下一次 Critical Security Patch Update 是 2026 年 11 月 17 日(週二),而且官方寫明預告會在前一個週四發布(也就是 11 月 12 日)。Oracle 現在有兩套排程:季度的 Critical Patch Update(1、4、7、10 月的第三個週二,下一次是 2027 年 1 月 19 日),以及 2、3、5、6、8、9、11、12 月第三個週二的 Critical Security Patch Update。把這兩套搞混就會以為「Oracle 這一季沒事」。

這兩筆都不是「現在要動手」,但它們是可以提前排的——而巡檢真正會被犧牲的原因,從來不是沒時間,是沒排進行事曆。

六、這一週確認「沒有新東西」的來源

這一節的價值和上面幾節一樣:說得出哪些看過了而且沒事,才知道剩下的是什麼。以下每一條都是我們這一週實際讀過的,括號裡是我們讀到的最後一筆。

  • PHP〔官方〕:本週沒有安全更新。11 月 5 日只有 8.6.0 RC5(測試版)。上一次安全公告是 10 月 21 日那一批(8.5.12/8.4.27/8.3.36/8.2.35),已在第一期與第二期寫過。
  • Laravel〔官方〕:11 月 3 日發布 13.40.0,發行說明裡沒有任何安全條目(我們整篇查過 security 字樣,沒有命中)。Packagist 上 laravel/framework 最近一筆安全公告是 10 月 23 日。
  • GitLab〔官方〕:本週沒有新批次。最後一批是 10 月 29 日的 19.5.3/19.4.5/19.3.7/19.2.10/19.1.10/19.0.1。這同時回答了上一期留著的那個問題——上一期寫「無法證實 GitLab 這一週有沒有新批次」,現在可以說:到 11 月 6 日為止沒有。
  • Mozilla〔官方〕:本週沒有新公告。最後一則是 10 月 27 日的 MFSA 2026-123(Firefox 159)。
  • Go〔官方〕:本週沒有新版本。1.27.3 是 10 月 19 日發布的(含 crypto/x509 的安全修補),不在本週窗口內。
  • Oracle〔官方〕:本週沒有新公告,10 月那一批最後的修訂是 Rev 2(10 月 26 日)。
  • Composer(ca-bundle)〔官方〕:本週沒有新版本,最後一筆是 10 月 29 日的 1.6.1。
  • Electron〔官方〕:11 月 3 日與 4 日有釋出(45.2.3/45.2.2/44.10.2/43.8.7),但官方發行說明寫的是崩潰修正與上游(Chromium、ANGLE、FFmpeg 等)的回補,沒有列出任何安全公告。所以它不算本週的安全更新——但如果你的桌面應用是 Electron 包的,Chrome 157 那 213 項會以回補的形式陸續進來。

七、我們查不到、或這一週沒讀到的

這一節是刻意留著的。一份週報如果只寫看到的東西,讀者會以為「這週就這些」——而漏掉什麼,只有寫週報的人知道。

  • GitHub 的變更日誌:11 月 6 日沒讀到,出刊前補讀到了。當天我們這台機器對 github.blog 的網域解析失敗,不是頁面回錯誤——那是我們的環境問題,不是 GitHub 沒發。11 月 8 日解析正常,讀到變更日誌最近 10 則(11 月 4 日至 7 日):沒有一則是需要修補的漏洞公告,都是功能更新(例如 11 月 5 日 secret scanning 的偵測器更新、11 月 4 日 CodeQL 2.27.4)。我們只讀到那 10 則,所以說不出 11 月 2 日與 3 日有沒有東西。
  • 新加坡 CSA 的公告頁,這一週沒讀到。它回 301 轉導,我們沒有跟完。
  • Chrome 那 213 項的官方嚴重度彙總,查無。官方公告逐條標了 Critical/High/Medium/Low,但沒有給任何一行總計。上面第三節那組分布是我們自己逐條數的,寫出來是為了讓你知道它的來源,而不是假裝官方給了。
  • 第 2 層(研究機構與媒體)六家,這一週一家都沒讀——Tenable、Sansec、Socket、StepSecurity、Snyk、Checkmarx。這與上一期是同一個缺口,我們沒有補上。意思是:如果某個漏洞這一週只有資安研究機構在談、廠商還沒發公告,這份週報看不到它。
  • 三筆從另一條線拿到的線索,這一期全部核完了,而其中一筆改寫了上面第二節。(1) 它最初說「Symfony 這批是 22 則」,同日自己更正為 21 則——與我們兩個管道各自數到的 21 則一致,而它更正的那一輪也正好讓我們回去重數、發現自己把 16 篇數錯。(2) 它說這批有 9 則帶 CVE 並點名了四個編號。我們第一輪在 Packagist、symfony.com 與 GitHub 的全域公告 API 三個地方都找不到,照規矩沒有寫進結論;它接著給出確切的出處——GitHub 上 repos/symfony/symfony/security-advisories 這個 repo 專屬的端點——我們自己打了一次,四個編號全部核到,而且順手拿到了只有那個資料集才有的嚴重度。所以第二節那張對照表是這一來一往的結果,不是我們單方面查出來的。(3) 另一則據稱影響 Laravel 13.x 的公告編號,仍然核不起來(GitHub 的全域公告 API 回 Not Found、Packagist 的 laravel/framework 沒有 11 月紀錄),所以沒有寫進結論。這一段留在這裡是因為它示範了一件事:「查不到」要寫成查不到,但也要把出處問清楚再下結論——我們第一輪的「查不到」是對的,第二輪的「核到了」也是對的,中間差的只是一個正確的端點。
  • LiteLLM 的 1.108.0(11 月 4 日)發行說明含 security 字樣,但我們沒有逐條查證。它一週發好幾個版本,要分清哪一條是安全修補需要另外一輪,這一期沒做。
  • KEV 的資料檔只到 11 月 4 日(版本 2026.11.04),所以 11 月 5 日與 6 日有沒有新增,這一期看不到。

還有一個結構性的缺口,每一期都成立:這份清單不是從「我們維護的系統實際用了哪些套件」反推出來的,而是從兩條線的經驗長出來的。要讓它對你家的系統真的有覆蓋,得先有一份你自己的技術清單——那是系統健檢會做的第一件事。

這一週可以拿去問技術負責人的三個問題

  • 我們的 WordPress 現在是哪一版?如果不是 7.1.4 或更新,問的下一句是「什麼時候更新,誰去做」。這一條本週有官方認定的實際攻擊,不是理論風險。
  • 我們的 Symfony 專案,用到的那幾個元件都升到有修補的版本了嗎?(多數元件是 5.4.56/6.4.50/7.4.23/8.1.11,HTML Sanitizer 從 6.4.50 起,JSON Path 只有 7.4.23 與 8.1.11)如果已經升了,再問一句:「那個路徑規則繞過的退化,是不是我們反而中了?」——那一條只影響已經升到 5.4.50/6.4.29/7.3.7 之後的人。
  • 下週三 Node.js 的那批,誰排?官方已經預告了日期與最高嚴重度,所以這一題測的不是技術,是流程:有沒有人在看預告,而不是等到出事才看。

恩梯科技是客製化開發出身的系統軟體公司,現在做的是 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 層(研究/媒體):本期沒有引用任何第二層來源,因為這一週一家都沒讀(見第七節)。

想把這些做法落地到你的公司?

認識 Helper CTO:系統交給誰負責
預約系統健檢 加 LINE 詢問

我們不追求大量專案。

只與少數值得深入合作的夥伴建立長期關係。

需要協助嗎?

用 LINE 直接問我們

加 LINE 詢問