AI 基礎設施成為實際攻擊目標：Ray 與 MLflow 遭利用，同期 vCenter 路徑穿越被用來投放勒索軟體AI infrastructure moves from theory to target: Ray and MLflow exploited, while a vCenter path traversal delivers ransomware

vCenter 存在一個目錄穿越漏洞（CVSS 9.8），具備網路存取權限的攻擊者可藉此執行任意程式碼。QUIRSO 於 8 月 12 日回報已出現實際利用，攻擊者藉此取得持續性的遠端存取。

數日後，研究人員將這波利用歸因於疑似中國背景的 APT，並指出攻擊行動中部署了源自 Babuk 的勒索軟體。CISA 已於 8 月 18 日將此漏洞列入 KEV 目錄。修補程式在遭利用之前就已釋出——也就是說，中招的環境是尚未套用更新的那些。

vCenter contains a directory traversal flaw (CVSS 9.8) that lets an attacker with network access to vCenter execute arbitrary code. QUIRSO reported active exploitation on 12 August, with attackers using it to establish persistent remote access.

Days later researchers attributed the activity to a suspected China-nexus APT and reported that the intrusions deployed ransomware derived from Babuk. CISA added the flaw to the KEV catalog on 18 August. Patches were available before exploitation began — meaning the environments being hit are the ones that had not applied them.

路徑穿越之所以能升級成任意程式碼執行，關鍵在於它可以寫入而不只是讀取：把檔案放到會被執行的位置，就等同取得執行權。

而 vCenter 這個目標特別有價值——它是整座虛擬化環境的管理平面。拿下 vCenter 等於同時掌握其下所有虛擬機，勒索軟體集團因此偏好這條路徑：不需要逐台植入，直接在 hypervisor 層加密即可癱瘓整個機房。這與本站先前報導的 RMM 平台攻擊是同一種思維——打管理平面，不打個別端點。

A path traversal escalates to arbitrary code execution when it can write rather than only read: place a file where something will execute it and you have execution.

vCenter is a particularly valuable target because it is the management plane for an entire virtualisation estate. Owning vCenter means owning every virtual machine beneath it, which is why ransomware crews favour this path — no need to plant anything host by host when encrypting at the hypervisor layer takes down the whole room. It is the same logic as the RMM platform attacks this site covered earlier: go after the management plane, not individual endpoints.

所有執行未修補 vCenter 的組織。因為影響的是整個虛擬化平台，這一則的潛在損失規模通常是本期最大的——不只是資料外洩，而是營運中斷。

Any organisation running an unpatched vCenter. Because the entire virtualisation platform is at stake, the potential loss here is usually the largest in this issue — not just data exposure but operational shutdown.

1. 立即套用 Broadcom 的修補程式。這是本期優先序最高的一項。
2. 確認 vCenter 管理介面沒有對網際網路開放，並限制在管理網段或 VPN 之後。管理平面不該從任何地方都連得到。
3. 進行入侵跡證盤查：非預期的檔案寫入、新增的帳號、排程工作、對外連線；vCenter 的日誌與 ESXi 主機的日誌都要看。
4. 確認備份是離線或不可變的，且未透過同一套虛擬化環境掛載——勒索軟體攻擊 hypervisor 的目的之一就是同時毀掉備份。
5. 輪換 vCenter 上的所有憑證與服務帳號。

1. Apply Broadcom's patch now. This is the highest priority item in this issue.
2. Confirm the vCenter console is not reachable from the internet, and restrict it to a management segment or behind VPN. A management plane should not be reachable from anywhere.
3. Hunt for compromise: unexpected file writes, new accounts, scheduled tasks, outbound connections — review both vCenter logs and ESXi host logs.
4. Verify backups are offline or immutable and not mounted through the same virtualisation estate — destroying backups is part of why ransomware targets the hypervisor.
5. Rotate all vCenter credentials and service accounts.

在 vCenter 上尋找非預期的檔案寫入，特別是寫入到會被服務載入或執行的目錄。網路層可觀察管理介面出現來自非管理網段的存取——正常情況下這類連線應該極少且來源固定。

Look for unexpected file writes on vCenter, especially into directories a service loads or executes from. At the network layer, watch for console access originating outside your management segment — legitimate connections here should be few and from fixed sources.

CISA 於 8 月 17 日將 Ray 的一個重大漏洞列入 KEV，指出已有實際遭利用的證據。Ray 是開源的 Python 分散式運算框架，用於擴展 AI 與機器學習工作負載。

