Ray Liu's Blog

前言昨天才整理完 GitLab、PHP、Node.js、Java、Go 與 Railway，接著又看到「Linux 核心多項漏洞公開、最高 CVSS 9.0」的消息。對管理 NAS、Linux 伺服器或 Kubernetes 的人來說，接下來要確認的是：自己的主機有沒有啟用相關元件，修補又走到哪個階段？ 這篇承接前一篇十月資安事件總整理，追蹤這批 Linux 通報，並補上 ConnMan DNS proxy 與 LiteLLM 1.107.0 供應鏈入侵。三者分別涉及核心、使用者空間服務與套件發行流程，維護時需要找到各自的負責層級。 查核截點：2026-10-23 08:25，台灣時間 UTC+8。 本文依公開通報、維護者回覆與官方事件說明整理；受影響版本、發行版回移修補與調查結論仍可能更新。文中的指令為唯讀盤點範例，未在讀者環境執行。封面是 AI 生成的概念插畫：紫色紙板櫃的開口與紅色紙帶連向共用底座，呈現不同入口對共用設施的影響。 一、Linux 這次發生什麼事？10/21，Trend Micro Zero Day Initiative（ZDI）送出了多份 ...

前言這幾天打開技術社群，看到的是一整串維護工作：PHP、GitLab 與 Node.js 發布安全修補，Java 和 Go 更新憑證信任，Railway 通知使用者輪替機密資料，Fortinet 又要求準備緊急升級。對維護多個服務的人來說，最需要的是一份能對照自己系統、分派責任並追蹤完成狀態的清單。 這篇集中整理 2026/10/14～10/22 與後端、DevOps、雲端部署相關，且已查到官方公告的重要事件。前面的 PHP、Node.js、Go 已有深入文章，這裡會把它們放回同一個系統裡，接著補上 GitLab、Java、NGINX、Railway、Fortinet、Oracle，以及 Python、Rust、Docker 等憑證更新。10/23 再增補 Python 生態的 LiteLLM 套件供應鏈事件，將受污染產物、環境重建與機密輪替一起納入盤點。 查核日期：2026-10-22，台灣時間 UTC+8。 一般發布日期沿用原公告記載；動態狀態另標 UTC 與台灣時間。本文為有範圍的事件彙整，各產品完整 CVE 與適用版本仍以連結...

前言2026 年 10 月的這波安全更新，Go 的重點落在 TLS 憑證信任。CVE-2026-111943 對應標準函式庫 crypto/x509 的緊急修補：驗證憑證鏈時，拒絕信任與本次事件相關的中繼 CA 金鑰。官方要求立即升級至 Go 1.26.10 或 1.27.3，漏洞資料庫編號為 GO-2026-6809。Go 發布公告、Go 漏洞資料庫 如果你維護的是 Go API、Webhook、SSO 整合、反向代理或 CLI，這次需要一路追到實際執行的二進位檔。一般 Go 應用會將用到的標準函式庫程式碼編進產物；更新建置機上的 Go 之後，還要重新編譯、發布並替換正式環境中的舊程序，才能套用這段驗證邏輯。 查核日期：2026-10-22，台灣時間 UTC+8。 本文依 Go 官方公告、CVE／Go 漏洞資料庫、公開修補程式碼及業者公告整理。文中的盤點情境與指令供讀者套用，未針對實際服務執行漏洞利用或連線測試。封面為 AI 生成的概念插畫，以鈷藍信任鏈及被移除的琥珀色共同金鑰連結呈現修補意象。 一、先釐清日期與版本：10/21 建檔，修正版已先發布安全新聞裡...

