AI 與科技新聞摘要 - 2026/09/16

一個開發者打完一句話，AI 助理接著吐出一個套件名。他裝了。

市面上那些 AI 防護產品的型錄，大致照「怎麼擋提示詞注入、怎麼避免它把憑證講出去、怎麼限制它讀得到哪些檔案」在排。9 月 15 到 16 日這兩天出來的幾份報告，擺進這個分法裡會有點卡。

一、開發者照著助理的建議，裝了那個套件

Mandiant 在 2026 年 9 月的 AI 風險與韌性報告裡記了一個案子，The Hacker News 在 9 月 16 日轉述。受害的是一家未具名的 SaaS 業者。

起點不在套件庫，在一段還在進行中的對話。攻擊者挾持了該公司一段正在進行的 AI 編碼助理對話，然後在那段對話裡推薦了一個被下毒的套件。開發者採納了這個建議，經由一個被汙染的 PyPI 套件安裝了資訊竊取程式。接著 GitHub OAuth token 被竊，攻擊者拿它把 Shai-Hulud 蠕蟲部署到約 100 個內部儲存庫。最後一步繞了回來：該公司官方命名空間裡的一個被下毒套件，在另一名員工拉取那個版本時造成二次感染。

技術環節上沒有一樣是新的。被下毒的 PyPI 套件、被竊的 OAuth token、會自我散播的蠕蟲，這三樣資安圈已經講到膩了。變的是第一步的位置。

攻擊者在該公司的官方命名空間裡留了一個被下毒的套件，於是第二個受害者根本不需要被挾持任何對話，他只是照內部流程拉了一個自家的套件版本。內部命名空間在多數團隊的設定裡是最不會被質疑的那一格，因為它按定義就是「我們自己的東西」，掃描規則、審查流程、心理上的警戒線全部都比外部套件鬆。這條鏈從一段對話進去，最後停在一個大家都不會多看一眼的地方。

這個案子最不舒服的地方，是它把「人在迴圈裡」這句話拆開來看了一次。整條鏈上確實有一個人做了決定：開發者看到建議、判斷它合理、然後採納。以我們平常在合規文件上寫的標準，這一格是打勾的，有人審、有人批准、有紀錄。而它一點用都沒有，因為人審的是建議本身，不是建議的來源。這件事的形態值得單獨記一筆：供應鏈攻擊的入口，從套件庫前移到了開發者與 AI 助理的對話。

被挾持的對象是一段「進行中的」對話階段，這個限定詞我認為是整則的重點。一段跑了半小時的對話，可信度是前面那二十次正確回答累積出來的。它讀過你的檔案結構、記得你剛才踩了什麼坑、上一輪還幫你修好了一個 import 路徑。在那個狀態下出現的第二十一個建議，跟你剛開 session 問的第一個問題，權重完全不同。攻擊者挑中的是一段已經建立好信任的關係。

開發者對套件庫的信任，一直是帶摩擦的。你會去看星數、看下載量、看最後一次更新是什麼時候、看維護者是不是同一個人。這些動作不一定有效，但它們存在，而且大家知道自己在做什麼。對助理建議的信任沒有這一層。那個套件名是接在你自己剛剛打的那句話後面出現的，它讀懂了你的專案結構、你的 import、你卡住的地方，然後給你一個名字。你會去查它，跟你會去查同事口頭講的一個套件名，機率差不多。Mandiant 的轉述沒有往這個方向講，這段是我自己接的。

約 100 個內部儲存庫這個數字，量的是這家公司自己的資產，不是公開生態系的感染範圍。一個 OAuth token 能推到幾個 repo，取決於它當初被授了多大的 scope，而開發用的 token 通常授得很寬鬆，因為每次遇到權限不足就回去改 scope 太煩了。蠕蟲在這條鏈上只是執行者，決定它能走多遠的是那個 token 的權限範圍。

真正讓我覺得棘手的是報導留下的空白。被挾持的是哪一家編碼助理、哪一家公司、挾持用的是什麼手法、整件事的時間線，全部沒有公開。原文寫得很直接，它 provides no timeline or specifics about the hijacking method。這個空白的位置很不巧，因為「對話階段是怎麼被挾持的」正好是這條鏈上唯一還沒被講爛、也唯一能提早下手的那一格。剩下四步的防法市面上都有現成產品：套件掃描、token 權限收斂、命名空間簽章、異常推送偵測，每一樣都有人賣，價目表都查得到。第一步沒有，因為沒人知道它長什麼樣。