這個漏洞屬於程式碼注入，可導致遠端程式碼執行。值得注意的是它的觸發途徑：把 Ray 當作開發工具使用的人，可能透過 Firefox 與 Safari 被利用——也就是說，開發者只是在瀏覽器裡開了某個頁面，就可能讓本機的 Ray 執行攻擊者的程式碼。

CISA added a critical Ray flaw to the KEV catalog on 17 August, citing evidence of active exploitation. Ray is an open-source, Python-native distributed computing framework used to scale AI and machine learning workloads.

The flaw is a code injection that can lead to remote code execution. The delivery path is what stands out: developers using Ray as a development tool may be exploited through Firefox and Safari — meaning a developer merely opening a page in their browser could cause their local Ray to run an attacker's code.

這一則點出 AI／ML 工具鏈一個普遍的設計預設：這些框架多半假設自己跑在受信任的內部網路裡，因此預設不啟用驗證，也對來源檢查寬鬆。這在資料中心的封閉叢集裡說得通，但實際使用情境早已不是如此——開發者在自己的筆電上跑、在雲端 VM 上跑、在共用的實驗環境上跑。

瀏覽器可觸發這一點尤其麻煩：它把攻擊面從「誰連得到這個服務」擴大成「這個人瀏覽了什麼」。開發者的機器上通常還放著雲端憑證、原始碼與生產環境存取權，價值不低。

This one exposes a design assumption common across AI/ML tooling: these frameworks generally assume they run on a trusted internal network, so authentication is off by default and origin checks are lax. That made sense for a closed cluster in a data centre, but it is not how they are actually used today — developers run them on laptops, on cloud VMs, on shared experiment environments.

Browser-triggerability makes it worse, expanding the attack surface from "who can reach this service" to "what did this person browse". And a developer's machine typically also holds cloud credentials, source code, and production access.

使用 Ray 的資料科學與 ML 工程團隊，包含本機開發環境，不只是叢集部署。如果你的團隊在筆電上跑 Ray 做實驗，那些機器也在範圍內。

Data science and ML engineering teams using Ray — including local development environments, not only cluster deployments. If your team runs Ray on laptops for experiments, those machines are in scope.

1. 升級 Ray 至已修補版本，開發機與叢集都要處理。
2. 盤點環境中所有 Ray 執行個體，包含個人開發機。這類工具常在無人核准的情況下被裝起來。
3. 確認 Ray 的儀表板與 API 沒有對外開放，並綁定到 localhost 或受限的內部位址。
4. 若曾對外暴露，假設已遭入侵：檢查該主機上的雲端憑證是否需要輪換、有無非預期的程序與排程。
5. 檢視使用 Ray 的工作負載其服務帳號權限，依最小權限收斂。

1. Upgrade Ray to a fixed release on both development machines and clusters.
2. Inventory every Ray instance in your environment, including personal development machines — this class of tool is often installed without approval.
3. Confirm the Ray dashboard and API are not internet-facing, binding them to localhost or a restricted internal address.
4. If it was ever exposed, assume compromise: check whether cloud credentials on that host need rotating and look for unexpected processes and scheduled tasks.
5. Review the service account permissions of Ray workloads and reduce to least privilege.

CVE-2026-55040（CVSS 9.1）是一個源自弱驗證的重大安全功能繞過，未經授權的攻擊者可藉此在網路上繞過安全機制。微軟已於 2026 年 7 月的例行更新中修補。

關鍵在時間軸：漏洞修補後一段時間，概念驗證程式碼公開，攻擊行動隨即出現。CISA 於 8 月 18 日將其列入 KEV。這是「修補已存在但尚未套用」的又一個案例。

CVE-2026-55040 (CVSS 9.1) is a critical security feature bypass stemming from weak authentication, letting an unauthorised attacker bypass a security feature over a network. Microsoft patched it in the July 2026 Patch Tuesday updates.

The timeline is the point: some time after the patch, proof-of-concept code became public, and exploitation followed immediately. CISA added it to KEV on 18 August. Another case of "the patch existed and had not been applied".

PoC 公開到大規模利用的間隔正在縮短，如今經常以小時計。這改變了修補排程的算術：過去可以把修補排進下個維護窗口，現在對於「已修補但 PoC 可能公開」的重大漏洞，等待期本身就是風險。

