邊界設備與開發工具鏈同期失守，攻擊自動化跨過門檻：本期合併四週，44 則漏洞列入 KEVEdge devices and developer toolchains breached in the same window, as attack automation crosses a threshold: four weeks merged, 44 additions to KEV

Cisco 警告 Secure Email Gateway 的 AsyncOS 軟體存在重大漏洞並已遭實際利用。編號 CVE-2026-76461，CVSS 9.8，成因是郵件解析邏輯的驗證不足，未經驗證的遠端攻擊者可藉此在底層作業系統上以 root 權限執行任意指令。CISA 於 9 月 14 日將其列入 KEV。

Cisco warned that a critical flaw in AsyncOS Software for Cisco Secure Email Gateway is under active exploitation. Tracked as CVE-2026-76461 with a CVSS score of 9.8, it stems from insufficient validation in the email parsing logic, allowing an unauthenticated remote attacker to execute arbitrary commands with root privileges on the underlying operating system. CISA added it to KEV on 14 September.

漏洞位於郵件解析環節，這一點決定了它的嚴重性。郵件閘道的職責就是收下並剖析每一封進來的信——攻擊者不需要誘使任何人點擊、不需要有效憑證，只要把構造過的郵件寄到你的網域，設備在處理它的過程中就被攻陷。

這是一條零點擊的路徑。而且郵件閘道位於網路邊界、通常對全網際網路開放、又持有解密後的郵件內容與寄送憑證。拿下它等同同時取得郵件內容的存取權與一個內網立足點。

The flaw sits in email parsing, and that placement determines its severity. A mail gateway's entire job is to accept and parse every message that arrives — so an attacker needs no click, no valid credentials, only to send a crafted message to your domain. The appliance is compromised in the course of doing its job.

This is a zero-click path. And a mail gateway sits at the network edge, is typically reachable from the whole internet, and holds decrypted message content plus sending credentials. Owning it grants both access to mail and a foothold inside.

使用 Cisco Secure Email Gateway 的組織。因為攻擊來自「收信」這個無法關閉的功能，沒有「暫時停用該功能」這個緩解選項，只能修補或下線。

Any organisation running Cisco Secure Email Gateway. Because the attack arrives through receiving mail — a function you cannot switch off — there is no "temporarily disable the feature" mitigation. Patch or take it offline.

1. 立即套用 Cisco 的修補程式。這是本期優先序最高的項目。
2. 假設已遭入侵並盤查：檢視設備上的異常程序、非預期的設定變更、新增的帳號、對外連線紀錄。
3. 輪換該設備持有的所有憑證，包含與郵件服務、目錄服務、日誌平台之間的認證資訊。
4. 檢視郵件流紀錄，確認有無非預期的轉寄規則或郵件被外送到不明位址。
5. 若設備管理介面對外開放，一併收回到管理網段。

1. Apply Cisco's patch immediately. This is the highest-priority item in this issue.
2. Assume compromise and hunt: anomalous processes on the appliance, unexpected configuration changes, new accounts, outbound connections.
3. Rotate every credential the appliance holds, including authentication to mail services, directory services, and logging platforms.
4. Review mail flow logs for unexpected forwarding rules or messages sent to unfamiliar destinations.
5. If the management interface is internet-facing, pull it back to a management segment.

郵件閘道遭入侵後，最可靠的訊號在設備的對外連線而非郵件內容——正常運作的閘道對外連線目的地相當固定（郵件伺服器、更新來源、信譽查詢服務）。出現其他目的地就值得追查。設備本機日誌在被取得 root 之後不可盡信，請以網路側紀錄比對。

After a gateway compromise, the most reliable signal is the appliance's own outbound connections rather than message content — a healthy gateway talks to a fairly fixed set of destinations (mail servers, update sources, reputation services). Anything else warrants investigation. Do not rely solely on on-box logs once root has been obtained; corroborate from the network side.

Cisco 揭露有三個不同的威脅叢集正在利用兩個已修補的 FMC 漏洞，這些叢集分別關聯到勒索軟體與國家級攻擊行動。其中 CVE-2026-20079（CVSS 10.0）是 FMC 網頁介面的認證繞過漏洞，未經驗證的遠端攻擊者可藉此繞過驗證。

