AUR 供應鏈攻擊：數百個孤立套件遭植入惡意 npm 模組，用戶資料面臨外洩風險
Arch Linux aur-general 郵件列表 · 2026-06-12 發布
2026 年 6 月 12 日，Arch Linux 社群發現 Arch User Repository（AUR）中數百個孤立套件遭到惡意竄改，攻擊者在套件建置腳本中注入了名為 atomic-lockfile 的惡意 npm 模組，導致使用者在編譯這些套件時，敏感資料可能被靜默外洩至攻擊者控制的遠端伺服器。Arch Linux 維護團隊在確認事件後，隨即啟動緊急清理程序，逐一重置或刪除遭竄改的提交，並封鎖相關攻擊者帳號。
漏洞機制
AUR 的設計允許任何已註冊使用者認養（adopt）無人維護的孤立套件，並取得直接推送 PKGBUILD 的權限，而這些變更無需經過人工審核即可上線。攻擊者利用此信任模型，批次認養了數百個長期無人維護的孤立套件，並在 PKGBUILD 的 build() 或 package() 函數中插入對 atomic-lockfile npm 模組的依賴呼叫。
惡意模組 atomic-lockfile 在安裝或執行時觸發資料外洩邏輯，蒐集並回傳主機上的敏感資訊，包括環境變數、Shell 歷史記錄、SSH 金鑰等潛在高價值資料。由於 AUR 套件的建置過程通常以使用者身分（而非 root）執行，受竊資料的範圍主要集中於當前使用者的 home 目錄與執行環境。針對啟用了 chroot 隔離沙箱（如 devtools 中的 makechrootpkg）進行建置的使用者，其暴露風險相對較低，但並非完全免疫。
下方為遭竄改後的典型 PKGBUILD 片段示意：
build() {
cd "$pkgname-$pkgver"
npm install atomic-lockfile # 惡意注入行
./configure --prefix=/usr
make
}根據 AUR 孤立套件列表（gr.ht/aur_pkg_list.txt），受影響套件逾 400 個，涵蓋範圍相當廣泛，包括桌面環境元件（Hyprland、KDE 相關工具）、媒體工具（FFmpeg 變體、VLC 外掛）、開發工具（LLVM 衍生版本、Python 輔助套件）及多種系統工具，對 Arch 或 Arch 衍生發行版（如 Manjaro、EndeavourOS）的使用者構成現實威脅。
受影響版本
- 所有在 2026 年 6 月 12 日前後從 AUR 安裝或更新受影響孤立套件的使用者
- 使用
yay、paru、makepkg等工具手動建置 AUR 套件的使用者 - Arch Linux、Manjaro、EndeavourOS 及其他 Arch 衍生發行版使用者
- 以一般使用者權限（非 chroot 沙箱）執行建置流程者，風險相對較高
修補與緩解
Arch Linux 官方正積極清除所有惡意提交，並已封鎖攻擊者帳號。建議使用者立即核對自己安裝的套件是否出現在受影響列表（gr.ht/aur_pkg_list.txt），若有符合項目，應視同主機已遭竄改，立即輪換 SSH 金鑰、API 金鑰及其他重要憑證。
從實務緩解角度，建議在 chroot 沙箱環境中建置所有 AUR 套件，可使用 devtools 套件提供的 makechrootpkg 工具，限制建置過程對主機資源的存取。此外，在安裝前仔細審閱 PKGBUILD 內容、善用 PKGBUILD diff 工具，以及避免認養或安裝長期無人維護的孤立套件，均是降低 AUR 供應鏈風險的長期有效策略。此次事件也再次突顯 AUR 缺乏自動化審核機制的結構性隱患，社群對於引入更嚴格孤立套件認養審核流程的討論，預計將因此事件重新升溫。
原始來源：LWN.net — Hundreds of AUR packages compromised、Arch Linux aur-general 郵件列表
OpenStack Neutron 通訊埠 RBAC 規則可繞過：DSA-6340-1 修補 Trixie 版本
Debian Security Announce · 2026-06-12 發布
2026 年 6 月 12 日，Debian 發布安全公告 DSA-6340-1，修補 OpenStack 虛擬網路服務 Neutron 中一項由研究員 Tim Shepard 發現的存取控制繞過漏洞，編號 CVE-2026-50266。該漏洞允許攻擊者繞過 Neutron 通訊埠（port）層級的角色型存取控制（RBAC）規則，在多租戶 OpenStack 環境中，可能導致未授權的網路資源存取或跨租戶隔離失效。Debian stable（Trixie）已釋出修補版本，oldstable（Bookworm）不受影響。
漏洞機制
OpenStack Neutron 透過 RBAC 策略管理網路資源的存取權限，允許租戶管理員精細控制哪些專案（project）可使用特定的網路、子網路或通訊埠資源。CVE-2026-50266 的根因在於 Neutron 的通訊埠 RBAC 規則在特定請求路徑下未被正確強制執行，導致擁有有效 OpenStack 憑證的租戶使用者，在不具備對應 RBAC 授權的情況下，仍能操作原本應受保護的通訊埠資源。
在多租戶 OpenStack 部署中，通訊埠 RBAC 是實現租戶間網路隔離的關鍵機制。若此隔離被繞過，惡意租戶可能將虛擬機器接入不屬於其租用範圍的網路片段，進而進行網路嗅探、橫向移動，或干擾其他租戶的網路流量。公有雲或私有雲的多租戶 Neutron 部署受影響程度最高；單租戶部署（如私人實驗室環境）的實際風險較低，但仍建議更新。
Debian 安全公告未公開具體的技術利用細節或概念驗證（PoC）程式碼，以降低在補丁廣泛部署前遭到利用的風險。管理員可查閱 Debian 安全追蹤器（security-tracker.debian.org）取得最新狀態資訊。
受影響版本
- Debian Trixie（stable）：
neutron2:26.0.3-0+deb13u1及更早版本受影響 - Debian Bookworm（oldstable）：不受影響
- 使用 Trixie 套件庫部署 OpenStack 的私有雲、公有雲及混合雲環境
- 上游 OpenStack Neutron
26.x系列（Epoxy 版本）的其他發行版包裝亦可能受影響，需查閱各發行版公告
修補與緩解
Debian Trixie 的修補版本為 neutron 2:26.0.3-0+deb13u2，已透過標準 Debian 安全更新頻道發布。管理員應立即執行 apt-get update && apt-get install neutron-server（視部署架構調整元件名稱）完成更新，更新後須重新啟動 Neutron API 服務使修補生效。
在更新之前，可作為臨時緩解措施的方向包括：嚴格限制能夠向 Neutron API 發送請求的帳號數量，並在 Keystone 層面強化最小權限原則，確保租戶使用者僅具備實際業務所需的最低 OpenStack 角色。OpenStack 部署者也應定期審閱 Neutron 的 RBAC 策略配置，移除過於寬鬆的共享規則，以降低此類繞過漏洞的潛在影響範圍。
Portainer 預設高風險配置允許容器逃逸並接管宿主機：CVE-2026-33590（CVSS 8.2）
oss-security 郵件列表 · 2026-06-12 發布
2026 年 6 月 12 日，資安研究員 Sifis Bampionitakis（intWave 實習生）透過 oss-security 郵件列表公開披露 CVE-2026-33590，影響廣泛使用的容器管理平台 Portainer 2.38.0 以前的所有版本。該漏洞源自不安全的預設配置——Portainer 預設允許使用者建立特權容器（privileged container）並掛載宿主機目錄（bind mount），低權限的 Portainer 使用者即可藉此執行任意命令，最終完全接管容器宿主機。CVSS v3.1 評分為 8.2（High），攻擊者僅需具備低權限 Portainer 帳號即可發動攻擊，無需利用任何程式碼漏洞。
漏洞機制
Portainer 是一套圖形化 Docker/Kubernetes 管理介面，在中小型團隊與 homelab 環境中極為普及。問題根源在於 Portainer 的 Docker Security Settings 預設關閉了兩項關鍵限制：一是禁止使用者建立特權模式容器（--privileged）的選項預設為「允許」，二是禁止任意 bind mount 宿主機路徑的選項同樣預設為「允許」。這意味著，任何被授予 Portainer 環境存取權的使用者（即便角色定義為受限的 Standard User），都可以在不需要 Docker socket 直接存取權的情況下，透過 Portainer UI 建立高度危險的容器。
實際攻擊路徑相對直接。攻擊者登入 Portainer 後，建立一個啟用 --privileged 旗標並將宿主機根目錄（/）掛載至容器內部的新容器，在容器內執行 chroot 即可獲得宿主機的完整 root 存取權限：
# 攻擊者透過 Portainer UI 建立容器時設定：
# Privileged mode: ON
# Volume: / → /host (bind mount)
# 進入容器後執行：
chroot /host /bin/bash
# 已取得宿主機 root shell由於 Portainer 在企業與社群中常作為多使用者管理介面部署，且往往開放給不完全受信任的內部使用者，此預設配置實際上將 Portainer 帳號等同於宿主機 root 帳號，嚴重違反最小權限原則。CVSS 向量 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H 反映了此漏洞的高影響範圍：可跨越容器邊界（Scope Changed），且對機密性、完整性與可用性均造成高度影響。
受影響版本
- Portainer CE 及 EE 所有版本 < 2.38.0
- 使用預設 Docker Security Settings 部署的任何 Portainer 實例
- 在 Portainer 中開放多使用者存取（包括 Standard User 角色）的環境風險最高
- 單一管理員自用的 Portainer 實例若從未開放其他帳號，實際可利用性較低
修補與緩解
Portainer 已在 2.38.0（STS，短期支援）與 2.39.0（LTS，長期支援）中修正此問題，新版本將「禁止特權容器」與「禁止任意 bind mount」作為預設開啟的安全選項。管理員應立即升級至上述版本之一，並在更新後依照 Portainer 官方文件重新審閱 Settings → Docker Security Settings 頁面的配置，確認安全限制確實生效。
若短期內無法升級，可採取以下緩解措施：在 Portainer 的 Environment 設定中，手動開啟「Disable use of privileged containers」與「Disable use of host path binds」兩項選項。同時應嚴格控管 Portainer 使用者帳號的發放，將 Standard User 角色的授予限制在完全受信任的人員，避免將 Portainer 存取權視為低風險操作開放給一般使用者。此外，建議在 Portainer 前方加設身份驗證閘道（如 OAuth2 Proxy 或 SSO），避免 Portainer 直接暴露於內網所有使用者。
原始來源：oss-security — CVE-2026-33590: Insecure default settings of Portainer < 2.38.0