伺服器
該標籤下有 15 篇文章
Linux 核心 CVE-2026-98432：可透過網路觸發的 TCP 釋放後使用漏洞（CVSS 9.8）；請安裝已修復的核心、重新啟動並檢查 MPTCP
CVE-2026-98432 是 Linux 核心 IPv4 TCP 程式碼中的一個釋放後使用漏洞，於2026年10月15日公布。核心專案的 CNA 給出 CVSS v3.1 9.8 分（網路、無需權限、無需使用者互動）。據報導，一家 AI 公司的研究人員在實驗室中、依據其自身報告，示範了針對具有 Multipath TCP（MPTCP）監聽器的伺服器以 root 身分遠端執行程式碼。BleepingComputer 稱，針對一般 TCP 伺服器的遠端程式碼執行尚未公開展示，也未確認有在野利用，本站於11月1日在 CISA 的 KEV 目錄中沒有找到該 CVE。上游修復包含在 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56 與 7.2.10 及之後的版本中。截至11月1日，Debian 已有修復的核心，SUSE 有部分，Ubuntu 與 Red Hat 將修復列為進行中。僅停用 MPTCP 並不是完整的修復。本站的結論是：隨著修復發布，更新面向網際網路的 Linux 伺服器並重新啟動，僅在此之前使用廠商的暫行緩解措施。
緊急 PHP 更新後該檢查什麼：網頁 PHP 與命令列 PHP 的差異、set -e 與 diff 結束代碼，以及入侵再檢查
在 2026 年 10 月回應嚴重 PHP 漏洞期間，本站營運者管理的一個網站已更新網頁 PHP，但 cron 使用的命令列 PHP 仍指向舊版本。請分別檢查網頁與 CLI。在 set -e 之下，diff 與 grep 會以結束狀態 1 表示「發現差異」或「沒有符合」，進而中止腳本；請分別處理 0、1 與 2。修補後，請對每台伺服器執行相同的入侵檢查清單；若日誌出現可疑紀錄，請比對線上檔案與已知正常的部署副本來釐清。
VMware ESX CVE-2026-41709（CVSS 2.7）：CISA 將這項低風險日誌漏洞列為已遭利用；請修補整份 VMSA-2026-0006 並檢查主機
CVE-2026-41709 是 VMware ESX 中的日誌記錄不足漏洞（CVSS 2.7，低風險）：已經擁有管理員權限的攻擊者可以執行某些操作而不被記錄到日誌中。Broadcom 已於2026年7月29日在公告 VMSA-2026-0006 中修復，沒有因應方案。2026年10月28日（美國時間），CISA 將其加入已知遭利用漏洞（KEV）目錄，美國聯邦機構的期限為11月11日。一家資安公司的威脅報告稱，一個與中國有關聯的組織在對美國多個組織的入侵中將其作為零時差漏洞使用，最晚到2026年初，SecurityWeek 將其目的描述為降低稽核軌跡的可見性；本站尚未獨立查證該報告。該漏洞本身不提供入口，但意味著受影響主機的日誌可能無法顯示入侵者做了什麼。同一公告還包含兩個評級為 9.8 的 vCenter 漏洞，其中之一（CVE-2026-59310）已於8月18日被 CISA 列為已遭利用，因此只修補 ESX 漏洞會讓入口依然敞開。本站的結論是：把 ESX 與 vCenter 更新到整份公告對應的修復版本，把主機日誌傳送到另一台伺服器，並尋找入侵跡象，而不是只相信日誌。
Linux 核心 Fragnesia（CVE-2026-46300）：CISA 列為已遭利用，期限為10月31日；請修補 PHP 與核心，然後重新開機
CVE-2026-46300，暱稱 Fragnesia，是 Linux 核心中的一個漏洞，可讓低權限的本機用戶取得 root 權限（CVSS v3.1 7.8，本機攻擊向量）。核心在網路緩衝區之間搬移資料片段時，可能遺失一個標記，該標記表示這些資料與記憶體中的某個檔案共用，隨後 IPsec ESP 程式碼可能在該唯讀檔案的快取副本上直接解密並覆寫。核心專案於2026年5月23日發布了該 CVE，修復包含在核心 5.10.257、5.15.208、6.1.174、6.6.141、6.12.91、6.18.33 與 7.0.10 及之後的版本中。2026年10月28日（美國時間），CISA 基於存在活躍利用的證據，將其加入已知遭利用漏洞（KEV）目錄，美國聯邦機構的期限為10月31日。CISA 的描述表示，它可與 PHP 漏洞 CVE-2026-109618 和 CVE-2026-109619 串聯，植入 PHP webshell 並以 root 身分執行指令。一家資安公司報告指出，這條攻擊鏈被用於攻擊 25 台伺服器（大多是防火牆），SecurityWeek 轉述了該報告；本站未獨立查證這些數字。Ubuntu、Red Hat 與 Debian 已發布修復核心，而核心更新必須在重新開機後才會生效。本站的結論是：若您在 Linux 上執行 PHP 網站，請更新 PHP 與核心，重新開機，並檢查是否有 webshell。
Nextcloud 內建 Collabora CODE 伺服器 CVE-2026-110447 遭利用：影響範圍與處置方式
2026 年 10 月 14 日，Collabora Online 開發者揭露 CVE-2026-110447，這是 Nextcloud 應用程式 Collabora Online - Built-in CODE Server（應用程式 ID richdocumentscode）中無需驗證的作業系統指令注入漏洞。透過該應用程式的 proxy.php，指令可以以網頁伺服器使用者的身分執行。條件是內建 CODE 伺服器未在執行，這可能發生在容器重新啟動、升級或當機之後。26.4.303 之前的版本受影響；26.4.303 於 9 月 11 日發布。開發者表示停用此應用程式無法防止問題，並要求使用者更新或移除。在已停止維護的 Nextcloud 29 及更早版本上，請更新 Nextcloud 或移除此應用程式。開發者表示，獨立的 Collabora Online 伺服器、Docker 映像檔、RPM/DEB 套件以及 Nextcloud All-in-One 不受影響。CVSS v4.0 分數為 9.2。CISA 於 10 月 23 日將此漏洞加入「已知遭利用漏洞」（KEV）目錄，截止日期為 10 月 26 日。使用者在開發者的儲存庫中回報，約自 9 月 10 日起出現攻擊，據媒體報導，已有網頁後門（web shell）被植入。本站的結論：若已安裝內建 CODE 應用程式，即使已停用，也請今天就檢查其版本，更新或移除，然後檢查自 9 月 10 日起是否有入侵痕跡。
GitLab CVE-2026-110264（CVSS 10.0）與已遭利用的 CVE-2026-97229：如何檢查並更新自架 GitLab
2026 年 10 月 21 日，GitLab 針對社群版（CE）與企業版（EE）發布重大修補版本 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 與 18.11.13。最嚴重的漏洞 CVE-2026-110264（CVSS 10.0）是在編譯特製正規表示式時發生的整數溢位，在特定條件下，未經驗證的使用者可能藉此在 GitLab 伺服器上執行任意程式碼。自 7.0 起幾乎所有版本都受影響。10 月 29 日，CISA 將與之相近的漏洞 CVE-2026-97229（CVSS 10.0，CWE-190）列入已知遭利用漏洞（KEV）目錄，處置期限為 11 月 1 日。它是同一類漏洞（CI/CD 正規表示式編譯器中的整數溢位，未經驗證的使用者即可觸及），GitLab 已於 10 月 12 日在 19.4.2、19.3.5 與 19.2.8 中修復，僅影響 19.2.0 至 19.2.7、19.3.0 至 19.3.4 與 19.4.0 至 19.4.1。仍低於 19.4.2、19.3.5 或 19.2.8 的執行個體，暴露在一個已遭利用的漏洞之下。升級到本文建議的版本（19.5.1、19.4.3、19.3.6、19.2.9）同樣可以修復 CVE-2026-97229。GitLab.com 已完成修補，自架執行個體需要升級。10 月 21 日的同一次發布還修復了兩個高風險漏洞（CVSS 8.2 與 7.5）以及其他漏洞，但這些修補僅在 19.3.6、19.4.3 與 19.5.1 版本線中提供。問題的根源在於 Ruby 的正規表示式引擎（Onigmo），Ruby 於 10 月 23 日發布了 4.0.9、3.4.12 與 3.3.13。從攻擊者可控字串編譯正規表示式的應用程式會受影響，而 Regexp.timeout 無法防護這些錯誤。GitLab 的公告未說明 CVE-2026-110264 已遭利用，截至 10 月 30 日它也不在 KEV 中。Alpine Linux 報告稱，其自己的 GitLab 在 10 月 20 日和 21 日遭到透過 CVE-2026-97229 的攻擊嘗試，並且只升級 GitLab（到 19.3.6）沒有堵住該漏洞，因為修復還需要打過修補的 Ruby；它重建了該執行個體，並未發現攻擊者程式碼被執行的證據。本站的結論：核對必須經過的升級停靠點後，今天就升級自架 GitLab，最終升級到 19.3.6 或更高版本；如果您自行建置 GitLab 或執行自己的 Ruby，也請確認 Ruby 為 3.3.13、3.4.12 或 4.0.9 或更高版本。Ruby 應用程式應升級到已修正的 Ruby，並停止從使用者輸入建構正規表示式。
SiteGuard Server Edition 的 CVE-2026-106931 已遭利用：誰受影響、該怎麼做
2026 年 10 月 14 日，EG Secure Solutions 公布 CVE-2026-106931，這是其主機型網頁應用程式防火牆（WAF）SiteGuard Server Edition 統計功能中的作業系統命令注入漏洞，並表示已確認有人利用。攻擊成功時，可能以 root 或 SYSTEM 權限在執行該產品的伺服器上執行任意作業系統命令。受影響的是 Ver2.20 以後且啟用統計功能的版本（預設為啟用）：Ver8.00 Update5 之前的 Apache、Nginx 與 IIS 版，以及 Ver7.00 Update6 之前的 FreeBSD Apache 與 Nginx 版。IIS 版 Ver3.10 至 Ver4.00 Update4 不受影響。修正版本為 Ver8.00 Update5 與 Ver7.00 Update6；無法升級的系統可使用修補程式，已終止支援的版本也包含在內。廠商將此漏洞評為本機攻擊途徑、需低權限（CVSS v3.0 7.8、v4.0 8.5）。JPCERT/CC 發布警示，表示已確認該產品在日本被廣泛使用，且停用統計功能可避開此問題。CISA 於 10 月 20 日將此漏洞列入已知遭利用漏洞（KEV）目錄，期限為 10 月 23 日。本站的結論：若您使用 Server Edition，請今天就確認版本與統計功能，更新前先保存診斷資料，再套用修正版本或修補程式。
【快訊】PHP 漏洞 CVE-2026-109618 與 CVE-2026-109619 已遭利用，列入 CISA KEV 目錄：請立即更新至 8.5.12、8.4.27、8.3.36 或 8.2.35
2026 年 10 月 21 日，PHP 安全團隊發布 PHP 8.5.12、8.4.27、8.3.36 與 8.2.35，修補兩個可能允許未經驗證遠端程式碼執行（RCE）的嚴重漏洞，並敦促所有使用者立即更新。CVE-2026-109618 涉及記憶體不足（out-of-memory）處理，CVE-2026-109619 涉及請求之間殘留的過期內部狀態；依 CVSS v4.0 兩者皆為 9.2 分。所有處理網頁請求的 PHP 安裝都有風險（PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed）。該團隊認為 mod_php 風險最高，並引用一個已示範的攻擊程式：未經驗證的請求會在任何應用程式碼執行前就觸發攻擊。PHP 8.1 及更舊版本不會獲得官方更新；該團隊為 7.4、8.0 與 8.1 提供了最小化的原始碼回補修補程式。Linux 發行版已提前取得修補程式。目前沒有完整的緩解方式，更新是唯一安全的選擇。10 月 22 日，日本 IPA 與 JPCERT/CC 發布警示，JVN 發布 JVNVU#99905564。CISA 在首次發布警示時尚未觀察到遭利用，但已於 10 月 26 日將這兩個漏洞列入其已知遭利用漏洞（KEV）目錄，並為美國聯邦民事機構設定 10 月 29 日的期限。據媒體報導，一名資安研究人員以 mod_php 執行未修補 PHP 8.4.26 的蜜罐系統，於 10 月 24 日遭成功遠端程式碼執行。一家大型雲端供應商的蜜罐系統在揭露前四天（10 月 17 日）就已看到遭利用的嘗試。就本站所能查到的範圍，截至 10 月 27 日，尚無蜜罐系統以外的入侵事件被公開。多數日本主要共享主機業者已宣布修補已套用，但部分業者（例如 KAGOYA）尚未宣布。10 月 23 日，PHP 團隊揭露第三個問題（CVE-2026-115560），該問題未被 10 月 21 日的版本修補。它只有在特定的設定與應用程式碼組合下才可能導致程式碼執行；該團隊認為實際上不太可能發生，將於下一個例行版本中提供修補與完整公告，並建議在此之前設定 session.upload_progress.enabled=0。受影響版本與 CVSS 分數尚未公布，也沒有任何遭利用的通報。截至 10 月 29 日（在 php.net 上查看），此問題的修補版本尚未發布。10 月 28 日，CISA 還將 Linux 核心漏洞 CVE-2026-46300 列入 KEV（美國聯邦機構的期限為 10 月 31 日），並表示它可以與這兩個漏洞串聯，用於植入 PHP webshell 並以 root 身分執行指令。本站的看法：遭利用現已獲得確認，請確認你或你的主機業者是否為各網站更新 PHP，並今天就升級至修補版本。同時請檢查 10 月 17 日起的日誌，尋找入侵跡象。若使用共享主機，請在業者官方網站查看其完成公告。
網站安全會影響 SEO 嗎？依據 Google 官方文件，整理漏洞、網站遭駭、HTTPS 與搜尋排名的關係
Google 沒有把漏洞列為排名因素。真正的損害發生在漏洞被利用之後。遭駭後出現的垃圾網頁會讓搜尋結果顯示「This site may be hacked」（這個網站可能遭到入侵）標示；惡意軟體或網路釣魚會觸發 Chrome 的「Dangerous site」（危險網站）警告（其他瀏覽器也會顯示各自的 Safe Browsing 警告）；違反垃圾內容政策的網站，排名可能下降，甚至完全不出現在結果中。HTTPS 在 2014 年被宣布為「非常輕微」的信號，而 Google 現行的網頁體驗文件說明，除了 Core Web Vitals 之外，其他網頁體驗面向並不會直接幫助網站提高排名。本站的看法：從 SEO 的角度，與其花時間提高安全評分，不如把心力放在不被入侵，以及被入侵時盡快發現。
如何確認網站或伺服器是否被入侵：共用虛擬主機、WordPress 與 VPS 的逐步檢查，以及發現異常時首先要做的事
檢查網站是否遭入侵，要同時查看從外部看得到的徵兆和留在內部的痕跡。徵兆：Search Console 的安全性問題報告、搜尋結果中的「This site may be hacked」（這個網站可能遭到入侵）標示、主機業者的通知、不明的管理員、只在手機或從搜尋進入時才發生的重新導向。痕跡：管理員使用者、被修改的核心檔案（wp core verify-checksums）、登入紀錄、authorized_keys、cron、監聽中的連接埠、最近變更的檔案。本站的看法：什麼都沒找到，並不能證明沒事。如果真的發現異常，請在清理前保存證據，從乾淨的裝置更換所有憑證，從入侵前的備份還原或重建，封住入侵途徑，最後才申請審查。
是否把機密檔案遺忘在公開目錄裡：webroot 盤點
放在 webroot 裡的東西，任何人都能透過 URL 取走。遺留的權杖／憑證 JSON、.env 或備份就等於立即外洩；如果它來自共用範本，每個站點都有同一個檔案。對策：公開目錄只放可以公開的東西，機密放在 webroot 之外並設權限 600，一旦發現一個，就盤點所有站點與主機。
安全資產盤點：個人維運多台伺服器時最易忽略的 7 項檢查
個人維運多台伺服器的事故，往往源於「沒掌握的狀態」而非「缺少防護」。要守的邊界是放置金鑰的電腦。2FA 依哪個帳號能復原其他帳號來排定優先順序（郵件最先），列出哪把 SSH 金鑰能打開哪台伺服器，並刪除重複、未使用的金鑰與殘留的註冊，明文密碼從雲端清除，整改要可逆且逐項進行，台帳裡不寫機密。比起花俏的新工具，盤點更優先。
自建 Git 伺服器和 GitHub，從安全角度看哪個更安全
自建 Git 不是『變安全』，而是『轉移風險』。誤公開這一類事故確實會消失，但伺服器修補、備份、提交前金鑰偵測的責任會轉移到你身上。能持續做這些工作就是好選擇，放任不管則比 GitHub 更危險。本站視角＝自建維運必須連同補償性的控制一起，否則無法成立。
SSH 金鑰的最小權限：別把正式環境的 root 金鑰放進可能被入侵的臨時環境
從可能被入侵的臨時環境（GPU pod、CI runner、一次性 VM）向正式環境登記 root 金鑰，該環境一旦被入侵，攻擊者就會取得正式環境的 root。對策：臨時環境不放 root 金鑰；不用就刪除；再次需要時，用非 root 使用者加上限制為單一操作的 command 限制金鑰。把重複使用的金鑰當作最重要的資產，絕不要建立一把金鑰外洩就能打開所有伺服器的架構。
在虛擬主機上避免 .env 被公開的目錄配置與設定
主要對策是把應用程式主體放在 docroot 之外，只公開 public/。先用 .htaccess 封鎖存取，再用結構改造做長期修復，最後自我檢查。本站的看法：這不是個人的疏忽，而是一種危險的配置在業界成了標準，所以要靠流程而不是靠注意力來防。bootstrap-redirect 比 symlink 更穩。