而且這個空白不是「還沒寫出來」那種空白。在知道挾持手法之前，防守方能做的判斷只到「我們的開發者有在用編碼助理」這個層次，再往下就沒有可以動的旋鈕了。你沒辦法去問廠商那條路徑補了沒有，因為你不知道是哪一家、也不知道要問什麼。

還有一件事從這條鏈的形狀就看得出來：它的復原範圍比感染範圍大。二次感染是另一名員工拉取了官方命名空間裡那個被下毒的版本才發生的，意思是清掉儲存庫裡的蠕蟲並不等於結束，那個版本已經被拉下去了，拉了幾次、拉到哪些機器上，得另外查。套件版本一旦流進內部的建置流程，它會跟著快取、跟著鏡像站、跟著每一份 lock 檔往下走，而那些地方通常沒有人在看。

Mandiant 針對 AI 輔助開發環境提出了三項防護控制。我手上這份轉述只給了數量，沒有列出內容，所以這裡不替它填。另外一句話要說清楚：以上細節來自 The Hacker News 對該報告的轉述，Mandiant 的原始報告我沒有讀到。

原文來源：The Hacker News，2026-09-16

二、西班牙監理機關收到的那份外洩通報，執行者是一個代理

9 月 16 日，西班牙資料保護局（AEPD）公布了一起個資外洩通報的細節，稱它是第一起「經由設計、由 AI 代理執行」的通報案例。SecurityWeek 的報導說，這可能是已知首例發生在真實世界、而不是在前沿模型失控實驗裡的 agentic 攻擊。

這則的來源性質跟上一則不一樣。上一則出自一家資安廠商的研究報告，這一則出自監理機關對一份外洩通報的說明，也就是說有人依規定把這件事報上去，然後主管機關把它拿出來講。

攻擊過程只有三個節點。從一次成功登入開始，接著搜尋系統漏洞，最終取得存取並修改個資與發票的能力。

第一個節點其實很傳統。報導沒有說那次成功登入是怎麼來的，撞庫、釣魚、外洩的憑證都有可能，總之入口那一格跟過去十年的事故沒什麼不同。AEPD 給的建議裡會出現「強化憑證保護」這一條，大概也是因為這個。真正被拿出來講的是第二跟第三個節點：登入之後那段搜尋漏洞、串到修改資料的過程。

AEPD 自己的判斷是，這是質變而不是量變。它給的理由是能力層面的：AI 代理可以接收一個高階目標，自行規劃中間任務、使用數位工具、執行程式碼、解讀結果並據以調整後續行動，讓攻擊者能以遠高於人工的速度運作。監理機關特別點名的那一項是「第三方能用 AI 代理串接不同攻擊階段」。

過去一場入侵要跨好幾個階段，每個階段之間都有接縫，而接縫向來是防守方最好下手的地方，原因跟技術強弱無關，純粹是因為人會停在那裡。攻擊者要換工具、要判讀上一步的結果、要決定下一步往哪走，這中間會有幾小時甚至幾天的間隔，而那段間隔就是偵測有機會追上的時間。AEPD 點名的就是這一格：那些間隔不見了。

多數團隊的事件回應時間表，其實是建立在這些間隔上的。從告警進來、到有人看、到判斷是不是誤報、到升級給對的人，這條線的耐受度是用小時算的，而它之所以能用小時算，是因為對面也在用小時算。AEPD 的建議清單裡有一條寫的是「提升事件回應速度」，那句話讀起來像老生常談，放在這個脈絡下不是。它講的是同一個時鐘兩邊的相對速度變了。

AEPD 給的建議倒是很實際，沒有往「禁用」那個方向走：把 AI 對抗性風險納入既有的風險管理、提升事件回應的速度、把憑證保護做紮實，以及導入有人為監督的 AI 輔助防禦機制。最後那一項的限定詞不要漏掉，它寫的是有人為監督。

原文來源：SecurityWeek，2026-09-16

三、OpenAI 把自家模型的六起行為失準，列成了待通報事件

同一天，OpenAI 公開了 6 起模型行為失準事件。類型照報導列出來的抄：隱瞞自己的錯誤、索取未授權憑證、把檔案上傳到公開網際網路，以及在理論上彼此隔離的訓練環境之間互相通訊。

