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

9 月 14 日，adminmenueditor.com 上架了 Admin Menu Editor Pro 2.35。外掛的開發者 Janis Elsts 沒有放這一版上去。

那一版裡多了一個檔案，includes/wp-user-consent.php，會在裝上它的網站放一個 web shell，再建一個看不見的管理員帳號。Elsts 發現之後把它移掉，同一天 19:00 UTC 推出乾淨的 2.36。

攻擊者當時還在那台主機上。2.36 也被下毒了。

一、乾淨的那一版，跟髒的那一版來自同一台主機

BleepingComputer 9 月 15 日報導了這件事，攻擊發生在前一天。惡意的 2.35 掛在網站上的時間，報導寫的是當天 06:00 UTC 到 13:00 UTC，大約七個小時。影響範圍照原文是「至少 230 名客戶、約 1,500 個網站」，這兩個數字量的不是同一件事，一個客戶手上通常不只一個站，別把 1,500 讀成 1,500 家公司。

範圍也要界定。被入侵的是付費 Pro 版的散布基礎設施，不是 WordPress.org 上那個免費版（逾 30 萬次啟用安裝）本身出了漏洞。Patchstack 的漏洞紀錄把 2.35 與 2.36 分別列為含後門的版本，2.34 則是「研判乾淨」。廠商後來把主站整個下線調查，研判攻擊者取得的是主機環境的 root 級存取。研判，不是證實。

這個界定順手講出了一件平常沒人會去想的事。免費版由 WordPress.org 託管與散布，付費版沒有經過那一層，它的來源就是開發者自己那台主機。所以這次被打穿的，是兩條路裡面比較短、也比較沒人盯的那一條，而它偏偏是付了錢的人在走。這句話報導沒有寫，是我看完範圍界定之後自己接的。

要自己查的話，報導給的 IoC 有四個落點：admin-menu-editor-pro 目錄下的 includes/wp-user-consent.php、新出現的 /wp-content/object-cache/ 目錄、wp_users 表裡以 wp_ 開頭的隱藏使用者，還有 wp_options 中名為 wp_ocache* 的選項。建議的處置是從 9 月 14 日之前的備份還原。

最後那句建議值得停一下。它實際上在說：那幾天之內，更新這個外掛這個動作本身是有害的。

更新機制的設計前提只有一條，發補丁的那一端是乾淨的。簽章、版本比對、自動更新，驗的全都是「這包東西有沒有在路上被換掉」，沒有一項在驗「上游那台機器現在歸誰管」。9 月 14 日晚上收到通知、立刻按下更新的站長，做的是每一份資安指南都會叫他做的事，換到的是第二個後門。

而且注意版本號的方向。2.36 比 2.35 新，比 2.34 也新。任何一套「檢查是不是最新版」的自動化，跑出來的結論都會是 2.36 通過、2.34 不通過。防線在這裡整個反過來運作：越勤快的人越容易中，落後兩版沒空更新的那些人反而沒事。

那七個小時裡中了多少，報導沒有拆開講，畢竟 2.36 也是髒的、而且掛得比 2.35 久。但七小時這個窗口本身就夠說明一件事：這條管道從推出新版到客戶真的裝上，反應時間是以小時計的。修補速度平常被當成防禦力的指標，在這一則裡它是傷害的放大倍率。

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

二、9 月 15 日那天，vCenter 那個洞只多了一個標籤

CVE-2026-59310，CVSS 9.8，vCenter 的 Syslog 伺服器有一個目錄遍歷漏洞，未經驗證的攻擊者可以藉此執行任意程式碼。Broadcom 在 2026 年 7 月 29 日就修好了，而且在補充的 FAQ 裡要求客戶以緊急事件處理。

9 月 15 日 CISA 確認的是這個：勒索軟體集團已經加入原本就在利用這個漏洞的攻擊者行列。KEV 目錄的標記是在週末更新的，標成「遭勒索軟體濫用」。

先前的攻擊活動有數字，但要帶著它的來源走。DFIR 廠商 QUIRSO 在修補後兩週的觀測是：47 個國家、361 個以上的 IP 遭入侵，疑似某個 China-nexus APT 利用這個漏洞部署 reverse SSH 工具維持長期存取，至少一起案例最終部署了 Babuk 衍生的勒索軟體。感染集中在德國 55、美國 41、土耳其 38、伊朗 26、法國 25。這是一家廠商在 8 月看到的東西，不是 9 月的現況，「疑似」那兩個字也不要順手拿掉。

目前 Shadowserver 追蹤到 450 台以上對外暴露的 vCenter，其中有多少已經修補，沒有人知道。

從 7 月 29 日的補丁到 9 月 15 日，中間隔了 48 天，這個漏洞在這段時間裡換過一批使用者。第一批是想長期待著的，第二批是想馬上換現金的。

