【LLM 日報】2026 年 10 月 22 日 — LiteLLM 供應鏈攻擊、主動式代理與 agent-scale 基礎設施
過去三天的消息同時出現兩種方向：代理開始長時間替使用者處理工作，模型公司也在調整漏洞回應與程式碼基礎設施來承接更高的自動化流量。與此同時，LiteLLM 的 PyPI 發布被報告含有竊取憑證的程式，讓依賴、發布流程與代理權限的邊界仍是部署條件的一部分。
🔥 LiteLLM 1.107.0 PyPI 發布被報告含竊取憑證程式與後門
SafeDep 報告稱，LiteLLM 1.107.0 的 PyPI 發布包含 cook.pth、cook.py 與 sitecustomize.py 三個植入檔案，所有七個平台 wheel 都受到影響。cook.pth 會讓 Python 啟動時載入 cook.py；報告列出的收集目標包括瀏覽器密碼與歷史、SSH 金鑰、雲端憑證、CI/CD 機密、AI 開發工具設定、環境變數與雲端執行個體 metadata。
報告指出，資料會以 AES-256-CBC 加密，再用內嵌的 RSA 公鑰包裝金鑰後送往 www.litellm[.]dev/healthcheck；sitecustomize.py 另會每小時讀取 GitHub 上的 domain.txt，下載並執行第二階段程式。LiteLLM 1.106.2、1.107.0rc1 與 1.107.0rc2 在 SafeDep 的檢查中未發現同樣植入物。
SafeDep 比對了 539 次公開 GitHub Actions 執行紀錄，沒有找到建置或發布 1.107.0 的公開 workflow。其評估是惡意 wheel 可能由遭修改的私人發布流程產生，但也明確表示只有 BerriAI 的 pipeline log 能確認入侵來源。報告列出受影響檔案的 SHA-256 與主機、網路 IOC，供部署者檢查。
- 來源：safedep.io
Claude Duet 以背景代理處理郵件、行事曆與營運工作
Anthropic 將 Claude Duet 列為研究預覽，描述為會主動整理需要使用者處理的事項、在背景執行任務，並在敏感操作前等待核准的代理。產品頁列出的示例包括每日摘要、準備會議與簡報、整理資料、尋找未付款發票，以及準備薪資與合約相關工作。
Claude Duet 使用 Claude 帳號的記憶、技能與 connectors，產品頁宣稱支援超過 6,000 個 connectors 與 plugins；它在自己的雲端電腦上使用已連接的應用程式。Anthropic 說，登入、核准與安全檢查在該環境中執行，使用者可以查看代理已完成和正在進行的工作。
目前使用條件是美國地區的 Claude Pro 與 Max 訂閱者加入 waitlist，Team 與 Enterprise 尚未包含在內；使用量與 Claude 其他功能共用方案額度，背景檢查也會計入額度。Anthropic 同時列出研究預覽的限制：代理可能誤讀對話、判斷錯誤的急迫性，或在兩次檢查之間漏掉新進訊息。
- 來源：claude.com
OpenAI 提出 Patch the Planet，協調 AI 發現漏洞後的修補流程
OpenAI 表示，過去兩個月曾與維護者、研究人員和安全服務商合作處理 PHP 的重大漏洞；其文章稱 Calif 使用 GPT-5.6 Sol 發現其中一個漏洞，Wiz 也獨立發現並通報兩個漏洞。PHP 維護者負責修補與發布，OpenAI、Wiz、Cloudflare 等團隊提供研究、技術支援與協調。
Patch the Planet 提出的流程包括確認上游漏洞、讓受影響組織預留處理時間、與政府夥伴協調、準備不同產品的更新，以及在修補程式可用後發布指引。OpenAI 也公開 PHP version checker 的 Codex skill，讓營運者檢查版本並依 PHP 與服務商指引判斷應套用的更新。
這套框架把提前通知的對象交給維護者依保護角色、處理時間與敏感資訊能力判定；文章沒有列出固定的審查機制或申訴流程。OpenAI 說已承諾提供 10 億美元的補助 Daybreak 存取額度給防禦者，並表示會調整阻擋濫用的分類器；公司同時把「誰需要提前知道」與披露窗口列為仍在徵求意見的問題。
- 來源：openai.com
GitHub 以逐 reference quorum 提高 agent-scale Git 寫入吞吐量
GitHub 工程團隊表示，99.99999% 的 repository 已同時存放在自有資料中心與 Azure，剩餘最繁忙的 repository 受到約 25 毫秒跨區 round trip 影響。現有 Spokes quorum 會等待所有健康 replica 回應，且整個 repository 的寫入在提交時持有鎖，最慢 replica 會影響每次寫入的延遲與吞吐量。
新設計把 quorum 的序列化範圍從整個 repository 縮小到單一 reference。不同 branch 的更新可以並行處理，只有寫入同一 reference 的操作需要互相等待。GitHub 表示，在使用真實流量的內部測試中，不同 reference 的寫入吞吐量提高約 3 到 4 倍、延遲也較低。
GitHub 也描述把 Azure Blob Storage 加入 quorum、作為不提供讀取的 virtual replica，讓 repository 資料持久化後，再依需求增加不加入 quorum 的 virtual read replicas。這些讀取 replica 會從 Blob Storage 暖機並在背景同步；GitHub 明確列出的尚未解決條件包括部分讀取工作仍需要即時同步，以及 quorum 仍是進一步提高寫入吞吐量的限制。
- 來源：github.blog