攻擊活動中已觀察到竊取憑證與部署 Qilin 勒索軟體。CISA 已將相關漏洞列入 KEV。

Cisco disclosed that three distinct threat clusters — variously linked to ransomware and state-sponsored operations — are exploiting two recently patched FMC vulnerabilities. Among them, CVE-2026-20079 (CVSS 10.0) is an authentication bypass in the FMC web interface that lets an unauthenticated remote attacker bypass authentication.

Observed activity includes credential theft and deployment of Qilin ransomware. CISA has added the relevant flaws to KEV.

FMC 是管理整個防火牆機群的中控台。攻陷它的後果不只是多一台被入侵的主機：

- 可以改規則——攻擊者能為自己開一條進出通道，而且這條規則看起來是合法設定
- 握有憑證——FMC 需要與所有受管防火牆及目錄服務認證，這些憑證都在它身上
- 看得見拓撲——整個網路的分段設計、允許的流量、資產分布一覽無遺

三個獨立叢集同時利用同一個漏洞，是一個重要訊號：它代表利用方式已充分擴散，不再是單一行為者的專有能力。這種情況下「還沒被攻擊」通常只是還沒輪到你。

FMC is the console that manages an entire firewall fleet. Compromising it costs more than one more owned host:

- Rules can be changed — an attacker can open a path for themselves, and that rule looks like legitimate configuration
- Credentials are held there — FMC authenticates to every managed firewall and to directory services, so those credentials live on it
- Topology is visible — segmentation design, permitted flows, and asset distribution all in one view

Three independent clusters exploiting the same flaw is a meaningful signal: the technique has diffused well beyond any single actor. In that situation, "we have not been attacked" usually means your turn has not come.

使用 Cisco Secure Firewall Management Center 或 Security Cloud Control 防火牆管理功能的組織。由於已有勒索軟體行為者參與，潛在後果包含營運中斷而不僅是資料外洩。

Organisations using Cisco Secure Firewall Management Center or Security Cloud Control firewall management. With ransomware actors involved, the potential outcome includes operational shutdown, not merely data exposure.

1. 立即套用修補程式（漏洞已修補，遭攻擊的是未更新的環境）。
2. 比對防火牆規則與您的變更紀錄。任何找不到對應工單的規則都要當成入侵跡證處理，這是本則最關鍵的一步。
3. 輪換 FMC 上的所有管理憑證，以及它用來認證受管防火牆與目錄服務的帳號。
4. 確認 FMC 網頁介面未對網際網路開放。管理平面不該從任意位置可及。
5. 檢查備份是否離線或不可變——已有勒索軟體行為者涉入，備份完整性直接決定復原能力。

1. Apply the patches now (fixes exist; the environments being hit are the unpatched ones).
2. Reconcile firewall rules against your change record. Any rule without a matching ticket should be treated as evidence of intrusion — this is the critical step here.
3. Rotate every administrative credential on FMC, plus the accounts it uses to authenticate to managed firewalls and directory services.
4. Confirm the FMC web interface is not internet-facing. A management plane should not be reachable from anywhere.
5. Verify backups are offline or immutable — with ransomware actors involved, backup integrity determines whether you can recover.

把焦點放在設定變更的來源與時間：非管理時段的規則異動、來自非管理網段的登入、以及同一管理帳號在短時間內做出大量變更。這些訊號比在被完全控制的主機上找惡意檔案可靠。

Focus on the source and timing of configuration changes: rule edits outside maintenance windows, sign-ins from outside the management segment, and one administrative account making an unusual volume of changes quickly. These are more reliable than hunting for malicious files on a host the attacker fully controls.

資安公司 Wiz 指出，攻擊者串接兩個 JFrog Artifactory 漏洞取得自架伺服器的管理員控制權並植入後門，觀察到的攻擊期間為 8 月 15 日至 9 月 8 日。JFrog 在這之前即已修補兩者，因此受害的是未更新的伺服器。

兩個漏洞分別是 CVE-2026-42016（CVSS 8.1，授權檢查不當——只驗證權杖的簽章與簽發者，未驗證其適用範圍，導致權限提升）與 CVE-2026-42018（驗證不當——在匿名存取已停用的情況下，仍可能將內部匿名使用者權杖回傳給未經驗證的呼叫端）。CISA 於 9 月 11 日將多個 Artifactory 漏洞列入 KEV。