前言2026 年 10 月 21 日，除了 PHP 的緊急安全更新，Node.js 也釋出新版本，處理 10 項漏洞：4 項 High、3 項 Medium、3 項 Low。最高等級為 High，其中 CVE-2026-111497 涉及 Brotli 解碼器的越界寫入，官方列出的影響包含遠端程式碼執行（Remote Code Execution，RCE）。Node.js 官方安全公告 對維運與後端團隊來說，應先確認實際執行的版本，再看程式用到哪些功能。接收外部壓縮資料、呼叫外部 HTTP／HTTPS 服務、使用自訂啟動快照，以及依賴 Permission Model 限制檔案操作，是這篇要逐一說明的盤點方向。 查核日期：2026-10-22，台灣時間 UTC+8。 本文解讀 10 月 21 日的官方公告、發布紀錄與公開修補程式碼；程式碼檢閱與利用重現是不同層次的證據，本文未執行漏洞 PoC。封面為 AI 生成的概念插畫，以折疊材料越過檢查框呈現邊界檢查的意象。 一、先確認更新版本：22.23.4、24.22.1、26.12.1本次三條受支援分支都已有安全版本。若仍使用本...

前言2026 年 10 月 21 日晚間，pixiv、Niconico、BASE 與多款日本遊戲陸續出現緊急維護公告。這波異動的重要背景，是 PHP 發布兩個重大漏洞的安全更新：CVE-2026-109618 與 CVE-2026-109619，研究團隊將相關問題稱為 PHP2Shell。PHP 官方確認，它們可能讓未登入的攻擊者在受影響伺服器上執行程式碼。本文會整理漏洞原理、更新範圍與各站公告。PHP 官方公告、Wiz 研究報告 先補上最容易過時的一項消息：pixiv 已公告於日本時間 10 月 21 日 23:30，也就是台灣時間 22:30，結束緊急維護。 原先預告的「維護到隔天凌晨」已經有更新；停站與恢復時間都應以官方後續公告為準。pixiv 維護完成公告 資料截點：2026-10-21 22:53，台灣時間 UTC+8。 相當於日本時間 2026-10-21 23:53（UTC+9）。本文網站維護表統一使用日本時間，預定結束時間不代表實際恢復時間。封面為 AI 生成的概念插畫，描繪服務暫停後修補共用元件，並非事件現場或遭駭證據。 一、今晚發生什麼事？先掌握嚴重程...

前言DeepSeek 在 2026 年 10 月 17 日推出 DeepSeek-V4.1-Flash-1017，是 9 月 V4.1 Flash 的更新版。這次發布的主題是「Wish-Driven Programming（願望驅動編程）」：官方說法是把一個完整專案交給模型，由它自己規劃、產生、檢查再修正到可交付的成果。官方釋出的示範涵蓋 3D 建模、網頁遊戲與 Godot 引擎重製，訴求是「講出願望，模型完成開發」。官方發布說明 同一天 DeepSeek 也開放自研的 Search 與 Fetch API，讓 Agent 能自行搜尋網頁並讀取正文。這篇整理截至 2026 年 10 月 17 日 的官方資訊，包含這次改了什麼、基準數據怎麼看、API 與收費的變化，以及導入時要留意的地方。 官方把這次更新形容為效能與成本之間的 Pareto 改良（Pareto improvement）：基準表現更好，同時縮短任務執行時間、減少輸出長度。但這些數字主要來自 DeepSeek 自己的測試，實際效益仍取決於你用的 Agent 框架、任務類型與執行設定，不能直接當成團隊的成效保證。 ...

前言在 Laravel 專案裡，如果一百個後台列表都有相似的篩選、排序與分頁，我們可能會建立一個共用 Repository，讓大家從同一個入口取資料。轉到 C# 後，卻常看到另一種建議：直接使用 EF Core，把查詢條件抽成 IQueryable<T> 擴充方法。兩邊都在解決重複程式碼，差異到底在哪裡？ 類似的疑問也會出現在 Middleware、Service Provider、Model、Event 與 Validation。熟悉 Laravel 的經驗很有用，但遷移時需要重新確認三件事：這個元件負責什麼、活多久，以及在哪個時機真正執行工作。 這篇以 ASP.NET Core 與 EF Core 為核心，整理這些概念的對應與實務取捨。 本文依 2026-10-16 查閱的 Laravel 13.x、ASP.NET Core 10 與 EF Core 官方文件整理。C# 程式碼是聚焦概念的片段，省略完整型別、DI 註冊與錯誤回應整合，未建立或執行完整範例專案；版本特有行為會另外註明。 一、先用職責對照，避免只翻譯名稱有些概念十分接近，有些則需要拆成幾個元件...