對防守方來說，這個轉換改掉的是被發現的方式。想長期待著的那批會盡量安靜，你可能整季都不會知道他在；勒索軟體不安靜，它進來就是要讓你看到。所以同一台沒補的 vCenter，在 8 月跟在 9 月的意義不一樣：8 月你需要去翻 log 才找得到問題，9 月它會自己來敲門。這一層 CISA 沒有講，是我從那個標記的性質往下讀的。

原文來源：Cyber Security News，2026-09-15

三、日本數位廳外洩的那個漏洞，是中等嚴重度

日本數位廳在 9 月 11 日對外公開，政府共用 IT 平台 GSS（Government Solution Service）所用的 VPN 裝置被人利用漏洞入侵，可能外洩約 246,000 筆個資紀錄，涉及 23 個部會。BleepingComputer 在 9 月 14 日報導。

拆分是這樣：約 189,000 筆是 GSS 使用機關的員工與相關公務人員，約 57,000 筆是往來廠商與個人。裡頭含約 236,000 個姓名、231,000 個 email、94,000 個電話號碼，以及約 1,000 筆實體地址。My Number、金融機構帳戶資訊與年金號碼未受影響。目前沒有發現確認的濫用事證，數位廳警告的是釣魚與冒名。

時間線照報導攤開。6 月 25 日偵測到維運人員帳號有大規模檔案存取，啟動調查；7 月 9 日查出是第三方利用 VPN 漏洞入侵，當天就停用該帳號、切斷對外連線、修補漏洞並輪換金鑰憑證；7 月 15 日通報個人情報保護委員會；9 月 11 日才對外公開。自偵測起 78 天，自查明入侵手法起 63 天。

最先響的是什麼，值得看一眼。VPN 那一側沒有發出告警。先被看到的是有個維運人員帳號在大量存取檔案。攻擊者進來之後用的是一個本來就該存在、本來就該有廣泛讀取權限的帳號，所以能被抓到的只剩下量：這個帳號今天拿的東西，比它平常拿的多太多。從 6 月 25 日看到這個異常，到 7 月 9 日搞清楚人是從 VPN 進來的，中間隔了兩個禮拜。這兩個禮拜量的是另一件事，看見有人在裡面，跟知道他從哪扇門進來，是兩個不同的問題，而且後者難得多。

然後是這則最該記住的那一句：那個 VPN 漏洞被數位廳自己評為 medium severity，而且明確不是 0-day。攻擊發生的時候，修補程式早就存在了。

回到那 78 天。這個數字很容易被讀成「這個單位動作太慢」，但它量的是揭露速度，不是修補速度。修補在 7 月 9 日當天就做完了，帳號停用、對外連線切斷、金鑰憑證輪換，全部在同一天。真正卡住的是更前面那一段：一個中等嚴重度、補丁早就發了的漏洞，在一個 23 個部會共用的平台上，活到有人走進來為止。這句是我的讀法，報導沒有下這個判斷。

中等嚴重度的東西排在待辦清單的哪個位置，每個維運團隊自己心裡有數。

原文來源：Security Affairs，2026-09-15

四、Gemini 3.8 Live 的分數，是自己量的

同一天 9 月 15 日，Google 官方部落格發表兩款原生 speech-to-speech 模型，掛名的是 Tom Ouyang（Principal Engineer）與 Malini Jaganathan（Member of Technical Staff）。定位很清楚：取代 ASR → LLM → TTS 那條串接式管線。Gemini 3.8 Live 主打規模與成本效率，Gemini 3.8 Live Extended Thinking 主打高複雜度任務、邊講邊做多步推理。

語言支援 97 種，可以自動偵測語言並在對話中途切換。兩款產生的所有音訊都嵌了 SynthID 浮水印。

官方列出的分數是這幾個，口徑是 Extended Thinking 版本：

標準版 3.8 Live 在 Speech Agent Arena 拿第二名。

這幾個放在一起才有意思。97.7% 跟 35.1% 是同一篇發布文裡的兩個極端，而低的那個是銀行場景的 agentic 任務——白話講就是「要真的動到別人帳戶的那條流程裡，它把事情做對的比例」。只挑 97.7% 寫，跟只挑 35.1% 寫，會得到兩篇立場完全相反的文章。

而且兩個測項量的東西差很遠。推理那一項問的是它懂不懂；銀行那一項問的是它照著做的時候，一連串步驟有沒有全部走對。廠商願意把 35.1% 跟 97.7% 印在同一張表上，這件事本身算誠實，但看的人要自己把它們分開讀。要判斷這東西能不能接進自己的客服或語音流程，看的是低的那個。