Security firm Wiz reported that attackers chained two JFrog Artifactory flaws to take administrator control of self-hosted servers and plant backdoors, with observed activity running from 15 August to 8 September. JFrog had fixed both beforehand, so the servers being hit were the un-updated ones.

The two are CVE-2026-42016 (CVSS 8.1, incorrect authorization — validating a token's signature and issuer but not its scope, leading to privilege escalation) and CVE-2026-42018 (improper authentication — returning an internal anonymous-user token to an unauthenticated caller even when anonymous access is disabled). CISA added several Artifactory flaws to KEV on 11 September.

Artifactory 是建置流程拉取相依套件的來源。這個位置決定了它的價值：攻擊者植入後門之後，不必再攻擊任何一個開發者或 CI 節點——下游所有的建置都會主動來取用被動過手腳的產物。

這也是為什麼「權杖只驗簽章不驗範圍」這種看似技術性的疏失後果如此嚴重。權杖範圍（scope）存在的目的，就是讓一把低權限的鑰匙不能拿去開高權限的門；驗證漏掉這一步，等於整套權限模型失效。

本則與本站先前報導的 npm 蠕蟲屬於同一類問題的不同層次：那一次污染的是公開套件倉庫，這一次是企業自己的內部倉庫。後者更難察覺，因為它本來就是你信任的來源。

Artifactory is where build pipelines pull dependencies from. That position defines its value: once a backdoor is planted, the attacker need not touch a single developer machine or CI runner — every downstream build comes and collects the tampered artefact on its own.

It is also why a seemingly technical oversight — validating a token's signature but not its scope — carries such weight. Scope exists precisely so a low-privilege key cannot open a high-privilege door; skipping that check voids the entire permission model.

This is the same class of problem as the npm worm covered earlier on this site, one layer in: that campaign poisoned a public registry, this one poisons an organisation's own internal repository. The latter is harder to notice, because it is a source you already trust.

自架 Artifactory 且未在 8 月中前完成更新的組織。影響不限於伺服器本身——若後門確實植入，凡是在該期間從這台伺服器取用過產物的建置，都需要重新檢視。

Organisations self-hosting Artifactory that had not updated by mid-August. The impact is not confined to the server — if a backdoor was planted, every build that pulled artefacts from it during that window needs review.

1. 確認 Artifactory 已更新至修補版本。
2. 稽核管理員帳號與存取權杖：有無非預期的新增帳號、權限變更、或您不認得的權杖。
3. 比對 8 月 15 日至 9 月 8 日期間的產物：檢查該期間上傳或變更的產物與其雜湊值，特別是內部套件。
4. 輪換所有存取權杖，包含 CI 使用的服務帳號。
5. 檢視同期間的建置產出，若無法排除污染可能，重新建置比事後追查更快。
6. 中長期：對內部產物導入簽章驗證，讓建置流程能自行辨識未經授權的變更。

1. Confirm Artifactory is updated to a fixed release.
2. Audit administrator accounts and access tokens: unexpected new accounts, permission changes, or tokens you do not recognise.
3. Compare artefacts from 15 August to 8 September: check what was uploaded or modified in that window and verify hashes, internal packages especially.
4. Rotate every access token, including CI service accounts.
5. Review builds produced in the same period; where contamination cannot be excluded, rebuilding is faster than forensic tracing.
6. Longer term: sign internal artefacts so pipelines can detect unauthorised changes themselves.

在 Artifactory 的存取紀錄中尋找匿名或低權限主體成功執行了管理操作的事件——這正是權杖範圍未驗證所產生的痕跡。另外檢查產物的上傳來源 IP 是否都落在預期的 CI 網段內。

In Artifactory's access logs, look for anonymous or low-privilege principals successfully performing administrative operations — the fingerprint left by unvalidated token scope. Also check that artefact upload source IPs all fall within your expected CI ranges.

Acronis 威脅研究團隊（TRU）指出，疑似中國背景的威脅行為者 Red Heron 迅速利用 Gitea 的重大漏洞 CVE-2026-60004 入侵對外開放的執行個體，發動跨國攻擊行動。

規模數據值得注意：Red Heron 掃描了七個國家共 1,386 個 Gitea 執行個體，並另外維護一份 477 個台灣系統的獨立資料集，最終在六個國家入侵了 13 個組織。

時間軸是典型的「修補已釋出但未套用」：Gitea 於 7 月底修補，一個月後 CISA 警告該漏洞遭積極利用，而實際攻擊在 PoC 公開後不久即展開。

Acronis Threat Research Unit (TRU) attributed rapid exploitation of the critical Gitea flaw CVE-2026-60004 to Red Heron, a suspected Chinese threat actor, compromising internet-facing instances in a multi-national campaign.

The scale figures matter: Red Heron scanned 1,386 Gitea instances across seven countries and maintained a separate dataset of 477 Taiwan-based systems, ultimately compromising 13 organisations across six countries.

The timeline is the familiar "patch shipped, patch not applied": Gitea fixed it in late July, CISA warned of active exploitation a month later, and the attacks began shortly after proof-of-concept code became public.

「另外維護一份 477 個台灣系統的獨立資料集」這句話值得停下來看。它代表的不是隨機掃描後恰好打到台灣，而是針對台灣的目標篩選與資源配置——攻擊者投入了額外成本來建立這份清單。

自架 Git 服務為什麼是高價值目標？因為它同時裝著三樣東西：原始碼（可用於尋找其他漏洞）、CI/CD 的認證資訊（通往正式環境）、以及歷史提交（常含誤commit 的金鑰）。對情報導向的行為者而言，這比單純的資料外洩有價值得多。

這也是本期第三則與開發工具鏈相關的通報。前兩則（Artifactory、GitLab）加上這一則，共同顯示的趨勢是：開發基礎設施已從「內部工具」變成第一線的攻擊面，但多數組織對它的防護投入仍停留在內部工具的水準。

The phrase "maintained a separate dataset of 477 Taiwan-based systems" is worth pausing on. It does not describe random scanning that happened to hit Taiwan; it describes deliberate target selection and resource allocation — the operators spent extra effort building that list.

Why is a self-hosted Git service such a valuable target? Because it holds three things at once: source code (useful for finding further vulnerabilities), CI/CD credentials (a route into production), and commit history (frequently containing accidentally committed keys). For an intelligence-driven actor that is worth considerably more than a plain data breach.

This is also the third developer-toolchain advisory in this issue. Together with Artifactory and GitLab, the trend is clear: development infrastructure has moved from "internal tooling" to front-line attack surface, while most organisations still protect it at internal-tooling levels.

自架 Gitea 且對外開放的組織。台灣的組織應特別檢視——攻擊者已明確將台灣系統列為獨立目標集。

Organisations self-hosting internet-facing Gitea. Those in Taiwan should look particularly closely — the operators explicitly treated Taiwanese systems as a distinct target set.

1. 立即更新 Gitea 至修補版本。
2. 評估是否真的需要對網際網路開放。多數自架 Git 服務只有內部人員使用，移到 VPN 之後即可消除這整條攻擊路徑。
3. 若曾對外開放：檢視存取紀錄與 webhook 設定，尋找非預期的複製（clone）行為與新增的部署金鑰。
4. 輪換儲存庫中的所有 CI/CD 憑證與部署金鑰，並掃描歷史提交中是否有外洩的密鑰。
5. 檢查有無非預期的新增使用者或權限異動。

1. Update Gitea to a fixed release now.
2. Assess whether internet exposure is actually required. Most self-hosted Git services serve internal users only; moving behind a VPN removes this entire attack path.
3. If it was exposed: review access logs and webhook configuration for unexpected clone activity and newly added deploy keys.
4. Rotate all CI/CD credentials and deploy keys held in repositories, and scan commit history for leaked secrets.
5. Check for unexpected new users or permission changes.

在存取紀錄中尋找單一來源在短時間內複製大量儲存庫的行為——這是資料竊取階段的明確特徵，與正常開發者的使用模式差異極大。另外留意非上班時段、來自境外位址的驗證成功事件。

In access logs, look for one source cloning many repositories in a short window — a clear signature of the collection phase, and very unlike normal developer behaviour. Also watch for successful authentications outside working hours from foreign addresses.