前言假設今天要用 C# 寫一套訂單後端，包含建立訂單、查詢、付款狀態更新與取消訂單。採用三層架構，可以從 Controller → Service → Repository 開始；採用 DDD，可能會出現 Application、Domain、Infrastructure；採用垂直切片，又會變成 Features/Orders/Cancel。光看目錄，很難判斷這些選擇在實際開發上差在哪裡。 這篇固定使用同一套 ASP.NET Core API、EF Core 與 PostgreSQL，以「取消訂單」比較三種寫法，再把需求改成「多個入口共用規則」「與付款同時發生」「取消後要發送通知」，觀察程式碼與責任如何變動。比較集中在專案內部的設計、開發與維護成本。 本文的「垂直架構」指 Vertical Slice Architecture，垂直切片架構。程式碼為說明責任配置的核心片段，省略 DI、完整型別、EF 對應與例外轉譯，沒有建立或執行三套可重現的 C# 範例專案；文中的選型是依情境提出的工程判斷。 一、先釐清：這三個名稱關注的事情不同三層、DDD 與垂直切片可以放在一起討論，...

前言「把一部分查詢搬去 MongoDB，真的會比較快嗎？」「Cassandra、ScyllaDB 為什麼能存那麼多聊天訊息？」「NoSQL 是不是為了效能，接受寫入成功後資料還會消失？」這幾個問題其實連在一起：資料庫用什麼方式組織資料，以及它回覆成功時，到底承諾了什麼。 這篇從實際選型出發，先整理各類資料庫擅長的工作，再深入 MongoDB、Cassandra、ScyllaDB 與 Discord 的遷移案例，最後回到資料遺失、讀寫一致性和 CQRS（命令與查詢職責分離）讀模型。重點是找出哪個工作負載值得換工具，以及換了之後要承擔哪些責任。 先分清楚：資料模型、交易保證與擴展方式NoSQL 是一個範圍很廣的分類，包含文件、鍵值、寬列、圖等不同模型。**ACID 描述交易的原子性、一致性、隔離性與持久性，和是否使用 SQL 是不同維度。**例如 MongoDB 支援單文件原子操作，也支援跨文件與分片叢集的交易，不能直接把它歸類成「沒有交易保證」。MongoDB 原子性與交易 同樣地，「有多台機器」也可能代表不同事情：有些副本是保存相同資料、分擔讀取；有些分片則各自保存不同資料、...

前言假設要做同一套會員與訂單 API：有路由、驗證、ORM、資料庫連線、Redis 快取與 JSON 回應，分別用 Go、C#、Java、Node.js、PHP 實作。在功能一樣、部署成容器的前提下，哪一種比較省記憶體？哪一種容易在高流量下卡住？正式環境又要多照顧哪些地方？ 我的選型起點是：**重視精簡常駐服務，先評估 Go；重視複雜業務與持續吞吐，評估 C#、Java；以 TypeScript 整合服務，評估 Node.js；快速交付商業 CRUD，評估 Laravel，並把 FPM 與 Octane 分開看。**接下來把這些判斷放進同一個專案比較，說明背後的 CPU、記憶體與執行模型差異。 比較基準：同樣功能、相同資源與相同達標條件本文比較的是 Linux 容器中的後端 API。JavaScript／TypeScript 都以 Node.js 執行後端來看；C# 使用現代 ASP.NET Core。PHP 則分成傳統 PHP-FPM 與 Laravel Octane，因為兩者的請求生命週期不同。 先定義一套共同的微服務規格，避免拿精簡 JSON endpoint 和完整訂...