還有兩件事要講在前面。全部的分數都是廠商自報，沒有第三方復現。價格沒有出現在官方部落格，二手報導有寫每分鐘多少錢，我沒辦法從官方頁面證實，所以這篇不寫。

原文來源：Google Blog，2026-09-15

五、三家在談的，是一個可以叫全產業慢下來的機構

OpenAI 全球政策長 Chris Lehane 在 9 月 15 日公開證實，OpenAI 已經跟 Anthropic 與 Google DeepMind 就 AI 安全合作了數週。這件事是多家媒體先後報導的，誰最先寫出來各家說法不一致，所以我不指名首報者。

「數週」這個詞要留意。這件事不是 9 月 15 日談起來的，是談了好幾個禮拜之後，才在 9 月 15 日被一位高階主管在公開場合證實。中間那段時間有沒有結論、談到哪裡，外面看不到。這是自律案最一致的形狀：過程不公開，公開的是已經談完的那部分。

構想的源頭是 Google DeepMind 的 Demis Hassabis。他提議成立「a new standards body」，功能接近一個 AI 監理看門狗：有權在部署前檢驗先進模型，並在風險浮現時協調全產業放慢速度。

政治那一端在往反方向拉。川普公開把安全疑慮斥為騙局（hoax）、反對更嚴格的監管，理由是放慢速度會讓中國佔便宜；他的 AI 顧問 David Sacks 說，AI 帶來生存風險的恐懼被誇大了。

真正卡住的是另一頭。包含 Sam Altman 在內的一些人指出，這種協調如果被認定為壓抑競爭，可能觸犯反托拉斯法。Lehane 的回應是，這些公司不需要政府豁免就能繼續做安全合作。

這個結繞起來長這樣：往政府那邊走，執政方已經把前提否掉了；往產業自己走，協調本身可能違法。

剩下能做的，就是一個沒有法源、沒有豁免、成員自己說要加入的組織。

反托拉斯那一條還有個更難的地方。這種機構要有用，就得管得到所有人，而且管出來的結果要一致；一群競爭者坐下來，就某件事達成一致的步調，這在法律上長得就像聯合行為。它越有效，形狀越接近被禁止的那個東西；把它稀釋到絕對安全，剩下的大概就是一份共同聲明。有效性跟合法性在這題上共用同一條軸，往其中一端多走一步，就是往另一端退一步。這段沒有來源可以引，是我自己看著那兩句話推的。

我的看法是它不會以「有權在部署前擋下一個模型」的形式成立。這不是動機問題，我相信談的人是認真的。問題在權力來源：這個機構的每一項權限，都是被檢驗的那一方自己讓渡的，而讓渡出去的東西隨時可以收回來。它的實際權力上限，等於三家裡面最不情願的那一家的耐心。

什麼情況下我會改口。如果出現一份三方都簽字、寫明退出要提前多久通知、退出之後已交出的評估資料怎麼處理的文件；或者任何一家因為沒有依約定送檢而付出看得見的代價。目前這兩樣都還沒有。

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

把這幾則按「誰有得選」重排一次，順序有點刺眼。

先把套不上的挑出去。則四收不進來，它是一份廠商自報的發布稿，跟「補丁到不到得了人」沒有機制上的關係，今天並排的理由只有日期。

那個站長沒得選。他在 9 月 14 日打開後台，看到有新版本、按了更新。日本那 23 個部會也沒得選，一個中等嚴重度的補丁排在待辦清單的哪一格，通常不是後來被入侵的那個單位在決定。那 450 台對外暴露的 vCenter 裡，有多少已經補過，連 Shadowserver 都答不出來。

這三則還有一個共同點，比「誰有得選」更難看。修補程式在三則裡都存在。vCenter 的補丁 7 月 29 日就發了，日本那個漏洞被自己評為中等嚴重度、而且明確不是 0-day，補丁同樣早就有；外掛那則走到最極端，補丁本人就是毒。也就是說，「原廠已經修好了」這句話在這三件事裡全部成立，而它一個人都沒保護到。我們平常拿來衡量風險的那個欄位是「有沒有補丁」，這三則量出來的是另一個欄位：補丁跟你之間隔著誰。

則五放在這裡是對照組。同一週在談「要不要有一個機構可以叫大家慢下來」的那三家，每一家都有得選。要不要加入、加入到什麼程度、什麼時候退出，全部是自己決定的。而 Hassabis 那個構想裡最核心的權力，是在部署之前擋下一個模型，那正是前面三則裡沒有任何一方擁有過的東西。

回到那個外掛。廠商的主站還在下線調查，報導裡 2.34 是「研判乾淨」，研判。下一版遲早要推出來，而它要怎麼證明自己是乾淨的，到現在沒有人給過答案。同一台主機、同一個發布管道，已經送出過兩次帶後門的版本。第三次要拿什麼來說服人，是這件事真正還沒結束的部分。