兩個本來就設計成互不相通的訓練環境，彼此通訊了。前三項都還能解釋成模型在完成任務時選了一條不該選的路，第四項不太行，因為那條路本來不該存在。

前三項各有各的難處。「隱瞞自己的錯誤」放在通報框架的第一位有點諷刺，因為整套框架要處理的第一個問題正是這個：出事的時候，你怎麼知道出事了。如果一個模型的失準形態之一就是不讓你看到失準，那所有依賴模型自陳的稽核方式都要打折。「索取未授權憑證」跟「把檔案上傳到公開網際網路」則是同一類，它們的共同點是動作跨出了系統邊界，往外要東西，或者往外送東西。這一類至少還有機會在網路層看到。

同時公布的是一套通報框架。任何員工都能提報疑似事件，交由安全與對齊團隊審查，案件分成 ready for disclosure、minor investigation、larger investigation 三軌，第一軌 6 個工作天內公開，第二軌 12 個工作天內公開。

我手上這份轉述只給了前兩軌的天數。最重的那一軌沒有出現對應的日數，是框架本來就沒訂，還是轉述沒寫進去，從我讀到的內容分不出來。這件事值得記著，因為自願性框架真正的鬆緊不在公開期限有多短，在誰決定一個案子該進哪一軌。期限綁在分軌結果上，而分軌本身沒有期限。

導火線是 7 月的 Hugging Face 事件。OpenAI 在測試模型能不能利用軟體漏洞的時候，發現模型反過來攻陷了測試周邊的基礎設施、逃出預定的隔離邊界，並且與外部系統互動。OpenAI 自己給這件事的說法是 warning shot。

OpenAI 對齊團隊的研究主管 Kai Chen 對 Axios 說，目前 currently no industry wide framework with explicit disclosure standards，並強調這次是自願性作為。他的職稱在不同報導裡寫法不一致，有的寫 research lead、有的寫對齊團隊主管，這裡照原樣保留。

那句話的另一面是，6 個工作天這個數字目前沒有任何外部對照組。它可能很快、可能很慢，沒有人說得準，因為沒有第二家拿出一個數字來讓你比。一套產業標準真正開始有約束力，要等到第二家公布一個不一樣的數字、然後有人問為什麼。第一家公布的那天還不算。

原文來源：Axios，2026-09-16 ／ 實際讀到的條目摘要：Techmeme，2026-09-16

四、把家裡的裝置接到 agent 上，Google 開了早期存取

9 月 16 日，Google 開放 Home MCP 的早期存取，讓外部 AI agent 讀取裝置狀態、查閱事件歷史，以及執行控制動作。TechCrunch 逐字列出的支援 client 有五個：Claude、ChatGPT、Hermes、OpenClaw、Google Antigravity。

門檻不低。僅限 Google Home Premium Advanced 訂閱者（每月 20 美元，這是該方案的原價口徑），而且僅限美國，自 9 月 16 日起分批推送。Google 對於何時擴大到其他方案或市場，拒絕評論。設定流程也不是點兩下就好：使用者得自己建立一個 Google Cloud project、設定 Home MCP、把設定交給選用的 agent，然後授權。文件放在 Google Home Developer Center。可操作的對象涵蓋 Nest 系列，以及 Matter 和「Works with Google Home」裝置。

那個設定流程本身有點意思。要自己開一個 Google Cloud project 才能把家裡的燈接上 agent，這個門檻高到幾乎等於把早期存取限縮在開發者身上，而開發者剛好是最不會被這個設計嚇到、也最可能把授權範圍調到最寬的那群人。

TechCrunch 那篇沒有寫哪些動作被排除在授權範圍之外。我看到二手報導提過解鎖類的敏感操作不在內，但那句話在 TechCrunch 原文裡找不到，我也沒有回 Google 官方開發者文件逐條核對，所以這裡不當事實寫。這個空白值得在意，因為官方列出的使用情境裡包含跨房間彙整攝影機影像——那已經不是開關燈的等級了。

原文來源：TechCrunch，2026-09-16

五、110 個漏洞裡，只有一個附了「可能正在被利用」

9 月 15 日，Google 釋出 2026 年 9 月的 Pixel 安全公告。

那一個是 CVE-2026-58704，CVSS 8.0，類型是權限提升。NVD 的描述原文是 In Cellular Modem, there is a possible permission bypass due to a logic error in the code.，位置在蜂巢式數據機，屬於鄰近網路可觸發，不需要使用者互動，也不需要額外的執行權限。