同期還有一個相關趨勢值得留意：研究人員揭露了名為 TWINLOOT 的 Python 植入框架，它把整套 C2 基礎設施建立在受信任的微軟服務之內——指令透過 SharePoint Online 檔案傳遞，並利用 Teams 進行活動。這類手法讓惡意流量與正常的企業協作流量難以區分，因為它連的確實是合法的服務網域。

The gap between public PoC and mass exploitation keeps shrinking, now often measured in hours. That changes the arithmetic of patch scheduling: where a fix could once wait for the next maintenance window, for critical flaws with a plausible PoC the waiting period is itself the risk.

A related trend from the same period is worth noting: researchers disclosed a Python implant framework called TWINLOOT that runs its entire C2 infrastructure inside trusted Microsoft services — tasking flows through SharePoint Online files, with Teams used for activity. Approaches like this make malicious traffic hard to separate from normal corporate collaboration, because the destinations genuinely are legitimate service domains.

執行地端 SharePoint 且未套用 7 月更新的組織。SharePoint 通常存放大量內部文件，一旦被存取，資料外洩的範圍往往很廣。

Organisations running on-premises SharePoint without the July updates. SharePoint typically holds a large volume of internal documents, so access tends to mean broad data exposure.

1. 確認 2026 年 7 月的 SharePoint 更新已套用。若尚未，這是本期第二優先。
2. 檢視 SharePoint 的存取紀錄，尋找未經驗證或異常來源的存取。
3. 針對 TWINLOOT 這類手法調整偵測思路：不要只看「連到可疑網域」，要看「對合法服務的存取模式是否異常」——例如非人類作息的規律存取、單一帳號對大量檔案的存取。
4. 盤點對外開放的 SharePoint 執行個體，評估是否有必要開放。

1. Confirm the July 2026 SharePoint updates are applied. If not, this is the second priority in this issue.
2. Review SharePoint access logs for unauthenticated or anomalous sources.
3. Adjust detection thinking for TWINLOOT-style tradecraft: do not only look for connections to suspicious domains — look for anomalous patterns of access to legitimate services, such as machine-regular timing or one account touching an unusual volume of files.
4. Inventory internet-facing SharePoint instances and assess whether that exposure is necessary.

C2 藏在合法 SaaS 服務中時，網域封鎖無效。改看行為特徵：固定間隔的存取（人類不會每 47 秒開一次檔案）、非上班時段的持續活動、以及服務主體或帳號的存取範圍突然擴大。

When C2 hides inside legitimate SaaS, domain blocking does nothing. Look at behaviour instead: fixed-interval access (humans do not open a file every 47 seconds), sustained activity outside working hours, and a service principal or account whose access scope suddenly widens.

CVE-2026-65400（CVSS 9.8）是螢幕共享元件的驗證缺陷，位於網路上的攻擊者無需有效憑證即可通過驗證。荷蘭國家網路安全中心（NCSC-NL）警告該漏洞已遭實際利用，攻擊者藉此在對外暴露的 Mac 上部署 Monero 挖礦程式。CISA 亦於 8 月 18 日將其列入 KEV。

Apple 隨後在 8 月 17 日釋出 iOS／iPadOS 與 macOS 的更新，一次修補 108 個漏洞——這批更新距離先前那次只修螢幕共享單一漏洞的小型更新約兩週。

CVE-2026-65400 (CVSS 9.8) is an authentication flaw in the Screen Sharing component that lets an attacker on the network authenticate without valid credentials. The Netherlands National Cyber Security Centre (NCSC-NL) warned it is being exploited in the wild to deploy a Monero miner on internet-exposed Macs. CISA added it to KEV on 18 August.

Apple then shipped iOS/iPadOS and macOS updates on 17 August fixing 108 vulnerabilities — roughly two weeks after the much smaller update that addressed the single screen-sharing flaw.

挖礦程式看起來是相對輕微的後果——沒有加密檔案、沒有竊取資料，只是電費變貴、機器變慢。但這是錯誤的解讀方式：能安裝挖礦程式，就能安裝任何東西。挖礦只是攻擊者當下選擇的變現方式，同一條路徑也能用來投放竊資木馬或勒索軟體。

真正值得檢討的是為什麼會有 Mac 把螢幕共享服務直接暴露在網際網路上。這通常源於遠端工作時期的臨時設定、或是誤以為「開了但沒人知道位址」等於安全。

