NetSafe.TW

recent posts

about

分類: 網路安全

  • 永豐銀行 419 名客戶帳戶遭「臉部掃描確認」轉出 4 千多萬：銀行稱新網銀系統程式異常、已全數返還，金管會要求 11/12 前交報告

    筆者認為這是最近最嚴重的金融體系事件，金融當局必須採取最嚴緊態度查清事實及對所有機構進行審查

    新聞摘要

    永豐銀行 11 月 3 日上午爆發大批客戶帳戶被不明轉出存款。多名用戶在 Threads 發文指出，自己沒有開啟 App、也沒有設定約定帳戶，帳戶卻以「臉部掃描確認」的方式被轉出新台幣 10 萬元，而且都轉到台北富邦銀行的同一個帳戶。

    金管會銀行局副局長王允中當天證實，依永豐銀行初步比對，異常交易共 427 筆、每筆約 10 萬元、合計 4,000 多萬元，影響 419 名客戶。永豐銀行聲明表示，原因是內部「新網銀交易系統」程式異常，已掌握原因並暫停服務，款項連同手續費已全數返還客戶；收款帳戶也已凍結。

    重點：依目前銀行與金管會的說法，這是銀行端系統異常，不是客戶被釣魚或被騙；但「程式異常」的具體原因，永豐銀行尚未公開說明。

    事件時間線（2026/11/3，台灣時間）

    • 上午 9 點多：多名客戶收到 App 或 LINE 的交易通知，發現帳戶被轉出 10 萬元至富邦銀行同一帳戶（受害者自述，自由時報、信傳媒報導）。
    • 上午：受害者在 Threads 發文，指稱「沒開 App、沒有約定帳戶」卻以臉部掃描確認轉出，留言區陸續有人回報相同狀況。
    • 截至中午：刑事局表示 165 反詐騙諮詢專線已接獲 68 件相關報案／進線，受害者戶籍多為雲林縣（身分證字號 P 開頭），已通報富邦銀行圈存收款帳戶。
    • 近中午 12 時：永豐銀行以電話通報金管會。
    • 下午約 3 點：永豐銀行表示已先行墊付款項給受影響客戶（自由財經報導，有受害者證實 10 萬元已回到帳戶）。
    • 下午：永豐銀行發布聲明，指「新網銀交易系統」程式異常，已暫停服務、全數返還款項；新版行動銀行 App 下架。
    • 下午：金管會記者會證實 419 人、427 筆、4,000 多萬元，並要求永豐銀行當天通報重大偶發事件。
    • 11 月 12 日前：永豐銀行須向金管會提交重大偶發事件報告。

    發生了什麼：系統異常，還是被駭？

    • 銀行的說法：永豐銀行稱「新網銀交易系統」程式異常，造成部分帳戶不明轉出，已掌握原因並暫停服務，之後未再發生相同情況。但銀行沒有說明是什麼樣的程式異常（iThome 向銀行詢問也未獲進一步說明）。
    • 金管會的說法：客戶反映新版行動銀行 App 並未登入帳戶，卻出現資金匯出交易；永豐仍在釐清資訊系統異常原因。
    • 「臉部掃描確認」從何而來：這是受害者看到的交易紀錄描述（多家媒體引述受害者貼文），目前沒有官方確認臉部辨識機制本身被破解，也沒有證據顯示是深偽（deepfake）或釣魚取得臉部資料。有受害者推測與自己設定了臉部辨識登入有關，屬個人猜測。
    • 為什麼都是雲林人、都轉到同一帳戶：刑事局證實報案者戶籍多為雲林縣，款項都進同一個富邦帳戶；網友懷疑與名單外洩有關，但目前沒有任何官方證實（未核實）。這種「固定金額、固定收款帳戶、特定族群」的模式，比較不像單純隨機的程式錯誤，真正原因要等永豐的調查報告。
    • 是否超過轉帳限額：有受害者表示收款帳戶不是約定帳戶、10 萬元明顯超過非約定轉帳限額，這是受害者自述，銀行未回應（未核實）。
    • 錢有沒有被領走：民視報導指收款帳戶已列為禁止提款帳戶、入帳款項未被轉出；永豐銀行也對自由財經表示款項都還在富邦銀行帳戶。

    銀行、金管會與警方的處理

    • 永豐銀行：暫停相關服務、下架新版行動銀行 App，引導客戶改用舊版 App 或 ATM；以代墊款方式全數返還本金與手續費，並主動通知受影響客戶。
    • 金管會：要求永豐妥善處理客戶權益並釐清原因；永豐須在 11 月 12 日前交重大偶發報告。是否開罰，金管會表示要看事件輕重與原因再決定。
    • 其他銀行：市場傳出另有銀行出現類似狀況，金管會表示資安重大偶發事件須在半小時內通報，截至 11/3 下午只收到永豐一家通報。
    • 警方：刑事局已請永豐銀行稽核查明並提供資料，釐清有無犯罪情事，並協助民眾到轄區警察機關報案。

    給企業／IT 管理者（銀行、電子支付、金融科技）

    • 新版網銀、App 上線後，對「未登入卻有交易」「同一收款帳戶短時間大量入帳」「固定金額批次出現」設即時告警與自動阻斷。
    • 轉帳授權要在伺服器端重新驗證：生物辨識結果、裝置綁定、約定／非約定帳戶限額都不能只信任前端或 App 回傳的旗標。
    • 臉部辨識要搭配活體偵測（liveness）與裝置綁定，並記錄每次驗證的裝置、時間與結果，方便事後鑑識。
    • 新舊系統切換期間保留可快速回退（rollback）的機制，並針對授權、限額、交易簽章等關鍵邏輯做獨立的安全測試與程式碼審查。
    • 準備好事件應變劇本：半小時內通報主管機關、凍結收款帳戶、代墊返還、對外說明的時程與分工。

    給一般用戶

    • 打開銀行 App 和 LINE 的交易通知，有不明轉出馬上打銀行客服、撥 165。
    • 這兩天常看一下永豐帳戶明細；被轉出的人確認款項是否已退回。
    • 依銀行指示改用舊版 App 或 ATM，不要從網路連結或來路不明的地方下載「新版」App。
    • 小心藉這次事件冒名的「退款」「帳戶驗證」電話或簡訊，銀行不會要你提供密碼、OTP 或臉部影像。
    • 可以檢查並調低非約定帳戶轉帳限額，不常用的約定帳戶也可以刪除。

    資料來源

  • 幣安遭竊 63 億美元、FBI 鎖定北韓 TraderTraitor：入侵起點是一台 DevOps 工程師筆電，高權限維運人員的電腦要先鎖好

    全球最大加密貨幣交易所幣安（Binance）10 月 29 日左右遭竊約 63 億美元加密資產，美國 FBI 已正式認定是北韓駭客組織 TraderTraitor 所為，被多家媒體稱為史上最大加密貨幣竊案。幣安初步調查指出，入侵起點是一名 DevOps 工程師的筆電。對台灣讀者來說，這起事件的重點不只是幣圈新聞：一台工程師電腦就能一路通到提款系統，任何有高權限維運人員的企業都該對照檢查。

    事件經過

    • 10 月 29 日左右：攻擊者從 10 條區塊鏈上的錢包轉走約 63.6 億美元加密資產，大部分在約 20 分鐘內轉出（BleepingComputer、iThome）。
    • 幣安初步調查：一名 DevOps 工程師的筆電遭入侵，攻擊者藉此存取與提款相關的服務容器，送出未授權的提款指令；幣安表示調查中未發現錢包私鑰外洩證據。
    • 之後幣安執行長 Richard Teng 表示，調查又發現「其他入侵點」，攻擊者還使用自毀機制，邊攻擊邊銷毀工具與痕跡，增加調查難度（The Record）。
    • 10 月 31 日至 11 月 1 日：FBI 發布警示，認定北韓 TraderTraitor 所為，並公布 628 個相關加密貨幣地址（608 個以太坊、19 個比特幣、1 個 Solana），呼籲交易所與 DeFi 業者封鎖相關交易。
    • 11 月 1 日：幣安分階段恢復提款，表示已用公司資金補足約 95% 遭竊資產，剩下 5% 是流動性較差的代幣；並強調損失不會轉嫁給用戶。中央社引述路透報導，恢復上線後客戶提領約 36.4 億美元。

    重點

    項目內容
    遭竊金額約 63 億美元（約 63.6 億美元）
    發生時間2026 年 10 月 29 日左右
    歸因FBI 認定北韓 TraderTraitor（與 Lazarus 相關）
    初始入侵DevOps 工程師筆電遭入侵 → 存取提款服務容器（幣安初步說法）
    凍結資金區塊鏈資安業者稱約 30 億美元已遭凍結
    補足比例幣安稱已補足約 95%
    FBI 公布地址628 個
    • 手法關鍵不是「破解錢包」，而是「拿到內部人員的權限」：TraderTraitor 過去多次透過假徵才、假面試、惡意程式碼專案鎖定工程師電腦，Bybit、DMM Bitcoin 案都是從員工或開發者電腦突破（BleepingComputer）。
    • 洗錢高度自動化：區塊鏈分析公司 Elliptic 指出，攻擊者使用約 1.2 萬個錢包、橫跨 11 條區塊鏈、進行約 4 萬筆交易，平均每 25 秒換一個錢包（The Record，單一來源，數字未核實）。
    • 有資安業者引述 Blockaid 指出，攻擊在單一交易中包含 50 個 EIP-7702 授權並委派給惡意「掃幣」合約（CSO Online 引述，未核實）。

    對你的實務建議

    企業 / IT 管理者

    1. 把「維運人員筆電」當成最高風險資產：DevOps、SRE、雲端管理員的電腦應強制 EDR、磁碟加密、禁止安裝來路不明的套件或「面試測驗程式」。
    2. 高風險操作不能只靠一台電腦就完成：提款、匯款、正式環境部署、金鑰存取，應設計多人覆核（雙人簽核、分權），讓單一帳號或單一裝置被攻陷時也無法單獨完成。
    3. 管理介面與正式環境的存取，改走特權存取管理（PAM）、短效憑證與即時審批，並保留不可竄改的稽核紀錄，避免攻擊者「自毀痕跡」後無從調查。
    4. 對工程師做社交工程演練：重點是假獵頭、假合作邀約、要求下載程式或專案執行的「測驗」。
    5. 如果你的服務會收到加密資產，可把 FBI 公布的地址加入交易監控名單。

    一般用戶

    • 幣安表示用戶資產不受損失、由公司承擔；用戶不需要「重新驗證帳戶」或「申請補償」。看到聲稱幣安補償、解凍、退款的簡訊、LINE、Telegram 訊息，一律當詐騙處理。
    • 只透過官方 App 或自行輸入官方網址登入，不點訊息中的連結。
    • 交易所帳號開啟 2FA（建議用驗證器 App 或實體金鑰），設定提款白名單。
    • 長期不動用的資產，可評估移到自己掌控的錢包，並妥善保管助記詞，不要拍照存雲端。

    資料來源

  • 數發部通訊傳播控制系統資安防護基準 2027 年元旦生效：通傳關鍵基礎設施業者的遠端存取、網路隔離與老舊設備替代措施要先盤點

    數位發展部已訂定通訊及傳播領域關鍵基礎設施提供者的「控制系統資通安全防護基準」，9 月 16 日公告、2027 年 1 月 1 日生效。依《資通安全管理法》被指定為關鍵基礎設施提供者的通傳業者，自行開發或委外開發的控制系統都要符合這套基準；老舊或專用系統真的做不到的，可以提出佐證和替代控制措施，經數發部同意後實施。離生效只剩不到兩個月，受影響業者現在就該做差距盤點。

    新聞摘要

    • 法規名稱：數發部法規查詢系統列為「數位發展部所管通訊及傳播領域關鍵基礎設施提供者控制系統資通安全防護基準」（法規編號 GL000203）。OT-ISAC 報告的英文名稱為 Cybersecurity Protection Baseline for Control Systems of Critical Infrastructure Providers in the Communications and Broadcasting Sectors。
    • 公告與生效：2026 年 9 月 16 日公告，2027 年 1 月 1 日生效（iThome、OT-ISAC、Industrial Cyber 一致）。
    • 適用對象：經指定的通訊及傳播領域關鍵基礎設施提供者，範圍包括自行開發及委外開發的控制系統。OT-ISAC 特別指出，這不是適用全台所有 OT 環境的通用規定。
    • 彈性條款：因技術限制，或個別控制系統的設計、結構等因素確實難以執行規定措施的，可提出佐證資料及替代控制措施，經數發部同意後實施。

    背景：為什麼通訊傳播也要管「控制系統」

    一般講資安，多半是辦公室電腦、網站、資料庫這類「資通系統」（IT）。控制系統屬於營運技術（OT），是讓實體設施運作的系統，例如機房的電力、空調與監控，或網路與播送設備的管理控制。這類系統一旦被入侵或中斷，影響的不只是資料，而是通話、上網、廣播電視這些民眾每天用到的服務。

    依行政院「國家關鍵基礎設施安全防護指導綱要」，通訊傳播是我國關鍵基礎設施領域之一，和能源、水資源、交通、金融、醫院等並列。依《資通安全管理法》，關鍵基礎設施提供者由中央目的事業主管機關指定、報行政院核定，屬於「特定非公務機關」，本來就要訂定資安維護計畫、設資安專職人員並接受稽核。

    其他領域已經先有類似規範：交通部訂有交通領域工業控制系統資安防護基準（9 大構面、90 項控制措施），經濟部 2022 年（民國 111 年）公告能源與水資源領域工控資安防護基準，衛福部 2023 年發布醫院醫療儀器相關系統防護基準。數發部資安署今年 5 月也修訂《關鍵資訊基礎設施資安防護建議》，參考 ISA/IEC 62443、新增老舊設備的「替代方案（補償控制）」，作為各領域訂定防護基準的藍圖。這次通傳領域的基準，可說是補上這一塊。

    主要要求

    以下細項是 iThome 依法規內容整理的重點，本站尚未能直接讀取數發部條文與附表全文，屬單一來源，標為「未核實」，實際條文以數發部公告為準：

    • 分級防護（未核實）：依控制系統防護需求分為高、中、普三級，各級要求不同。
    • 遠端存取（未核實）：須事先授權，來源須是預先定義及管理的存取控制點，採加密與多因子鑑別，並監控連線。高、中等級系統若要修改工程邏輯或變更保護參數，還須多因子鑑別或第二階段確認。
    • 網路防護（未核實）：高等級系統須與一般資通系統網路隔離，並建立網路邊界監控；中等級須建立網路邊界存取管控。
    • 無法修補的漏洞（未核實）：須以網路區隔、限制存取來源或強化監測等替代控制措施降低風險。
    • 營運持續（未核實）：依等級訂定資料備份、備援測試及營運持續計畫演練要求。
    • 委外開發（未核實）：須依等級把系統開發各階段的資安需求寫進委外契約。

    已由兩個以上來源確認的是：基準涵蓋自行或委外開發的控制系統，以及老舊、專用系統可申請替代控制措施、經數發部同意後實施。

    時間線

    • 2026/5/19：數發部資安署發布修訂後的《關鍵資訊基礎設施資安防護建議》，參考 ISA/IEC 62443，新增補償控制。
    • 2026/9/16：數發部公告通訊及傳播領域關鍵基礎設施提供者控制系統資安防護基準。
    • 2026/10：OT-ISAC 亞太 OT／關鍵基礎設施資安政策報告（資料截至 10/20）列入此基準，評為「已確認的政策發展」。
    • 2026/11/2：iThome 報導。
    • 2027/1/1：基準生效。

    誰會受影響

    • 直接適用：經數發部指定、報行政院核定的通訊及傳播領域關鍵基礎設施提供者。實際名單未公開，業者應以收到的書面指定通知為準。
    • 間接受影響：替這些業者開發、維護控制系統的系統整合商、設備商與遠端維運廠商。委外契約、遠端連線方式都可能被要求調整。
    • 不直接適用：一般企業與其他領域的 OT 環境（其他領域另有各自主管機關的基準）。

    建議措施

    企業／IT 管理者

    • 先確認公司是否被指定為關鍵基礎設施提供者，並到數發部法規系統下載條文與附表全文對照。
    • 盤點所有控制系統（含委外開發），依防護需求初步分出高、中、普等級。
    • 清查所有遠端連線：廠商維護帳號、跳板機、VPN，收斂到少數受管控制點，補上多因子鑑別與連線紀錄。
    • 檢查 OT 與辦公室網路是否真的隔開，邊界有沒有存取管控和監控。
    • 列出無法更新或修補的老舊設備，提早規劃替代控制措施並準備佐證資料，生效前送數發部。
    • 檢視委外契約是否寫入各開發階段的資安需求，續約或新約時一併補上。
    • 確認備份能還原，把控制系統中斷情境納入營運持續演練。

    一般用戶

    • 這是規範業者的法規，民眾不需要做任何設定或申請。
    • 若接到自稱電信業者或「數發部」要你配合「資安新規」更新資料、點連結或提供驗證碼，都是詐騙，請掛斷並撥 165 查證。
    • 家中可準備第二種聯絡方式（例如不同業者的門號或市話），網路或通訊中斷時仍能聯繫。

    資料來源

  • 全球逾萬台 GitLab 仍暴露於兩個 CVSS 10.0 漏洞、台灣有 46 台：只更新到 10/12 版本還不夠，CVE-2026-97229 已遭攻擊列入 KEV

    新聞重點

    GitLab 在 10 月中、下旬接連修補兩個 CVSS 10.0 滿分漏洞，但到了 11 月初，網路上仍有大量自架（self-managed）GitLab 沒有更新。資安監測組織 Shadowserver 11 月初公布的掃描資料顯示，全球每天約可觀測到 3.9 萬台直接連上網際網路的 GitLab 執行個體，其中逾 1.13 萬台仍受 CVE-2026-110264 影響，另有逾 1,000 台仍受已遭實際攻擊的 CVE-2026-97229 影響。

    台灣也有 46 台暴露在這兩個漏洞的風險下（iThome 引述 Shadowserver 儀表板的國家統計；此數字目前只有 iThome 一家報導，未核實）。同一份國家統計中，美國約 2,700 台最多，其次是中國約 2,400 台、德國約 1,100 台；這三個國家的數字有 iThome 與韓國資安媒體 Zerowiz 兩方報導對得上。

    TWCERT/CC 已在 10/22 發布漏洞警訊，香港政府電腦保安事故協調中心（GovCERT.HK）也在 10/23 發出高危保安警報，並於 11/2 更新。美國 CISA 則在 10/29 把 CVE-2026-97229 列入「已知遭利用漏洞」（KEV）清單，要求聯邦機關在 11/1 前完成修補。

    要特別注意的是：只更新到 10/12 那一批修補版本（19.4.2、19.3.5、19.2.8）還不夠，這些版本只修了 CVE-2026-97229，CVE-2026-110264 要到 10/21 的版本才修好。另外，如果不是用 GitLab 官方套件或官方容器映像檔，而是自己編譯、自帶 Ruby，光升級 GitLab 也沒用，還要把 Ruby 升到 3.3.13、3.4.12、4.0.9 或更新版本。

    事件時間線

    • 10/12：GitLab 發布 19.4.2、19.3.5、19.2.8，修補 CVE-2026-97229（CI/CD 正規表示式編譯器整數溢位，CVSS 10.0）。
    • 10/13：Rapid7 在實驗環境重現攻擊，並公開概念驗證（PoC）程式碼；當時尚未發現實際攻擊。
    • 10/20–21：開源作業系統 Alpine Linux 的 GitLab（當時仍是未修補的 19.3.4）遭人以特製 CI 設定嘗試利用 CVE-2026-97229，造成 8 次工作程序當機，其中 4 次攻擊已走到一半。
    • 10/21：GitLab 再發布 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），並破例回補到 18.11 等較舊版本。
    • 10/22：TWCERT/CC 發布 GitLab 兩項漏洞警訊。
    • 10/23：上游 Ruby 推出修補版 3.3.13、3.4.12、4.0.9；GovCERT.HK 發布高危保安警報。
    • 10/28：Alpine Linux 公開事件經過，說找不到攻擊成功的證據、但也無法排除，因此整台 GitLab 從頭重建並重設所有帳號密碼。
    • 10/29（美東時間）：CISA 將 CVE-2026-97229 列入 KEV，聯邦機關修補期限 11/1。
    • 11/1–11/2：Shadowserver 公布未修補 GitLab 數量；iThome 於 11/2 報導台灣有 46 台。

    技術細節：兩個滿分漏洞與修補版本

    兩個漏洞的根源都在 Ruby 內建的正規表示式引擎 Onigmo，GitLab 的修補方式是替官方套件裡附帶的 Ruby 打補丁，而不是改 GitLab 本身的程式碼。兩者都是同一位研究人員 joaxcar 透過 HackerOne 漏洞賞金計畫通報。

    項目CVE-2026-97229CVE-2026-110264
    CVSS10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）10.0（同左）
    問題位置CI/CD 設定中的正規表示式處理（CI/CD Regular Expression Compiler）編譯特製正規表示式時的整數溢位（Regular Expression Compiler）
    影響版本（GitLab 官方公告）19.2 至 19.2.8 前、19.3 至 19.3.5 前、19.4 至 19.4.2 前7.0 起至 18.11.13 前、19.0 至 19.0.10 前、19.1 至 19.1.9 前、19.2 至 19.2.9 前、19.3 至 19.3.6 前、19.4 至 19.4.3 前、19.5 至 19.5.1 前
    修補版本19.4.2、19.3.5、19.2.8（10/12）19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13（10/21）
    是否遭實際利用是，10/29 列入 CISA KEV目前未見確認的實際攻擊；GovCERT.HK 稱已有 PoC 公開（未核實）
    Shadowserver 未修補數量逾 1,000 台逾 11,300 台

    幾個容易誤會的地方：

    • CVE-2026-110264 影響範圍大很多：從 2014 年的 GitLab 7.0 起都受影響，所以未修補數量是 CVE-2026-97229 的十倍以上。
    • 10/12 的修補不涵蓋 CVE-2026-110264：手腳快、10 月中就更新的管理者，仍要再升一次到 10/21 的版本。最簡單的做法是直接升到各版本線的最新修補版。
    • 自帶 Ruby 的安裝要另外升 Ruby：GitLab 官方公告明說，自行編譯或自製容器映像檔、未使用官方套件附帶 Ruby 的環境，必須把 Ruby 升到 3.3.13、3.4.12、4.0.9 或更新版本。Alpine Linux 就是因為自製映像檔用的是一般 Ruby，10/22 升到 19.3.6 後漏洞其實仍未修好。
    • 「免驗證」有前提：GitLab 評為未經驗證即可利用，但 Rapid7 指出，攻擊者需能把惡意的 .gitlab-ci.yml 和含 UTF-8 字元的檔案路徑提交到公開專案的分支；在開放任何人註冊、可自建專案的自架 GitLab 上，這個條件很容易達成。
    • 台灣 TWCERT 警訊把兩個漏洞的影響版本合併列出（7.0 至 18.11.13 前等），實際上 CVE-2026-97229 只影響 19.2 到 19.4，以 GitLab 官方公告為準。
    • GitLab.com 和 GitLab Dedicated 已由 GitLab 修補，不需處理；風險集中在企業、學校、機關自己架設的 GitLab。

    暴露統計（資料來源與日期）

    • 全球每日可觀測約 3.9 萬台、逾 11,300 台受 CVE-2026-110264 影響、逾 1,000 台受 CVE-2026-97229 影響：Shadowserver 11/1（當地時間）在社群平台發布，BleepingComputer、Techzine、iThome 皆引述，數字一致。
    • 國家分布：美國約 2,700、中國約 2,400、德國約 1,100（iThome、Zerowiz 一致）；Zerowiz 另列俄羅斯 919、法國 717、新加坡 338、南韓 253、印度 238、香港 228、芬蘭 206、日本 204（僅 Zerowiz，未核實）。
    • 台灣 46 台：僅 iThome 引述 Shadowserver 儀表板（11/2 報導），未核實。
    • 計算方式：Shadowserver 是依伺服器對外顯示的 GitLab 版本判斷，屬「版本比對」，不代表該伺服器一定能被攻破，也不代表已遭入侵；國家統計是兩個漏洞標籤加總，同一台可能被算兩次（依 Zerowiz 說明，未核實）。反過來說，攻擊者只看版本號也能列出同一份目標清單。

    怎麼檢查有沒有被入侵

    • 先確認版本：在 GitLab 管理區（Admin Area）或 /help 頁面看目前版本，對照上表；自帶 Ruby 的環境另外執行 ruby -v 確認 Ruby 版本。
    • 查 GitLab 官方公布的威脅偵測項目：CVE-2026-97229 有 6 項（如 Onigmo native worker crash、Graphql cilint hostile regexp、ci regexp guard rejection、ci lint workhorse worker crash 等），CVE-2026-110264 有 2 項（Onigmo native worker crash、Org mode render error burst）。
    • 找不明原因的 GitLab 工作程序（worker）當機紀錄，尤其是集中在特定時段、且與 CI lint 或管線設定提交同時發生者。Alpine Linux 就是從 8 次工作程序當機發現攻擊。
    • 檢查近期新註冊的帳號、新建的公開專案，以及含有異常正規表示式或 UTF-8 檔案路徑的 .gitlab-ci.yml 提交。
    • 檢查伺服器上是否有不明檔案、SSH 金鑰、Git hooks、排程或程序，以及 git 使用者是否有異常的對外連線。
    • 注意：Alpine Linux 指出，攻擊成功可能不會留下當機或網頁日誌痕跡；如果日誌已經不完整，又曾在未修補狀態下對外開放，最保險的做法是視同已遭入侵。

    給企業／IT 管理者

    • 立即升級到各版本線最新修補版（至少 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10 或 18.11.13），不要停在 10/12 的版本。
    • 自編譯或自製容器映像檔者，同步把 Ruby 升到 3.3.13、3.4.12、4.0.9 或更新。
    • 19.4.3、19.3.6 含資料庫遷移，單節點升級會停機，先排好維護時段，但不要因此拖延。
    • 暫時關閉開放註冊、限制一般帳號建立公開專案，降低攻擊門檻。
    • 非必要不要把 GitLab 直接開在網際網路上，改放 VPN 或零信任存取後面。
    • 曾在未修補狀態下對外開放者，輪換管理員密碼、個人與專案存取權杖、Runner 權杖、部署金鑰與 CI/CD 變數中的雲端金鑰。
    • 依上方項目做入侵檢查，並保留日誌與對外連線紀錄。
    • 訂閱 Shadowserver 免費報告或留意 TWCERT/CC 通報，確認自家 IP 是否在名單上。

    給一般用戶

    • 如果你只用 GitLab.com，不需要自己處理，但建議開啟兩步驟驗證。
    • 如果你用的是公司、學校或開源專案自架的 GitLab，留意管理者的重設密碼或權杖通知，依指示處理。
    • 在家用 NAS 或 Docker 自架 GitLab 的玩家，請檢查版本並更新，不要直接開對外連接埠。
    • 不要把雲端金鑰、密碼直接寫進程式碼或 CI 設定。

    資料來源

  • 一週兩家上市櫃遭勒索加密：台數科伺服器檔案被加密、橙的 NAS 中招，備份與隔離決定復原速度

    台灣上市櫃公司又傳勒索攻擊。有線電視多系統業者台數科（6464）10 月 30 日發布重大訊息，證實公司及子公司資訊系統遭外部駭客入侵，部分伺服器檔案被惡意加密；兩天前（10 月 28 日），汽車零配件製造商橙的（4554）也公告部分區域網路儲存設備遭勒索病毒攻擊。兩家公司都表示目前評估對營運沒有重大影響，但「檔案被加密」本身就說明攻擊者已經進到內網。

    事件經過

    • 10 月 28 日：橙的發布資安事件說明，部分區域網路儲存設備遭勒索病毒攻擊，已啟動防禦機制、斷網隔離並啟動資安應變，初步評估對整體營運不致造成重大影響。
    • 10 月 30 日 18:06：台數科發布重大訊息，事實發生日為 115 年 10 月 30 日。公司及子公司資訊系統遭外部不明駭客攻擊，部分伺服器檔案遭惡意加密，影響部分內部作業系統正常運作。
    • 台數科的處理方式包括：隔離受影響設備、管制帳號權限並變更密碼、部署端點偵測監控（EDR）、以安全備份還原系統，並持續鑑識分析與調查影響範圍。
    • 台數科表示目前評估沒有個資外洩，也沒有核心機密或重要文件外洩，對公司及子公司營運與財務無重大影響；保險理賠則為「不適用」。
    • 兩家公司都沒有公布攻擊者身分、入侵途徑或勒索軟體家族。

    重點

    項目台數科（6464）橙的（4554）
    公告日期2026/10/302026/10/28
    受影響範圍公司及子公司部分伺服器檔案遭加密部分區域網路儲存設備
    公司處置隔離設備、帳號權限管制與改密碼、部署 EDR、備份還原、鑑識啟動防禦機制、斷網隔離、資安應變
    公司自評影響無個資及核心機密外洩，營運財務無重大影響對整體營運不致造成重大影響
    入侵途徑未公布未公布
    • 「沒有個資外洩」是公司目前的評估，鑑識仍在進行，後續若有更新，會以補充重訊公告為準。
    • 這兩起事件與近期 91APP Commerce Cloud 遭自動化攻擊、多家品牌陸續發重訊的事件是不同類型：91APP 是資料被擷取，台數科、橙的則是檔案被加密。
    • 兩家公司都能靠備份或隔離讓營運維持，顯示「有可用的離線備份」與「能快速切斷受害設備」仍是勒索事件中最關鍵的兩件事。

    對你的實務建議

    企業／IT 管理者

    1. 盤點所有 NAS 與檔案伺服器：關閉不必要的對外服務（管理介面、QuickConnect、UPnP 轉發等），韌體與作業系統更新到最新版。
    2. 備份遵守 3-2-1：至少一份離線或不可變（immutable）備份，並且實際演練還原，不要只看備份任務顯示成功。
    3. 端點與伺服器部署 EDR，並把 NAS、伺服器的登入紀錄集中到 SIEM 或日誌平台，留意大量檔案改名、異常時段登入。
    4. 網段切分：使用者電腦不要能直接以管理權限存取 NAS 與伺服器；網域管理員帳號只在專用管理主機上使用。
    5. 事件發生時先隔離、保全證據再還原；上市櫃公司請依規定在時限內發布重大訊息並通報主管機關。

    一般用戶

    1. 台數科表示沒有個資外洩，訂戶目前不需特別動作，但若接到自稱業者、要求「重新驗證」或付款的電話或簡訊，請直接打官方客服查證。
    2. 家用 NAS 也是勒索軟體的常見目標：關掉對外連線功能、改掉預設帳密、開啟兩步驟驗證。
    3. 重要照片與文件至少放兩個地方，其中一份平時不接電腦的外接硬碟。

    資料來源

  • 香港考評局國際考試系統遭網絡攻擊：約 1.69 萬名考生姓名、生日、電郵外洩，香港 10 月資料外洩連環爆

    香港考試及評核局（考評局）10 月 30 日公布，旗下部分國際考試資訊系統發生網絡安全事故，約 16,900 名申請兩項國際考試、居住在中國內地的考生個資外洩，外洩欄位包括姓名、出生日期及電郵地址。考評局已報警並通報香港個人資料私隱專員公署。這是香港 10 月以來接連通報的多宗資料外洩事故之一。

    事件經過

    • 10 月 29 日：考評局發現部分國際考試資訊系統出現網絡安全事故。
    • 10 月 30 日：考評局報警並通報私隱專員公署，同時通報相關考試主辦機構，並安排通知受影響人士。
    • 考評局表示，涉事系統只用於個別小規模國際考試；香港中學文憑考試（DSE）及絕大部分國際考試使用獨立報考系統，目前未有證據顯示受影響。
    • 考評局已設立查詢熱線（3628 8787）及電郵（ie@hkeaa.edu.hk）。

    重點：香港 10 月接連出現的外洩通報

    機構公開資訊可能外洩資料
    考評局約 16,900 名內地居住考生（兩項國際考試）姓名、出生日期、電郵
    國泰航空（經 Amadeus）約 5.3 萬宗預訂紀錄；涉及多少香港客戶未能確定姓名、訂位編號、航班資料；少部分含聯絡方式、旅遊證件、會員號碼
    香港航空、友和 YOHO、百老滙10 月 27 日報導：港航約 815 名、友和約 790 名；百老滙人數未公布姓名、電話等；有客戶接到詐騙來電
    • 據《大公報》11 月 1 日報導，私隱公署表示港航受影響人數更新為 864 名、友和為 1,073 名，公署並共接獲 51 宗投訴及 48 宗查詢（未核實，僅單一來源）。
    • 世界日報引述香港網絡安全事故協調中心提醒，外洩資料可能被用來冒充航空公司客服，增加針對性詐騙風險。
    • 多宗事件都牽涉第三方供應商或外判系統，問題不一定出在品牌本身，但受害的是同一批客戶。

    對你的實務建議

    企業／IT 管理者

    1. 盤點所有「小規模、獨立運作」的報名、活動、問卷系統，這類系統常被遺忘在修補與監控範圍之外。
    2. 委外系統要在合約寫清楚：可接觸個資的帳號清單、存取日誌保存與調閱權、事件通報時限、過期資料刪除期限。
    3. 第三方帳號一律啟用多因素驗證（MFA），並定期輪替服務帳號密碼；國泰事件中，供應商系統正是被人用合法登入憑證存取。
    4. 資料最小化：考試或活動結束後，不需要的個資就刪除或去識別化。
    5. 準備好對外通報範本與查詢熱線流程，事發後才寫會拖慢時間。

    一般用戶

    1. 曾報考考評局國際考試、或是國泰、港航、友和、百老滙客戶，請特別留意自稱「考試機構」「航空公司」「客服」的電郵與來電。
    2. 對方說得出你的姓名、航班或訂單資料，不代表就是真的官方，一律掛斷後自行撥打官網電話查證。
    3. 不要點擊訊息中的退款、改期、補件連結，也不要提供信用卡號、OTP 驗證碼。
    4. 同一組密碼若在多個網站使用，現在就改，並開啟兩步驟驗證。

    資料來源

  • WordPress 7.1.4 修補核心更新競態 RCE：Wordfence 24 小時擋下近 6.3 萬次攻擊嘗試，自架站請立即更新並封鎖 wp-content/upgrade

    WordPress 在 10 月 28 日釋出 7.1.4 安全更新，一次修補 22 個漏洞，其中最危險的是「核心更新時的競態條件（race condition）」，可能讓未登入的攻擊者在網站更新的短暫空檔執行程式碼。資安公司 Wordfence 表示，修補釋出後 24 小時內就擋下 62,969 次針對此漏洞的攻擊嘗試。自架 WordPress 的站長請立即更新。

    事件經過

    • 10 月 28 日：WordPress 釋出 7.1.4，並同步替 4.7 以來的舊分支推出修補版。
    • 漏洞影響 WordPress Core 4.7 至 7.1.3，CVSS 8.1，目前沒有 CVE 編號。
    • 成因：完整套件（full-package）核心更新時，新檔案會解壓到 wp-content/upgrade 底下可預測的暫存目錄，其中包含 WordPress 安裝程式；若該目錄可從網路直接存取，攻擊者在剛好的時間點請求安裝程式，就可能進一步執行 PHP 程式碼。
    • Wordfence 觀察到攻擊來源反覆輪詢 setup-config.php 等路徑，其中兩個最大來源對少數網站連續輪詢約 14.5 小時，想抓住更新的那幾秒空檔。

    重點

    項目內容
    受影響版本WordPress 4.7～7.1.3
    修補版本7.1.4；舊分支如 7.0.8、6.9.11、6.8.12 等
    攻擊條件正在進行完整套件核心更新、暫存目錄可從外部存取並能執行 PHP、路徑可預測、清理前時間足夠
    已觀察到的攻擊24 小時內 62,969 次攻擊嘗試（Wordfence 統計）；報導未證實有成功入侵案例
    同批修補另有多個 XSS、資訊洩漏問題，以及因 eMudhra 憑證撤銷而更新內建根憑證
    • 這個漏洞的時間窗在實驗室中只有幾秒，但攻擊者用「持續輪詢」來提高命中機率，越晚更新、越常做大版本更新的網站，越危險。
    • WordPress 官方提醒，只有最新版本才會持續獲得完整支援；4.6 以前已不再提供安全更新。

    對你的實務建議

    企業／IT 管理者

    1. 立即將所有 WordPress 站台更新到 7.1.4，或該分支的最新修補版；用代管服務的，請向業者確認已完成更新。
    2. 在 Web 伺服器層面封鎖對 wp-content/upgrade/ 的外部存取，並禁止該目錄執行 PHP（Nginx location 規則或 Apache .htaccess）。
    3. 檢查存取日誌：是否有對 wp-content/upgrade 下 PHP 檔（如 setup-config.php）的異常請求。
    4. 檢查是否出現陌生的管理員帳號、外掛或 PHP 檔案，有疑慮就從乾淨備份還原並更換所有密碼與金鑰（含 wp-config.php 的 salts）。
    5. 注意：Patchstack 指出，被解壓的暫存副本會載入自己的檔案，網站內的 PHP 防火牆外掛不會生效，必須在 Web 伺服器或前端 WAF 層阻擋，並確認該目錄無法被列出（directory listing）。
    6. 同批修補的漏洞大多需要「投稿者（Contributor）以上」帳號才能利用，順便清查誰擁有這些權限。

    一般用戶

    1. 自己有部落格、社團網站或小店網站用 WordPress 的，登入後台「控制台 → 更新」確認版本是 7.1.4。
    2. 如果是請朋友或接案工程師架的站，請直接問對方是否已更新，不要假設「應該會自動更新」。
    3. 網站管理帳號一律開啟兩步驟驗證，並移除不用的外掛與佈景主題。

    資料來源

  • 竊密程式 VOLTA 叫 LLM 幫受害者「估價」：預設呼叫 Claude Opus 4.6，被拒就改用 Kimi K2、Gemini 2.5 Flash

    Cisco Talos 10 月 31 日公開一款名為 VOLTA（自稱 VOLTA-AUTODOXER）的 Windows 竊密程式：偷完帳密、Cookie、信用卡與加密貨幣錢包之後，它會把整理好的受害者資料丟給大型語言模型（LLM），請模型扮演「鑑識情報分析師」，評估這個人「值多少錢」。如果模型拒絕回答，它還會自動換下一個模型。

    事件經過

    • Talos 透過其 CAIRN 研究計畫發現這支程式，研究員 Ryan Fetterman 於 10 月 31 日發表分析；WIRED 同日獨家報導。
    • 樣本首次被看到的時間為 2026 年 10 月 11 日（UTC）。
    • Talos 並未追蹤到這支程式是否已在真實環境中被大規模使用。
    • 程式採「建置器（builder）」模式，設定欄位可替換，Talos 研判可能是販售給不同買家使用的商品化惡意程式。

    重點：LLM 在這裡扮演什麼角色

    項目內容
    呼叫管道透過 OpenRouter 的 Chat Completions API
    預設模型Anthropic Claude Opus 4.6
    被拒時的備援Moonshot AI Kimi K2 → Google Gemini 2.5 Flash
    拒答偵測檢查回應中是否出現「I can’t」「I’m not able」等字樣
    輸出內容受害者摘要、「WHAT THEY’RE WORTH」（可變現資產排名）、「THEIR OPSEC」（資安習慣與密碼衛生評估）
    • 除了傳統竊密，VOLTA 還會用偷來的 Gmail 工作階段搜尋 Amazon、Uber Eats、DoorDash 等收據來確認住址，並把電腦上所有已存 Wi-Fi 密碼以明文匯出。
    • Talos 指出，提示詞刻意寫得不像惡意用途，同時預先設計「被拒就換模型」，代表攻擊者已把模型防護（guardrail）當成要繞過的常態障礙。
    • 即使沒有 API 金鑰，竊密功能照樣運作；LLM 只是「加值功能」，作用是取代人工分析、讓低階攻擊者也能快速挑出高價值目標。

    對你的實務建議

    企業／IT 管理者

    1. 依 Talos 建議，用應用程式控管限制哪些程式能以 --headless 參數啟動 Chrome，至少對非開發工具啟動 headless Chrome 發出告警（VOLTA 靠此繞過 Chrome 的 App-Bound Encryption）。
    2. 監控端點對 openrouter.ai 等 LLM API 的異常連線，特別是非開發人員的電腦。
    3. 若懷疑中招，保存 %APPDATA%\volta_debug.txt（竊取紀錄），撤銷所有可能外洩的權杖與工作階段，並強制改密碼。
    4. 推動密碼改存硬體保護的憑證庫或密碼管理器，少用瀏覽器內建儲存。

    一般用戶

    1. 竊密程式最常藏在破解軟體、遊戲外掛、假更新裡，不要下載來路不明的程式。
    2. 重要帳號開啟兩步驟驗證；若電腦曾中毒，除了改密碼，也要在各服務「登出所有裝置」。
    3. 加密貨幣助記詞不要以明文存在電腦裡；若曾外洩，請視錢包為已失守，盡快轉移資產。
    4. Wi-Fi 密碼別用姓名、生日或門牌號碼，這正是 VOLTA 要求 LLM「連連看」的線索。

    資料來源

  • 群暉 NAS 遭 C3RB3R 勒索軟體攻擊：舊版 DSM 成目標，檔案被改成 .L0CK3D，快更新並關掉對外連接埠

    台灣 NAS 大廠群暉（Synology）10 月 29 日發出聲明，證實有攻擊者利用 2024 年 12 月前就已修補的漏洞，鎖定仍執行舊版 DiskStation Manager（DSM）作業系統的 NAS，加密裡面的資料並勒索贖金。受害設備上的檔案會被加上 .L0CK3D 副檔名（中間是數字 0，不是字母 O），各資料夾也會出現名為 read-me3.txt 的勒索信。台灣教育機構資安通報平台（ANA）、澳門司法警察局已相繼發出預警。

    新聞重點

    • 群暉官方說法：攻擊利用的是 2024 年底已修補的漏洞，請用戶參考安全公告 Synology-SA-24:20，立即更新 DSM，並開啟自動更新。群暉聲明沒有公布受害設備數量，也沒有點名勒索軟體名稱。
    • 勒索軟體：中國資安公司 360 分析受害設備樣本，確認是老牌勒索家族 Cerber 的變種「C3RB3R」，加密後的檔案副檔名為 .L0CK3D，勒索信為 read-me3.txt，指示受害者用 Tor 瀏覽器到指定網站付款。
    • 入侵途徑說法不一：群暉指向 2024 年的 SA-24:20；360 則指入口是群暉 2026 年 9 月 18 日才修補的兩個高危漏洞 CVE-2026-13639、CVE-2026-13684（公告 SA-26:13）。兩邊說法是否指同一批攻擊，目前沒有官方說明。
    • 和 PHP2Shell 的關係：香港媒體 HKEPC 的報導把這波感染和近期的 PHP2Shell 漏洞（群暉公告 SA-26:14）連在一起；但據 iThome 報導，群暉發給媒體的新聞稿表示這次事件與 PHP 漏洞無關。NAS Compares 的整理也認為，現有資料無法證明 PHP2Shell 是這波攻擊的原因。
    • 目前沒有公開的免費解密工具：多方報導都指出，C3RB3R 沒有經確認的通用解密工具，復原主要靠攻擊者碰不到的快照或離線備份。

    事件時間軸

    • 2024/11/5：群暉發布 Synology-SA-24:20（Pwn2Own 2024 相關漏洞），致謝名單包括台灣 DEVCORE 研究團隊。DSM 7.2.2 修補版同步推出。
    • 2024/11/12～12/5：DSM 7.2.1（11/12）、DSM 7.1（11/26）、DSM 6.2（12/5）陸續推出修補版，這就是群暉所說「2024 年 12 月已修補」的時間點。
    • 2026/9/18：群暉發布 Synology-SA-26:13，一次修補 8 個 DSM 漏洞，其中 CVE-2026-13639、CVE-2026-13684 為 CVSS 9.8 的「Critical」等級。
    • 2026/10 月初起：360 反勒索服務陸續接到群暉 NAS 遭加密的求助。
    • 2026/10/29：群暉發布聲明呼籲更新 DSM；360 同日發布分析；台灣教育機構資安通報平台（ANA）發布漏洞預警（影響等級「高」）；HKEPC 報導並呼籲用戶先斷線。
    • 2026/10/30：澳門司法警察局網絡安全事故預警及應急中心發出警情通告，形容這是「全球自動化大規模攻擊」，並已向當地關鍵基礎設施營運者發出預警；iThome 同日報導。

    技術細節

    群暉點名的 SA-24:20（2024 年修補）

    • CVE-2024-10441（CVSS 9.8，Critical）：DSM 系統外掛服務（system plugin daemon）的輸出編碼問題，未經登入的遠端攻擊者可執行任意程式碼。
    • CVE-2024-50629（CVSS 5.3）：webapi 元件問題，可讀取部分檔案。
    • CVE-2024-10445（CVSS 4.3）：更新功能的憑證驗證問題，同網段的中間人攻擊者可寫入部分檔案。

    群暉聲明只說「一個」2024 年 12 月已修補的漏洞，沒有指明編號；iThome 報導列出上面三個 CVE。三者中只有 CVE-2024-10441 可遠端執行程式碼。

    DSM 版本線SA-24:20 最低修補版本
    DSM 7.2.27.2.2-72806-1 或更新
    DSM 7.2.17.2.1-69057-6 或更新
    DSM 7.27.2-64570-4 或更新
    DSM 7.17.1.1-42962-7 或更新
    DSM 6.26.2.4-25556-8 或更新
    BeeStation（BSM）1.1-65374 或更新

    360 點名的 SA-26:13（2026 年 9 月修補）

    • CVE-2026-13684（CVSS 9.8）：SCGI 元件的輸出編碼問題，未經登入的遠端攻擊者可讀寫任意檔案、造成服務中斷。
    • CVE-2026-13639（CVSS 9.8）：登入邏輯的亂數熵不足，同樣可讓未經登入的遠端攻擊者讀寫任意檔案、造成服務中斷。
    DSM 版本線SA-26:13 最低修補版本
    DSM 7.47.4-90075 或更新
    DSM 7.37.3.2-86009-4 或更新
    DSM 7.2.27.2.2-72806-9 或更新
    DSM 7.2.17.2.1-69057-12 或更新

    重點：只裝到 SA-24:20 的修補版本，仍然擋不住 SA-26:13 的漏洞。群暉官方對兩份公告都表示「無緩解措施」，唯一的解法是更新。最保險的做法是直接更新到自己機型可以安裝的最新 DSM 版本。

    C3RB3R 會做什麼

    • 依 360 分析：進入設備後跳過 27 個系統目錄，避免系統當機，其餘目錄逐層加密。
    • 依 360 分析：每個檔案用獨立金鑰以 ChaCha8 加密，金鑰再用 RSA-2048 保護後附在檔案尾端；副檔名改為 .L0CK3D，資料夾內留下 read-me3.txt。
    • 放在同一台 NAS 上、可寫入的本機備份（例如沒有多版本或隔離保護的 Hyper Backup 目錄）也可能一併被加密（HKEPC、RSM 香港）。
    • 【未核實】一份公開的受害設備鑑識報告（GitHub soimy/c3rb3r-rescue）指出，該案例設備為 DSM 7.2-64561，入侵方式「高度符合」CVE-2024-10441，但完整攻擊鏈尚未取得。另有資安簡報（TrebSec）提到有受害者已執行較新的 DSM 7.4.1，不排除另有新漏洞或透過套件、容器、帳密入侵。這兩點目前都只有單一來源。

    怎麼看自己有沒有中招

    • File Station 裡出現大量 .L0CK3D 結尾的檔案。
    • 資料夾裡出現 read-me3.txt，內容有「C3RB3R INSTRUCTIONS」字樣。
    • 日誌中心出現異常登入、短時間大量檔案被修改，或 CPU／硬碟長時間滿載。

    防護建議：企業／IT 管理者

    • 盤點並更新：清查所有群暉 NAS 的 DSM 版本，至少高於上面兩張表的版本，最好直接更新到最新版；同步更新套件中心內的 PHP、Web Station、Mail Station、Calendar 等套件，用不到的套件直接移除。
    • 收回對外曝露：關閉路由器上指向 NAS 的連接埠轉發（常見為 5000、5001、80、443）與 UPnP；遠端管理改走 VPN，管理介面以防火牆設定可信 IP 白名單。
    • 帳號強化：停用預設 admin 帳號，所有帳號使用高強度密碼並啟用兩步驟驗證（2FA），開啟自動封鎖 IP；不需要時關閉 SSH。
    • 檢查 Container Manager：在 NAS 上用容器架設 GitLab 等對外服務的，確認容器版本已修補、沒有掛載過大權限的目錄。
    • 快照與備份：共享資料夾開啟快照並啟用防竄改（不可變快照），定期確認快照有正常產生；至少保留一份與 NAS 平時不連線的離線或異地隔離備份。
    • 監控：留意日誌中心的異常登入與大量檔案異動，一發現可疑副檔名立刻斷網檢查。
    • 已經中招：立即隔離設備（拔網路線、暫停 Cloud Sync／Hyper Backup 等同步，避免覆蓋雲端好的備份），保留勒索信、系統與 SSH 日誌，不要自行重灌或初始化硬碟，聯絡群暉技術支援並依規定通報（教育單位走 ANA 通報）。不要付贖金。

    防護建議：一般用戶

    • 現在就更新：到「控制台 → 更新與還原」安裝最新 DSM，並開啟自動更新。
    • 別把 NAS 直接開到網路上：不確定自己有沒有開連接埠轉發，就到路由器關掉指向 NAS 的轉發和 UPnP；外出要連回家，改用 VPN 或官方的遠端連線服務，用不到 QuickConnect 就先關掉。
    • 帳號三件事：停用 admin、換一組只用在 NAS 的強密碼、打開兩步驟驗證。
    • NAS 不等於備份：重要照片和文件另外存一份到平常不插著的外接硬碟；有開快照功能的話記得打開。
    • 發現檔案變成 .L0CK3D：先拔網路線，不要刪檔、不要重灌，也不要付贖金；網路上自稱能解密的工具或「代解密服務」要特別小心。

    資料來源

  • 思科總裁給 27 歲工程師「無限 AI token」：目標 24 個月重構 98% 舊程式碼，AI 改寫程式的資安風險要看審查

    思科（Cisco）總裁暨產品長 Jeetu Patel 日前接受美國《財星》（Fortune）訪問時透露，他給一名 27 歲工程師「不設上限」的 AI token 額度，目標是在 24 個月內重構思科 98% 的舊程式碼。台灣的動區動趨、AI 新視界、TokenPost 中文版也已跟進報導。思科的路由器、交換器、防火牆在台灣企業和電信網路中相當普遍，這項計畫往後會不會影響產品的穩定與安全，值得 IT 管理者留意。

    新聞重點

    • 《財星》10 月 30 日（美東時間）報導：Patel 在一場小型圓桌晚宴上說，他給了工程師 Padmanabhan Krishnamurthy（暱稱 Paddy）無限的 token，「因為他要重構程式碼……你可以放手去做（go nuts）」。Tom’s Hardware、India Today、NDTV、InfoQ 及台灣多家媒體都引述了這段內容。
    • Krishnamurthy 2023 年共同創辦即時翻譯新創 EzDubs，2025 年隨思科收購 EzDubs 加入公司。Patel 形容他原本「被埋在組織裡，做著不具策略意義的事」，職級比 Patel 低「五層」。
    • Krishnamurthy 認為只要兩人小組就能重寫思科的舊程式碼。他先給自己 4 週做概念驗證，最終目標是 24 個月內重構 98% 的舊程式碼。
    • 98% 只是目標，不是成果。目前報導都沒有說明舊程式碼的範圍與規模、98% 怎麼計算、用哪一家的 AI 模型、token 花了多少錢，也沒有公布驗證結果。TokenPost 中文版指出，目前找不到思科針對這項計畫的官方公告。

    思科做了什麼、為什麼要做

    這不是思科第一次公開談 AI 寫程式。Patel 在 2026 年 2 月的思科 AI 高峰會上表示，思科第一個程式碼 100% 由 AI 撰寫的產品是 AI Defense；他預估 2026 年底前會有約 6 項產品的程式碼完全由 AI 撰寫，2027 年底前目標是約 70% 的產品組合達到同樣程度（Network World、India Today 及思科新聞中心皆有記載）。他同時強調，人類仍要負責撰寫規格與審查程式碼，開發瓶頸會從「寫程式」轉到「讀程式、審程式」。

    思科也公開過一個較具體的案例：DevNet 開發者文件平台 PubHub 因為無法達到思科內部資安標準，被資安部門要求改用 Go 語言重建。根據思科官方部落格（10 月 28 日發表 Part 2），原定 9 個月的工作由 12 名工程師約 5 個半月完成，9 月中旬上線，比原定 12 月底提早約 3.5 個月。團隊先讓 AI 讀舊程式碼、產生架構文件並由專家審核，再讓 Claude Code 等 AI 代理撰寫完整功能與測試；每一筆變更仍須人工審查，審查端也導入了 AI 審查代理。這段內容 TokenPost 中文版也有轉述。

    另有報導指出，Patel 在 10 月 8 日的 Y Combinator 訪談中提到，思科曾用 AI 把約 50 萬行內部程式碼重構成約 12 萬行，花了約兩週（未核實：目前只有 TokenPost 一個來源，也沒有品質或缺陷率資料）。

    資安面：AI 重寫程式碼的好處與風險

    可能的好處

    • 清理技術債：舊程式碼常留有過時函式庫、弱加密或寫死的設定，重寫是換掉它們的機會。PubHub 的重建本身就是為了符合資安標準。
    • 改用較安全的語言與標準基底：PubHub 改用 Go，並建立在思科新服務共用的安全基底映像（secure base image）上。
    • 把資安規則交給 AI 遵守：思科 2025 年 10 月開源 Project CodeGuard，2026 年 2 月捐給安全 AI 聯盟 CoSAI（OASIS 旗下），用規則引導 AI 寫程式時避開寫死密碼、弱加密、缺少輸入驗證與權限檢查等問題。

    需要注意的風險

    • 功能回歸與新漏洞：重構理論上不改變功能，但大規模改寫可能漏掉藏在舊程式碼裡、沒有文件記載的邊界情況。PubHub 團隊也提到，這些邊界情況「活在程式碼裡，而不是文件裡」。
    • 審查量暴增：AI 產出速度遠快於人工審查，Patel 本人和 PubHub 團隊都說審查是新的瓶頸。審查跟不上時，有問題的程式碼可能流入產品。
    • AI 常見的不安全寫法：CodeGuard 官方列出 AI 寫程式時容易跳過輸入驗證、寫死憑證、用弱加密演算法、漏掉身分驗證與授權檢查。思科也表明 CodeGuard 無法保證產出的程式碼一定安全，不能取代同儕審查。
    • 資訊不透明：目前沒有公開這項計畫涵蓋哪些產品，例如是否包括 IOS 等網通設備作業系統，也沒有測試方式與缺陷率數據。

    建議怎麼做

    企業／IT 管理者

    • 使用思科設備的單位，持續訂閱思科資安公告（Cisco Security Advisories），重大版本更新先在測試環境驗證，再分批上線。
    • 維持設備與軟體清冊，留意新版本的發行說明與已知問題，保留可回復的設定備份與舊版韌體。
    • 自家團隊導入 AI 重構時，比照 PubHub 做法：先讓 AI 產生文件並由專家確認，所有變更都要人工審查，搭配自動化測試與新舊版本比對。
    • 在 AI 寫程式流程中加入資安規則（例如 CodeGuard）與靜態掃描、相依套件檢查，但不要把它們當成取代審查的保證。

    一般用戶

    • 這則新聞對一般用戶沒有立即影響，不需要特別處理。
    • 家用路由器、手機與電腦照常開啟自動更新；更新後如果網路異常，先重新開機，再查詢廠商公告。
    • 自己用 AI 寫小程式或網頁時，不要把密碼、API 金鑰直接寫進程式碼，上線前請懂資安的人看過。

    資料來源