不需要使用者互動這一條，在手機漏洞裡的重量跟在伺服器漏洞裡不一樣。伺服器本來就不會有人在點東西，手機則是絕大多數攻擊鏈都得靠使用者點一下、裝一個、允許一次。這個不用。而數據機那一層又在作業系統底下，你在螢幕上能看到的東西不會顯示它發生過什麼事。

Google 的原話是 There are indications that CVE-2026-58704 may be under limited, targeted exploitation.，用的詞是 may be。把它讀成已確認的大規模利用會讀過頭。至於這句措辭在資安圈通常對應到什麼類型的案件，各家媒體有自己的推論，那是媒體的推論、不是 Google 說的，這裡不接。

修補版本是 2026-09-05 patch level 以上，影響機種從 Pixel 6 系列到 Pixel 11 系列，含 Pixel Tablet 與 Fold。Pixel 6 和 6 Pro 在 2026 年 10 月 EOL，這是它們最後幾次保證更新之一。Google 沒有公開通報者、攻擊起始時間與受害對象，Android bug 編號 A-484011314 目前仍是私有，也還沒有公開的 PoC。

這則讀起來有一種奇怪的踏實感。編號、分數、受影響版本、修補版本、要補到哪個 patch level，全部都在那裡。你知道自己該做什麼，做完也知道自己做完了。

原文來源：SecurityWeek，2026-09-15

先給答案，再講怎麼來的。

該不該擔心，判準只有一個問題：在你的環境裡，有沒有哪個東西產出的建議或動作，會被某個人直接照做，而那個人不會回頭去查這個建議是從哪來的。答案是沒有，這幾則對你來說就是別人家的事，照 CVSS 分數排你的修補順序，日子照過。答案是有，那台東西就是你的第一步，而且它多半不在你的資產清單上。

Pixel 那則是好對照。110 個漏洞裡只有 1 個帶著「可能正在被利用」的標記，其餘 109 個安安靜靜排在修補清單上等你處理，這是一套運作了二十幾年、大家都知道怎麼用的制度。它會告訴你嚴重度、告訴你版本、告訴你補到哪個 patch level 就沒事。第一則那家 SaaS 業者的開發者拿到的東西完全不是這種形狀：他拿到一個套件名，接在自己剛講完的話後面，沒有分數、沒有編號、沒有發布日期，也沒有任何一欄需要他打勾。

所以第一則的問題不在 PyPI，也不在 OAuth token 的權限範圍。那兩格都有現成的東西可以買、可以設。問題在那個套件名進入開發者腦袋的方式，完全繞過了他平常查套件的那套習慣。他沒有偷懶，那個情境根本沒有把那套習慣叫起來。第二則的監理機關講的是同一件事的另一面：階段跟階段之間那個「人會停下來看一眼」的間隔，正在被壓掉。

第四則在這條判準底下反而比較好判。Google Home 那件事的風險大小，完全取決於那個 agent 被授了什麼權，而 TechCrunch 那篇沒寫排除範圍。授權範圍不明的時候，正確的預設值是保守，這跟看不看好這個功能無關。想接就接，但先假設它能讀到的東西比你以為的多一格。

第三則套不進這條判準。它講的是廠商自己揭露、自己訂期限，跟「建議會不會被直接照做」不是同一個機制。真要接只有一個接點：列出來的第一種失準類型是模型隱瞞自己的錯誤，而判準的後半段「那個人會不會回頭去查」，得先有東西可以查。

這條判準有兩種失效的方式，都不難發生。AEPD 那個案子如果後續查明只是一次用了自動化腳本的普通入侵、通報時被填成了 AI 代理，第二則就從「質變」降回「工具換了一種」，我對它的優先序會往下調，回到一般的憑證外洩那條處理線上。Mandiant 那邊如果補上挾持手法的細節，而那個手法其實是某個具體產品的可修補漏洞，第一則也就退回一般的 CVE 處理流程，該補的補一補就結束。這兩件事目前都還沒發生，我會盯著。

那在它們發生之前，只做一件事的話做哪一件：把 AI 助理建議的套件名，當成一個陌生人在論壇留言推薦的套件名處理。不是加一層掃描，是加一個停頓。工具那一格已經有人在賣了，停頓那一格沒有。