A cryptocurrency miner looks like a mild outcome — nothing encrypted, nothing stolen, just a higher power bill and a slower machine. That reading is wrong: whoever can install a miner can install anything. Mining is simply how this attacker chose to monetise; the same path delivers infostealers or ransomware just as well.

The question worth asking is why a Mac had Screen Sharing exposed to the internet at all. Usually it traces back to a temporary remote-work arrangement, or an assumption that "it is open but nobody knows the address" amounts to safety.

任何啟用螢幕共享且可從網際網路存取的 Mac。企業環境中的開發者機器與家用 Mac 都在範圍內。

Any Mac with Screen Sharing enabled and reachable from the internet — developer machines in corporate environments and home Macs alike.

1. 套用 8 月 17 日的 macOS 更新（含前述 108 項修補）。
2. 關閉不需要的螢幕共享：系統設定 → 一般 → 共享，確認螢幕共享為關閉。這是最快也最有效的一步。
3. 確認沒有任何 Mac 的螢幕共享埠對外開放。需要遠端存取時走 VPN，不要直接暴露服務。
4. 若曾對外暴露，檢查是否有非預期的高 CPU 程序、登入項目與背景服務。
5. 檢視路由器上的埠轉發設定——這類暴露常源於幾年前設定後就忘記的規則。

1. Apply the 17 August macOS update (which carries the 108 fixes noted above).
2. Turn Screen Sharing off where it is not needed: System Settings → General → Sharing. Fastest and most effective step.
3. Confirm no Mac has its screen sharing port exposed to the internet. Where remote access is needed, use a VPN rather than publishing the service.
4. If it was exposed, check for unexpected high-CPU processes, login items, and background services.
5. Review port forwarding rules on your router — this kind of exposure often comes from a rule set years ago and forgotten.

GitLab 於 8 月 17 日發布重大修補更新，處理兩個 GraphQL 弱點 CVE-2026-19478 與 CVE-2026-19650。其中較嚴重的 CVE-2026-19478 經 GitLab 評為 Critical、CVSS 9.4——在特定條件下，未經驗證的攻擊者可遠端修改或刪除公開專案與使用者資料。

這次更新距離上一批 13 個漏洞的修補僅一週。

GitLab shipped a critical patch release on 17 August addressing two GraphQL weaknesses, CVE-2026-19478 and CVE-2026-19650. The more serious, CVE-2026-19478, is rated Critical by GitLab at CVSS 9.4 — under certain conditions an unauthenticated attacker can remotely modify or delete public projects and user data.

It came just a week after the previous batch of 13 fixes.

這一則的特別之處在於破壞性。多數漏洞的後果是機密性受損（資料被看到），這個則直接影響完整性與可用性——專案內容可被竄改或刪除。

對開發組織而言有兩層風險。明顯的一層是程式碼與歷史被刪除；比較隱蔽的一層是竄改：若攻擊者能修改專案內容而未被察覺，那是供應鏈攻擊的理想起點。你的 CI 會忠實地建置並發布被動過手腳的程式碼。

What sets this one apart is its destructiveness. Most vulnerabilities cost you confidentiality — data gets seen. This one goes at integrity and availability: project content can be altered or deleted.

For a development organisation that carries two layers of risk. The obvious one is losing code and history. The subtler one is tampering: an attacker who can modify project content without detection has an ideal starting point for a supply chain attack, and your CI will faithfully build and publish the altered code.

自架 GitLab（CE 或 EE）的組織，特別是有公開專案者。

Organisations self-hosting GitLab (CE or EE), particularly those with public projects.

1. 立即套用 8 月 17 日的重大修補更新。
2. 確認你的 Git 儲存庫有獨立於 GitLab 之外的備份——若備份只存在同一套系統裡，破壞性漏洞會一併帶走它。
3. 檢視公開專案近期的異常變更：非預期的 force push、標籤異動、成員權限變更。
4. 若有簽章提交（signed commits）的機制，這是驗證內容未遭竄改的最可靠方式；尚未導入的話值得評估。

1. Apply the 17 August critical patch release now.
2. Confirm your Git repositories have backups independent of GitLab — a destructive flaw takes the backup with it when both live in the same system.
3. Review public projects for recent anomalies: unexpected force pushes, tag changes, membership changes.
4. If you have signed commits, that is the most reliable way to verify content has not been tampered with; if not, it is worth evaluating.