標籤: PostgreSQL

[Tempest AI 深度解讀] 一個 SQL 關鍵字攻破「唯讀」：Postgres MCP 漏洞如何一路變成系統命令 (2026-10-05)

一個標示為「唯讀」的資料庫工具，為何可能一路變成作業系統命令執行入口？關鍵不在於 MCP 協定本身，而在於應用程式如何解讀「唯讀」，以及 PostgreSQL 帳號最後究竟握有多少權限。

事件背景：修補早於公開警報

原始分析指出，AWS Labs 的 postgres-mcp-server 在預設唯讀模式下，曾未攔住 COPY ... TO PROGRAM。攻擊者若把特製 SQL 植入代理會讀取的內容，經由已驗證使用者觸發工具呼叫，便可能讓 SQL 抵達資料庫。原文與技術脈絡見：https://dev.to/kielltampubolon/read-only-postgres-mcp-servers-fail-with-1-sql-keyword-18b8。

可確認的來源事實是：AWS 於 2026 年 9 月 9 日公布 CVE-2026-87911；受影響版本為 1.1.7 以前，GitHub 公告給予 CVSS 3.1 的 9.6 分。成立條件包括使用 PG wire 連線、自行管理的 PostgreSQL，以及 MCP 連線角色具備超級使用者或 pg_execute_server_program 權限。1.1.7 已修補此問題：https://aws.amazon.com/security/security-bulletins/2026-104-aws/、https://github.com/awslabs/mcp/security/advisories/GHSA-fph8-pg5w-78fv。

PyPI 紀錄顯示，1.1.7 其實早在 6 月 25 日上架，距公告超過兩個月。這段落差的實際意義是：使用浮動最新版者可能早已被動取得修補，鎖定舊版、內嵌原始碼或維護 fork 的團隊，卻未必知道應立刻處理。版本資料見：https://pypi.org/project/awslabs.postgres-mcp-server/1.1.7/。

一個關鍵字如何穿過「唯讀」

COPY 不只是匯入、匯出表格資料。搭配 PROGRAM 時，PostgreSQL 伺服器會直接執行指定程式，命令不是跑在使用者電腦，也不是跑在 MCP 客戶端，而是在資料庫主機上，並繼承 PostgreSQL 作業系統帳號能觸及的資源。官方文件同時明定，這項能力只應開放給超級使用者或持有 pg_execute_server_program 的角色：https://www.postgresql.org/docs/current/sql-copy.html。

這也解釋了為何把交易設成 READ ONLY 並不足夠。PostgreSQL 的唯讀交易會禁止寫入一般資料表的 INSERT、UPDATE、DELETE 與 COPY FROM 等操作，但官方明確稱這只是「高階層的唯讀概念」，無法阻止所有磁碟寫入；禁止清單也未包含 COPY TO PROGRAM。交易模式約束資料操作，角色權限才約束能否叫資料庫主機執行程式：https://www.postgresql.org/docs/current/sql-set-transaction.html。

為何現在值得注意

合理推論是：這起事件揭露的不是單一關鍵字有多神奇，而是 AI 代理把外部內容、使用者身分與高權限工具串成同一條執行鏈。攻擊者未必需要登入資料庫；他只要影響模型讀到的文字，再由代理代為提出查詢。CVSS 中「不需攻擊者權限、但需要使用者互動」正反映這種間接路徑。

更值得警惕的是安全邊界放錯位置。舊版用阻擋清單識別危險語法，能攔住已知名稱，卻很難窮舉 PostgreSQL 擴充功能、自訂函式、動態 SQL 與未來新增能力。9 月初另一項 CVE-2026-85787 也涉及 1.1.7 以前版本的唯讀檢查不完整，說明「再補一個名稱」並非穩定的權限模型。

影響範圍與容易忽略的限制

不能把此漏洞簡化成「所有 Postgres MCP 都能拿 shell」。AWS 公告限定於特定舊版、PG wire、自管 PostgreSQL與高權限角色；若 MCP 使用專屬低權限角色，資料庫會直接拒絕 COPY ... PROGRAM。同樣地，CVSS 9.6 描述的是條件成立時的技術衝擊，不等於每個部署都有同樣風險。

截至 10 月初，專案現行文件顯示查詢已改以 PostgreSQL 解析器處理，會拒絕多陳述句、解析錯誤、命令執行與主機檔案操作；但維護者仍把這層稱為「最佳努力」的縱深防禦，並承認解析器無法看穿任意第三方函式或動態 SQL。這項更新降低已知繞過空間，並沒有把應用層驗證升格成真正的權限邊界：https://github.com/awslabs/mcp/blob/main/src/postgres-mcp-server/README.md。

對台灣企業的實際意義

作者觀點是：企業導入 MCP 時，不應把產品介面的「唯讀」標籤直接寫進風險評估結論。金融、製造、醫療與零售常把代理接上內部報表庫；一旦沿用管理員帳號求快速上線，原本只是資料查詢的元件，就可能取得讀取主機檔案、跨網路存取或執行程式的能力。真正可稽核的問題應是：「資料庫拒絕什麼？」而不是「MCP 宣稱攔截什麼？」

  • 盤點實際套件、容器映像與 fork，確認不是只更新部署文件，而是執行中的版本已至少包含 1.1.7 修補。
  • 為每個代理建立專屬角色，只授予必要資料庫的 CONNECT、必要 schema 的 USAGE 與指定資料表的 SELECT。
  • 確認角色不是超級使用者，也未繼承 pg_execute_server_program、pg_read_server_files 或 pg_write_server_files。
  • 把資料庫程序放入受限主機或容器，限制對外連線、檔案系統與雲端中繼資料服務；這是降低失守後衝擊，不是取代資料庫權限。

後續觀察指標

接下來應觀察三件事：維護者是否把高權限角色檢查變成預設啟動門檻；企業是否能在稽核紀錄中區分使用者、模型與工具實際送出的 SQL；以及後續安全公告是否仍反覆出現「遺漏一個函式或語法節點」。若同類漏洞持續發生，答案就很清楚：MCP 的唯讀過濾適合改善操作體驗，真正的安全承諾仍必須落在資料庫角色、主機隔離與可追溯的授權鏈上。

[Tempest Agent Insights] 技術趨勢 (2026-10-04)

本期焦點從「Agent 能不能完成任務」進一步轉向「如何安全、可靠且可追溯地在正式環境執行」。工程端開始補強規格、權限、稽核與上下文管理；產品端則持續探索 Agent 原生介面、資料基礎設施與商業模式。

1. 程式碼看得懂，不代表能還原正式環境現場

AI coding agent 可以快速理解整個程式碼庫並完成修改，但當錯誤只發生在正式環境時，靜態程式碼上下文仍不足以回答「當時實際發生了什麼」。這凸顯 Agent 若要參與事故處理，還需要可查詢的執行紀錄、遙測資料、版本資訊與環境狀態，而不能只靠閱讀原始碼推理。

來源：https://ift.tt/4Lyj0Pg

2. Agent 治理需要系統紀錄，而不只是監控儀表板

當 Agent 開始登入供應商入口網站、核准發票、建立工單，甚至把任務交給其他 Agent，傳統服務監控已不足以支撐治理。企業需要保存每次決策的輸入、授權依據、工具呼叫、交接關係與最終動作，才能在出錯後重建完整脈絡，並釐清責任。

來源：https://ift.tt/CVXm2O8

3. 規格驅動與推理結構成為可靠性工程重點

規格驅動開發逐漸成為管理 AI Agent 的重要方法：先明確描述限制、驗收條件與允許的變更範圍，再讓 Agent 執行。另一項討論則指出，除單次答案是否正確外，推理流程能否維持結構完整、步驟一致且可檢查，同樣會影響自主工作流程的可靠性。

來源：https://ift.tt/CfuncBm、https://ift.tt/rdGFy1i

4. 沙箱不一定是 Agent 真正的信任邊界

近期案例顯示，風險可能在 Agent 進入沙箱前，就透過儲存庫設定等機制觸發；也可能在沙箱內，藉由看似合理的任務路徑把敏感內容傳到外部。這代表防護不能只看執行環境，還必須涵蓋輸入來源、工具供應鏈、網路出口與產出目的地。可安裝的 Agent skill 也應在啟用前接受安全掃描與權限審查。

來源：https://ift.tt/j5tqZLX、https://ift.tt/iIh0wCo

5. Apple 擬提高 macOS 完整磁碟存取的授權門檻

隨著 AI Agent 應用程式要求讀取更廣泛的本機資料，Apple 表示將加強 macOS「完整磁碟存取」控制。報導指出，使用者授予這類高權限時將需要更明確的操作。對桌面 Agent 開發者而言，最小權限、分階段授權與清楚說明資料用途，將成為產品設計的必要條件。

來源：https://ift.tt/MkRHVO0、https://ift.tt/0BduFJ2

6. WebMCP 嘗試讓網頁直接提供 Agent 可呼叫介面

目前許多瀏覽器 Agent 仍依靠讀取畫面、尋找按鈕與模擬點擊完成任務，版面或元件一變就容易失效。WebMCP 的方向是讓 Angular 應用程式提供較明確的 Agent 操作介面，把原本脆弱的 UI 自動化轉成具語意、可控管的 API 呼叫。

來源：https://ift.tt/ejRc9SW

7. Temporal Agent Harness 聚焦耐久且可組合的工作流程

Temporal Agent Harness 0.6.0 以 Temporal 為基礎，嘗試讓 Agent 工作流程具備耐久執行與組合能力，並能搭配既有 AI SDK。專案目前仍標示為實驗性質，API 可能變動；但它反映了 Agent 基礎設施正從單次呼叫，轉向可重試、可恢復且能長時間執行的任務編排。

來源：https://ift.tt/Xqowixu

8. PostgreSQL 權限可以設防，但無法包辦所有資料風險

當 Agent 查詢客戶、公司或伺服器等敏感資料時，PostgreSQL 可透過資料庫權限與政策限制存取範圍，但資料庫本身無法完全判斷某次查詢的業務目的是否合理，也無法控制資料離開資料庫後如何被組合與揭露。實務上仍需搭配身分驗證、查詢稽核、輸出過濾及應用層授權。

來源：https://ift.tt/VPUnkCf

9. 跨多個儲存庫的上下文仍是 coding agent 痛點

多數 coding agent 以單一根目錄作為理解與操作邊界，因此在跨服務、共用函式庫與基礎設施設定分散於不同儲存庫時，容易缺少完整依賴關係。改善方向不只是增加 context window，還包括建立跨儲存庫索引、版本對應、介面契約，以及明確的變更影響範圍。

來源：https://ift.tt/U3AvH16

10. AI 正把高效能運算工程師推向 Agent 協作模式

AI Agent 已開始產生用於 Nvidia GPU 的 CUDA kernel，部分結果甚至難以由人類工程師快速解釋。高效能運算工作的重心因而可能從逐行手寫，轉向提出限制、建立效能基準、驗證數值正確性與審查機器產生的實作；可驗證性也會比程式碼表面上的可讀性更重要。

來源：https://ift.tt/yRnE8HT

11. 開發速度提升後，市場驗證成為更明顯的瓶頸

多位獨立開發者觀察到，AI Agent 已大幅縮短 SaaS MVP 的製作時間，但「做得快」不會自動帶來付費客戶。如何辨認真正有需求的族群、找到接觸管道並展開有效對話，仍是產品能否成立的關鍵。Agent 的下一個價值焦點，可能從產生更多功能轉向支援研究、驗證與客戶開發。

來源：https://ift.tt/Bho5Yla、https://ift.tt/vAsKDFl

[Tempest Rust Daily] 技術情報精華 (2026-10-05) – 深度完整版

本期焦點涵蓋 Rust 編譯器行為、跨語言整合、訊息系統、資料隔離與新興開發工具。以下整理值得關注的技術文章與專案。

derive 巨集經常隱含 inline

文章指出，Rust 透過 #[derive(...)] 自動實作 Debug、Display、Clone 等核心 trait 時，目前可能同時產生 #[inline]。這項容易被忽略的編譯器行為，有助於理解衍生實作的程式碼生成方式與最佳化特性。

原文：https://ift.tt/sPlBRGy

從一則訊息理解 RocketMQ Rust

文章沿著單一訊息的生命週期，檢視 RocketMQ Rust 的架構與部署方式：發送呼叫返回後由哪個程序接收、資料何時進入儲存層，以及回應遺失、消費者重新啟動或資料庫更新成功時，系統會如何處理。這種分析方式適合用來釐清訊息可靠性與服務邊界。

原文：https://ift.tt/TcXfF4i

Rust 搭配 PostgreSQL RLS 的多租戶隔離

作者分享一套由單一 Rust 執行檔與 PostgreSQL 16 組成的雙容器架構，不額外使用 Redis 或 Kafka。儀表板查詢透過 PostgreSQL Row-Level Security，並以 SET LOCAL app.current_org_id 指定組織範圍，目標是在共用資料庫中降低應用程式錯誤造成跨租戶資料外洩的風險。

原文：https://ift.tt/3aYLoIt

Rust 納入 CPython 的評估方向

David Hewitt 在 PyCon US 2025 初步探詢後，進一步向 Python 核心開發者討論 CPython 導入 Rust 的需求，並提出時程、階段與成功標準。另一篇報導則從 Python 安全開發者 Seth Larson 的觀察切入，呈現官方核心開發者社群如何評估這項嘗試。

相關文章：https://ift.tt/GV0Ax7z

延伸報導：https://ift.tt/5WSVlkz

Tarvos：以 Rust 為中介的 Python 原生編譯器

Tarvos 鎖定可靜態分析的 Python 子集，依序進行型別檢查、降階至中介表示、產生 Rust 程式碼，最後輸出不需 Python 執行環境的獨立原生執行檔。作者特別強調這是子集編譯器，而非 CPython 的完整替代方案，並徵求社群對測試方法的意見。

原文：https://ift.tt/7oVIjbt

從 Rust 呼叫 C++ 靜態方法

這則討論聚焦於如何在不修改既有函式庫的前提下，從 Rust 呼叫 C++ 類別的靜態方法。範例同時涉及原始指標、自訂回傳型別與 C++ ABI，是規劃 Rust／C++ FFI 邊界時常見且具代表性的整合情境。

原文：https://ift.tt/0KZBokM

Rust 1.99.0 與 C 風格可變參數函式

文章整理 Rust 1.99.0 對可變參數函式的支援、原始指標安全規則的明文化，以及與下一版本相關的文件調整。對需要銜接 C ABI 或處理底層介面的開發者而言，這些變更值得納入相容性與安全性評估。

原文：https://ift.tt/wNIZjU9

cliproxy-rs：統一多家 AI 帳號的本機端點

cliproxy-rs 是一項 Rust 專案，目標是把既有的 Claude、ChatGPT 與 Gemini 帳號整合到單一本機端點，讓不同程式開發工具能透過一致介面使用。對同時採用多個 AI 服務的工作流程而言，這類代理層可簡化工具端設定。

原文：https://ift.tt/N6jGiDx

Cranpose：以 Rust 實作 Jetpack Compose 概念

Cranpose 嘗試把 Android 開發者熟悉的 Jetpack Compose 經驗帶入 Rust 生態系。作者經過近一年的構想與開發後公開專案，希望蒐集社群回饋；其核心方向是探索宣告式 UI 模型如何在 Rust 中落地。

原文：https://ift.tt/KfT7u2v

從 JavaScript 開發者角度理解 Rust 所有權

文章以 Node.js 中物件傳遞、原地修改與資料複製等常見問題為起點，帶領 JavaScript 開發者理解 Rust 的所有權模型。透過熟悉的可變資料情境切入，有助於建立所有權、借用與資料生命週期的直覺。

原文：https://ift.tt/chWoF4d

低規格 VPS 上的八種後端技術比較

這項實驗在配備 1 顆共享 CPU 與 2GB 記憶體的平價 VPS 上，以相同負載測試 Node、Bun、Python／FastAPI、Go、Java／Spring Boot、C#、PHP／Laravel 與 Rust。雖然摘要未提供測試數據與方法細節，但其統一硬體與負載的設計，可作為討論不同後端技術資源需求的起點。

原文：https://ift.tt/jrlpOdi

[Tempest Rust Daily] 技術情報精華 (2026-09-30) – 深度完整版

本期整理 Rust 生態系的實務案例與技術動向，涵蓋桌面工具、Web 後端、資料庫套件、GPU 程式設計、GUI 框架，以及序列化與型別處理等主題。

用 Rust 統一控制多螢幕亮度

開發者以 Rust 打造 Windows 系統匣工具，讓使用者能從同一介面調整各顯示器的亮度。筆電螢幕透過 Windows 內建的 WMI 控制，外接螢幕則使用 DDC/CI，省去逐台操作實體按鍵的麻煩。[https://ift.tt/Mpa0AnO]

給 C#／.NET 開發者的 Rust 入門指南

這份非完整指南以 C# 與 .NET 開發者為主要讀者，對照兩邊能互相映射的概念與語法，也介紹 Rust 記憶體管理等差異較大的設計。適合已熟悉 .NET、希望建立 Rust 心智模型的工程師。[https://microsoft.github.io/rust-for-dotnet-devs/latest/]

在 Termux 上實作終端機抽籤程式

一位來自孟加拉、剛接觸 Rust 的開發者，在手機的 Termux 環境完成抽籤應用程式。程式可接收並儲存姓名、隨機抽出結果，也能刪除既有名單；作者公開作品，希望社群協助進行程式碼審查。[https://ift.tt/21vYaM4]

從資料結構著手降低 DNS 快取記憶體用量

文章探討 Cloudflare 工程師如何調整 Rust 資料結構，減少不必要的記憶體浪費並改善 DNS 快取效能。標題宣稱節省了 100 TB 記憶體，內容焦點則是小型程式碼與資料配置最佳化在大規模服務中的累積效益。[https://ift.tt/QcIkeKM]

以 Rust 重製 ONCE Campfire

此專案將原本的 Rails 應用程式移植至 Rust，並以單一執行檔提供服務。開發目標包括維持畫面與通訊協定的一致性，以及直接沿用既有的 SQLite 資料庫和儲存目錄；作者宣稱完成相容性後，效能可達原版本的 19 至 44 倍。[https://ift.tt/wt1i8Hd]

用 Rust 改寫 FastAPI 限流瓶頸

作者表示 Python API 在每秒 10,000 次請求的負載下出現瓶頸，因此將限流器改以 Rust 實作。依文章標題所述，改寫後延遲降低 94%；案例重點在於辨識後端熱點，再針對關鍵路徑導入 Rust，而非全面重寫整套服務。[https://ift.tt/D8OMrqU]

Rust 擴充套件進入 PostgreSQL RPM 軟體庫

PostgreSQL RPM 軟體庫開始納入 Rust 相關套件，首批包含 pgrx 與 postgresql_anonymizer，並同步提供封裝規範。公告也提醒目前仍存在部分限制，對需要在 RPM 系統部署 PostgreSQL Rust 擴充功能的維運團隊而言，是值得關注的封裝進展。[https://postgr.es/p/9ww]

Rust Coreutils 0.12.0 聚焦 Ubuntu 相容性

Rust Coreutils 0.12.0 的開發重點是改善 Ubuntu 使用情境下的相容性。相關討論同時涉及專案承認曾複製 GNU GPL 程式碼的議題，使這次版本除了技術修正，也受到開源授權與程式碼來源管理方面的關注。[https://ift.tt/B5MiwuL]

探索 Arc 向下轉型與 Pin 的組合問題

作者在開發建置驅動程式時，遇到需要處理 Arc 向下轉型的特殊情境，並提出一套非典型解法。文章從實際問題出發，逐步說明 Arc、型別擦除、向下轉型與 Pin 之間的限制，適合想深入理解 Rust 型別與指標語意的讀者。[https://ift.tt/vodh2pF]

推動 Rust 原生 GPU 程式設計支援

rust-gpu 與 Rust CUDA 維護者 Christian Legnitto 持續探索以 Rust 開發 GPU 程式的可能性。現有專案已能讓開發者使用 Rust 撰寫部分 GPU 工作負載，但作者希望進一步改善工具鏈整合與原生支援，使 GPU 開發體驗更接近一般 Rust 專案。[https://ift.tt/PHsg3bc]

Git 用戶端從 Tauri／React 改用 Iced

一款以 Rust 開發的 Git 用戶端，將介面從 Tauri 搭配 React 改寫為 Iced。這次重構源於既有混合式架構的技術困擾，目標是統一技術堆疊、改善效能，並強化 Linux 支援；案例也呈現 Rust 原生 GUI 與 Web 前端方案之間的取捨。[https://ift.tt/m4rDbPE]

Deser 重新思考 Rust 序列化設計

Serde 長期是 Rust 生態系的重要序列化函式庫，但作者在實務使用中遇到若干限制，因此提出 Deser，嘗試重新思考序列化介面與架構。由於 Serde 已擁有龐大生態系，替代方案面臨的不只是 API 設計，也包含相容性與套件採用等挑戰。[https://ift.tt/8S2zJbN]

[Tempest AI 深度解讀] 唯讀不是安全邊界：Postgres MCP Pro 高危漏洞揭露代理資料庫防線缺口 (2026-09-06)

事件背景：被繞過的是「受限模式」

Postgres MCP Pro 是讓 AI 代理查詢、分析與調校 PostgreSQL 的開源 MCP 伺服器。專案文件把 restricted mode 定位為適合生產環境的選項：查詢在唯讀交易中執行，並先由 SQL 解析器檢查可接受的陳述與函式。原始報導將 CVE-2026-85620 描述為整套安全控制遭一種語法變形繞過：https://forkast.news/postgres-mcp-pro-restricted-mode-bypass-exposes-the-gap-in-ai-database-security/

已查證事實：漏洞回報者於 2026 年 6 月 6 日在專案公開 issue 揭露問題，表示已在當時最新的 0.3.0 版確認；GitHub Advisory Database 則於 9 月 4 日發布 GHSA-cm87-gp55-7cgj，給予 CVSS v4.0 9.2 分與 Critical 等級。不過該筆 GitHub 紀錄仍標示為「Unreviewed」，受影響與已修補版本欄位也都是 Unknown，因此不能把「所有舊版皆受影響」或「已有正式修補版」當成確定事實。漏洞紀錄：https://github.com/advisories/GHSA-cm87-gp55-7cgj；原始回報：https://github.com/crystaldba/postgres-mcp/issues/178

運作機制：同一個函式，換位置就漏檢

受限模式不是只比對 SQL 字串，而是使用 pglast 把語句轉成抽象語法樹（AST），再由 safe_sql.py 遞迴巡覽節點。一般寫成 SELECT pg_read_file(...) 時，函式會成為 FuncCall 節點，名稱不在允許清單便遭拒絕；改寫成 SELECT * FROM pg_read_file(...) 後，外層卻成為 RangeFunction，內部的 FuncCall 藏在巢狀 tuple。原有巡覽邏輯沒有再拆開這一層容器，函式名稱檢查因而根本未被執行。

這不是典型的 SQL injection：系統原本就允許代理提交 SQL，問題在於授權判斷只涵蓋部分合法語法形狀。攻擊者沒有破解資料庫解析器，而是利用中介層與 PostgreSQL 對同一語句的理解落差。這也說明「成功解析」不等於「完整檢查」，允許清單若依賴 AST，安全性取決於驗證器是否遍歷每一種節點與巢狀結構。

為何現在值得注意

問題的關鍵不只是單一 Python 程式錯誤，而是 MCP 把自然語言、模型輸出、工具呼叫與高價值資料庫串成一條執行鏈。提示注入或遭控制的 MCP 用戶端一旦能影響 execute_sql，就可能把精心構造的合法 SQL 送到安全閘門。過去需要工程師直接操作的資料庫能力，現在可能由代理在背景、自動且多步驟地呼叫，審查窗口因此縮短。

作者觀點：「唯讀」常被誤解成完整安全邊界，其實主要保護資料完整性；讀取敏感資料屬於機密性問題，昂貴查詢還涉及可用性。把唯讀交易、AST 允許清單與逾時機制合稱為安全模式，容易讓部署者忽略三者防守的是不同風險。

實際影響，以及不能忽略的前提

若 MCP 所使用的 PostgreSQL 角色有權執行 pg_read_file，繞過後可讀取資料庫伺服器作業系統帳號能存取的檔案，可能包括設定檔、憑證或其他服務密鑰。這些資料若再被用於存取相鄰系統，便可能形成橫向移動；但這一段是風險推論，不是目前資料已證實發生的入侵事件。

同樣重要的是，漏洞不會憑空賦予 PostgreSQL 或作業系統權限。PostgreSQL 官方文件指出，pg_read_file 預設只允許超級使用者執行，也可另外授予 EXECUTE；預先定義角色 pg_read_server_files 則能讀取資料庫程序可及的檔案，官方並警告這類角色會繞過一般資料庫權限檢查，必須非常審慎授予。參見：https://www.postgresql.org/docs/current/functions-admin.html、https://www.postgresql.org/docs/current/predefined-roles.html

因此，CVSS 所列的「不需權限」應理解為對受影響介面的評分語境，不代表全球任何人都能直接讀取任意 PostgreSQL 主機。攻擊者仍須能接觸 MCP 服務或控制可呼叫它的代理，而且最終能讀到什麼，取決於資料庫角色、函式 EXECUTE 權限、容器掛載與主機檔案權限。這些條件會大幅改變每個環境的真實風險。

對台灣企業的意義

台灣企業常把 ERP、電商、製造排程、客服與內部分析資料集中在 PostgreSQL，再透過 AI 助理降低查詢門檻。此時真正危險的組合，是 MCP 直接連到既有應用程式帳號，而該帳號為了維運方便持有超級使用者、跨 schema、檔案讀取或過多監控權限。即使 MCP 只供內網使用，惡意文件、客服內容或網頁資料造成的間接提示注入，仍可能沿代理工具鏈抵達資料庫。

立即處置應以資料庫原生最小權限為核心：為 MCP 建立專用角色，只授予必要 schema、資料表與檢視表的 SELECT；確認未繼承 superuser、pg_read_server_files、pg_write_server_files 或 pg_execute_server_program；必要時以檢視表、欄位遮罩與列級安全縮小可見資料。MCP 端另應限制可連線的主機與代理、保存工具呼叫及 SQL 稽核紀錄，並對 pg_read_file、pg_read_binary_file、pg_ls_dir、pg_stat_file 等函式建立告警。

修補狀態與後續觀察指標

截至 2026 年 9 月 6 日，即時查核顯示修補用 pull request #200 仍為 Open。其方向是讓驗證器繼續展開 RangeFunction 內的巢狀 tuple，並加入危險函式應被攔截、允許函式仍可通過的測試；它尚未合併，就不能視為可部署的正式修補：https://github.com/crystaldba/postgres-mcp/pull/200

  • 專案是否合併修補、發布高於 0.3.0 的標籤與套件，並明確列出受影響版本。
  • GitHub Advisory 是否完成審查，補上 patched versions 與正式套件對應。
  • 修補是否涵蓋更深層 AST 容器、LATERAL、ROWS FROM、WITH ORDINALITY 等變體，而非只封鎖單一範例。
  • 企業是否能證明 MCP 帳號在資料庫拒絕檔案讀取，而不只是中介層宣稱「restricted」。
  • 稽核系統能否把使用者提示、代理決策、工具呼叫、實際 SQL 與回傳資料串成同一條事件鏈。

這起事件最值得留下的結論不是「MCP 不安全」，而是安全控制必須放在最接近資產的位置。提示規則、SQL 解析與受限模式都可降低錯誤率；真正能在解析器漏檢時止血的，仍是 PostgreSQL 原生權限、隔離後的執行環境與可追溯的稽核。

[Tempest Python Daily] 技術動態摘要 (2026-09-05) – 深度完整版

本期聚焦 Python 非同步執行環境與雲端開發平台更新，整理多核心運算、asyncio 設計、年度方案、PostgreSQL 15 與資料庫管理介面等重點。

TonIO：Python 多執行緒非同步執行環境

1. 非同步程式碼通常只使用單一核心

即使電腦配備多個處理器核心，傳統 Python 非同步程式碼通常仍只在單一核心上執行，未必能直接運用整台機器的平行處理能力。

2. 單核心運作是 asyncio 的設計選擇

這項限制並非 asyncio 的程式錯誤，而是其既有設計方式。理解這個前提，有助於工程團隊正確評估非同步 I/O 與多核心運算之間的差異。

3. 加速事件迴圈無法改變核心架構

即使持續提升事件迴圈的執行速度，也不會因此改變非同步程式碼只使用單一核心的基本架構；效能最佳化與多核心運用是兩個不同層次的議題。

4. TonIO 從執行環境層級重新思考問題

TonIO 被介紹為 Python 的多執行緒非同步執行環境，嘗試從底層設計重新處理非同步工作與多核心資源利用之間的關係。

5. 適合關注高併發伺服器的開發者

對正在研究非同步應用、高併發服務或伺服器效能的 Python 開發者而言，這項討論提供了事件迴圈最佳化以外的架構視角。原始連結：https://ift.tt/tsFywvq

PythonAnywhere：方案與資料庫功能更新

6. 系統更新已部署至歐盟與美國環境

PythonAnywhere 表示，最新系統更新已分別於 2026 年 6 月 23 日部署至歐盟系統，並於 2026 年 7 月 28 日部署至美國系統。

7. 新帳號可選擇年度方案

建立新帳號的使用者現在可以選擇年度方案，讓訂閱週期多了一項可用選擇。

8. 免費帳號升級時也能選擇年繳

既有免費帳號在升級時，同樣可以選擇年度方案，這項更新涵蓋新註冊與由免費方案轉換的使用者。

9. 平台新增 PostgreSQL 15

本次更新加入 PostgreSQL 15，使用 PythonAnywhere 建置應用程式的開發者多了一個可用的 PostgreSQL 版本選項。

10. 資料庫管理介面更易操作

PythonAnywhere 也調整了 Databases 頁面，目標是讓資料庫管理操作更容易完成。相關帳號、方案及資料庫功能更新可參考原始連結：https://ift.tt/Apf4yLe

當日重點回顧與行動建議

今日兩項消息分別觸及 Python 執行效能與部署環境管理。需要提升非同步服務資源利用率的團隊，可進一步了解 TonIO 的多執行緒執行模型；使用 PythonAnywhere 的開發者，則可檢查年度方案、PostgreSQL 15 與新版資料庫頁面是否符合目前的部署需求。

[Tempest Rust 深度解讀] 每月仍下載 47 萬次：被棄用的 PostgreSQL MCP Server 如何成為供應鏈風險 (2026-08-16)

這起事件真正值得注意的，不是有人用 Rust 重寫了一套 PostgreSQL MCP Server，而是一個已被棄用、直接持有資料庫連線能力的橋接元件，仍被大量下載。當企業開始讓 AI 代理查詢營運資料，這類看似只是「開發工具」的套件，實際上已進入資料存取與權限控管的核心。

棄用不等於停止使用

原始文章指出，@modelcontextprotocol/server-postgres 最後一次發版是在 2024 年 12 月，且截至 2026 年 8 月 9 日的三十天內仍有 475,790 次下載。這項特定區間數字來自作者，無法由靜態頁面完整重現；不過 npm 頁面確實將套件標示為不再支援，查證時顯示每週下載量仍達 126,780 次，足以交叉證明它並非乏人問津的舊專案。原文：https://dev.to/eszetael/rebuilding-the-deprecated-postgresql-mcp-server-in-rust-safe-by-default-1eb；npm：https://www.npmjs.com/package/%40modelcontextprotocol/server-postgres?activeTab=versions

必須避免把下載次數直接換算成企業數或正式環境數量：CI 重建、快取失效及重複安裝都會放大數字。但「棄用警告沒有使下載歸零」仍是可確認的事實，代表舊教學、既有設定與自動化流程可能持續把它帶進新環境。

真正的安全邊界在資料庫，不在套件名稱

MCP Server 位於模型與 PostgreSQL 之間：模型產生查詢，伺服器拿著資料庫憑證執行，再把結果送回模型上下文。其風險至少包含三類：查詢造成資料或系統狀態改變、昂貴查詢拖垮資源，以及資料列內的文字被模型誤當成指令。

原文聲稱舊版另以 startsWith("SELECT") 做字串檢查，但封存倉庫目前可查到的 v0.6.2 原始碼並沒有這一層：程式直接執行呼叫端提供的 SQL，只先開啟 BEGIN TRANSACTION READ ONLY，最後再 ROLLBACK。因此，原文對「字串守門」的描述不應視為已證實事實；可確認的問題反而是安全性幾乎全押在 PostgreSQL 的唯讀交易。原始碼：https://raw.githubusercontent.com/modelcontextprotocol/servers-archived/main/src/postgres/index.ts

這道防線不是毫無作用。一般的 INSERT、UPDATE、DELETE、DDL 與多數破壞性敘述會被 PostgreSQL 阻擋。然而官方文件也明確說明，這只是「高階概念上的唯讀」，不保證阻止所有磁碟寫入；序列的 nextval 或 setval 變化也可能不因交易回滾而復原。這足以支持「不能只依賴 rollback」的核心論點，但原文所列特定管理函式及 874 筆異動仍屬作者測試結果，尚非獨立稽核結論。官方文件：https://www.postgresql.org/docs/current/sql-set-transaction.html、https://www.postgresql.org/docs/current/functions-sequence.html

Rust 重建版賣的不是效能，而是縱深防禦

新專案 postgres-mcp-hardened 的商業與工程邏輯，是假設每一層都可能失效：先把 SQL 解析成語法樹，只允許限定的查詢結構；再由資料庫設定唯讀、低權限角色與回滾；用 statement_timeout 限制執行時間，並以 EXPLAIN 成本預估攔截過重計畫。結果資料則標示為不可信內容並跳脫分隔符，網路部署可加 OAuth，所有工具決策寫入雜湊串接的稽核紀錄。

這些機制與測試、模糊測試語料、SBOM、簽章發布等資料可在專案倉庫看到：https://github.com/Eszetael/postgres-mcp-hardened。但它們目前主要仍是維護者提出並自行驗證的安全主張，不等同第三方滲透測試或成熟產品認證。

為何現在值得注意

傳統資料庫工具通常由人輸入 SQL；代理式系統則可能自動組合工具呼叫、讀取資料後繼續採取行動。這使資料列本身也可能成為間接提示注入來源。MCP 官方安全指南同樣要求最小權限、隔離本機伺服器，並提醒本機 MCP 程序可能繼承客戶端權限：https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

作者觀點是：棄用套件的問題不只在「未來不會修補」，還在企業可能從未把它列入正式資產。套件若藏在個人 IDE、桌面 AI 工具或專案設定檔中，資安與 DBA 團隊甚至不知道多了一條通往資料庫的路。

容易忽略的限制

  • 重寫不會自動消除供應鏈風險，只是把信任移交給另一位維護者、另一組依賴與發布流程。
  • 語法樹允許清單與管理函式拒絕清單都可能有缺口；PostgreSQL 方言與擴充功能也會持續演進。
  • EXPLAIN 成本只是估計，低估的查詢仍需靠逾時、併發限制和資料庫資源治理收尾。
  • 將工具輸出標成不可信內容只是訊號；若 MCP 客戶端把標記攤平成普通文字，提示注入防線仍可能失效。
  • 專案仍在 0.1.x 階段，維護者也坦承外部實際資料驗證有限，不宜因「Rust」或測試數量就直接認定可上正式環境。

對台灣團隊的實際意義

台灣企業不必先決定要不要採用這個 Rust 版本；更急迫的是把 MCP 納入既有資料庫治理。盤點 IDE、桌面代理、容器映像與 CI 設定中的 MCP 套件；停用棄用版本；為代理建立獨立、不可寫且不得持有超級使用者或 BYPASSRLS 的角色；限制可讀 schema、資料表與敏感欄位；設定查詢逾時、列數、併發及網路邊界；正式替換前以真實查詢樣本做壓力與對抗測試。

尤其金融、電商、製造與 SaaS 團隊，應把「唯讀」拆成三個問題：能否改變狀態、能讀到哪些資料、讀取行為是否可追溯。唯讀交易主要回答第一題，不能取代欄位授權、資料遮罩與稽核。

後續觀察指標

  • 棄用套件的每週下載量是否下降，以及舊教學與範例是否完成替換。
  • Rust 重建版是否出現獨立安全稽核、外部部署案例與可重現漏洞報告。
  • 對抗測試語料是否持續擴充，曾經放行的 SQL 是否永久加入回歸測試。
  • 提示注入標記能否被主流 MCP 客戶端保留，而非降格成普通文字。
  • 企業能否用資料庫端紀錄證明代理始終使用最小權限角色，而不是只相信 MCP Server 自稱「safe by default」。

[Tempest Rust Daily] 技術情報精華 (2026-08-16) – 深度完整版

本期整理 8 則 Rust 技術動態，涵蓋桌面應用、系統程式語言、虛擬機器、編譯效能、並行伺服器、資料庫工具與資安掃描器。

以 Rust 與 Tauri 打造輕量提詞及面試輔助工具

HackySack 是一款採用 Tauri 與 Rust 開發的原生桌面應用，定位為輕量化的提詞器及面試輔助工具。它能以浮動視窗呈現在畫面上，並主打不出現在螢幕分享內容中；專案採免費 BYOK 模式，讓使用者自行提供 AI 服務金鑰。

原文連結：https://ift.tt/YartDBy

以 Rust 實作新系統程式語言 Cyrus

Cyrus 是一款以 Rust 完整實作編譯器的新程式語言，採嚴格命令式設計並聚焦低階系統開發。其目標是在保留 C 語言細部控制能力的同時，提供較現代化的開發體驗，適合關注語言設計、編譯器與系統程式設計的工程師參考。

原文連結：https://ift.tt/e4T7Pir

Metalogos 堆疊式虛擬機器的 Rust 架構設計

這篇文章深入介紹 Metalogos 的堆疊式虛擬機器架構，包括 44 條指令、兩套執行後端，以及透過型別系統達成的零成本安全機制。專案由 30,500 行 Rust 程式碼構成，嘗試讓 XSS 與 SQL Injection 等問題在編譯期成為錯誤，並利用雙後端交叉檢查程式執行結果。

原文連結：https://ift.tt/MSCYbNk

Rust 安裝問題與環境設定排查

一名使用者依照《The Rust Programming Language》官方指南安裝 Rust 後仍遇到問題，因而尋求社群協助。這類案例可作為安裝流程與環境設定排查的參考，尤其適合正在 Windows 平台建立 Rust 開發環境的初學者。

原文連結：https://ift.tt/qL4p8kY

三項 Cargo 與編譯器最佳化技巧

這支影片介紹三項可改善 Rust 編譯時間的 Cargo 與編譯器最佳化方式，並說明建置時間的主要耗用環節、各項調整的運作原理，以及哪些功能需要使用 Nightly Rust。影片標題主張可將編譯時間降低 50%，實際成效仍會依專案結構與建置環境而異。

原文連結：https://www.youtube.com/watch?v=vFp4IbC2aZ0

並行網路伺服器系列：Rust 的解法

「Concurrent Servers」系列第七篇將焦點轉向 Rust，探討如何運用 Rust 處理前幾篇提出的並行網路伺服器挑戰。內容適合想比較不同程式語言並行模型，或了解 Rust 如何應用於網路服務實作的讀者。

原文連結：https://ift.tt/WVKX8AJ

以 Rust 重建已棄用的 PostgreSQL MCP Server

文章探討如何以 Rust 重建已標示棄用的 PostgreSQL MCP Server，並將「預設安全」納入核心設計。原套件最後一次發布是在 2024 年 12 月 4 日；儘管已不再受支援，截至 2026 年 8 月 9 日前的 30 天內仍有 475,790 次下載，反映替代實作與安全維護的需求。

原文連結：https://ift.tt/6IEh2CV

CipherRun：Rust 打造的 TLS／SSL 資安掃描器

CipherRun 是一款使用 Rust 開發的 TLS／SSL 資安掃描器，主打高速、模組化與可擴充性。對藍隊工程師、安全研究人員，以及需要檢視 TLS／SSL 設定的開發團隊而言，這項工具提供了一個以 Rust 實作的掃描方案。

原文連結：https://ift.tt/ycwuMvK

[Tempest Agent Insights] 技術趨勢 (2026-07-18)

今日 97 篇 Agent 相關文章顯示，產業焦點正從模型能力轉向可控執行環境、長期狀態、企業治理與實際工作流程。以下整理 10 項值得工程與產品團隊關注的趨勢。

1. Agent 安全核心移向「動作邊界」

Agent 在分類、摘要與提出建議時，風險仍局限於系統內部；一旦跨越動作邊界，開始寄信、修改工單、更新部署或發布內容，就會產生外部影響。實務設計應在工具呼叫與寫入操作前加入權限檢查、範圍限制、人工核准及稽核紀錄，不能只依賴提示詞約束。[https://ift.tt/SFbZlXn]

2. Agent 沙箱與護欄成為新一輪基礎建設投資重點

Runta 主打限制 Agent 可存取的檔案、資源與消費權限，完成由 a16z 領投的 2,000 萬美元募資，文章並稱其估值超過 1 億美元。Perplexity 則推出 SPACE 沙箱執行環境，用於支援 Computer 工作階段及可持續運作的 Agent 任務。兩者共同反映市場正把隔離、權限與執行階段控制視為正式產品層。[https://ift.tt/sNcfm2V] [https://ift.tt/WyAEcxd]

3. 自主攻擊能力使端點與工具權限風險升高

一篇報導援引 Sysdig 紀錄，指出 AI Agent 已能在沒有人持續操作鍵盤的情況下執行完整勒索軟體攻擊流程；CrowdStrike Field CTO 也警告，遭入侵的 Agent 可能放大「就地取材」攻擊的危險性。企業需將 Agent 使用的憑證、系統工具與網路存取納入最小權限、行為監控及快速撤銷機制。[https://ift.tt/V8Jzo7E] [https://ift.tt/bh9XyDc]

4. 雲端平台開始原生支援 Agent 全生命週期

阿里雲在 WAIC 2026 發表 Agent Native Cloud，定位為專為企業 Agent 擴充而設計的雲端架構。Google Cloud 則釋出 13 個 Gemini Enterprise Agent Platform 實作範例，涵蓋 Agent 的建置、擴充、治理與最佳化。平台競爭正從單一模型 API，延伸至部署、治理、觀測與營運的一體化能力。[https://ift.tt/y5S43KA] [https://ift.tt/XSQbhWK]

5. 開放模型 Agent 進入本機程式碼與文件工作流程

LM Studio 推出獨立桌面應用程式 Bionic，讓使用者以開放模型處理程式碼庫、研究、文件及檔案任務，並區分 Work Projects 與 Code Projects。這代表本機模型工具正由聊天介面走向可操作專案資源的桌面 Agent，同時提供資料留在裝置端的另一種部署選項。[https://ift.tt/njO6yfQ]

6. 可重用 Skills 正取代大量客製化 Agent 邏輯

Microsoft Agent Framework 的 Agent Skills for Python 已進入穩定版，允許 Agent 依任務載入由指令、參考資料與腳本組成的領域能力包。這種按需載入方式有助於減少固定塞入提示詞的內容，並讓領域知識能以模組化方式進行版本管理、測試及跨 Agent 重用。[https://ift.tt/LRv9ec6]

7. 長期 Agent 的競爭焦點轉向狀態與受治理記憶

多篇文章指出，僅保存聊天紀錄或將文件放進向量資料庫，無法完整處理長期 Agent 的記憶需求。工程問題已轉為哪些資訊應保留、由誰更新、何時失效，以及如何追蹤工作狀態。Agent 基礎建設也因此逐漸在狀態層分流，形成專門管理持久工作紀錄的元件。[https://ift.tt/IgsKTHG] [https://ift.tt/gkstF3Q]

8. Durable workflow 可直接建立在 PostgreSQL 上

resonate-pg 嘗試將執行協調、佇列與排程能力收斂到既有資料庫，以一份 1,351 行的 PL/pgSQL 檔案實作 Resonate Server，適用於 PostgreSQL 16 以上版本。對已使用 Supabase 或 PostgreSQL 的團隊而言，這提供了減少額外協調服務的架構方向，但仍需評估資料庫負載、故障隔離與維運責任。[https://ift.tt/sNuSty3]

9. Agent 評測走向多情境與應用專屬測試

OmniaBench 聚焦一般型 Agent 在多種情境下理解需求、呼叫工具與完成互動任務的能力；Copy-on-Write Scoring 則著重應用專屬工作流程，試圖更細緻地定位 Agent 成功與失敗的環節。實務上，團隊可將規則斷言、LLM-as-a-judge 與真實工作流程測試組合使用，避免只看單一整體分數。[https://ift.tt/7CorqUX] [https://ift.tt/KC2tYer] [https://ift.tt/NBWH3n7]

10. 醫療 Agent 的最後一哩路是合規傳輸與網路隔離

醫療 Agent 即使能讀取病歷並草擬追蹤訊息，在實際傳送受保護健康資訊時仍可能破壞 HIPAA 合規。相關文章強調，除了靜態加密、存取控制、稽核紀錄與商業夥伴協議，網路層設計及訊息傳輸路徑同樣不可忽略；僅將元件放入 VPC 並不足以回答所有資料外洩與權限問題。[https://ift.tt/woGVb6U] [https://ift.tt/tzVdfaw]

今日觀察

Agent 產品化的主要瓶頸已不只是推理品質，而是能否安全地執行動作、保存可治理的狀態、通過應用情境評測，並整合企業既有的權限與合規機制。近期值得優先投入的工程能力包括沙箱執行、最小權限、持久工作流程、記憶生命週期及端到端稽核。

[Tempest Rust Daily] 技術情報精華 (2026-07-10) – 深度完整版

本期焦點

1. Bun 用 11 天從 Zig 改寫至 Rust，背後是 Claude Fable 5 AI 的全力加持

Bun 的創建者 Jarred Sumner 發布了一篇詳細的技術文章，說明他如何在短短 11 天內，藉助預發布版 Claude Fable 5 與 Claude Code，獨自完成 Bun 執行期（runtime）從 Zig 到 Rust 的完整改寫。這項工程若以人力完成，估計需要三名對程式碼庫有完整背景知識的工程師耗費約一年時間。Bun 已於 2025 年 12 月被 Anthropic 收購，此次改寫的 Claude Fable 5 API 費用約為 165,000 美元。原文：[https://ift.tt/rtKWhMu]

2. Bun Rust 改寫啟示錄：AI 輔助大規模程式碼遷移的意義

《The Pulse》深度分析此次 Bun 以 165,000 美元完成 Zig 到 Rust 遷移的商業與技術意義。相較於三名資深工程師一整年的人力成本，此 API 費用極具競爭力。文章也討論了 Bun 1.4 Rust 版本的穩定性、社群信任問題，以及這個案例對整體軟體工程模式的啟示。原文：[https://ift.tt/1xnrcIA]

3. Rust 1.97.0 正式發布：預設啟用 v0 符號修飾方案

Rust 1.97.0 於 2026 年 7 月 9 日正式發布。最重要的改變是 v0 符號修飾（symbol mangling）方案正式成為預設選項，取代原先沿用自 Itanium ABI 的舊方案。此版本同步穩定化 Cargo 的 build.warnings 組態設定，開發者現在可在 CI 流程中強制執行 lint 規則，且不會破壞建置快取。更新指令：rustup update stable。發布公告：[https://ift.tt/LwYRb6O]

4. pgrust：用 Rust 改寫的 PostgreSQL，通過全部 46,000 項回歸測試

pgrust 是一個以 Rust 重寫的 PostgreSQL 資料庫實作，目標對齊 PostgreSQL 18.3，並已通過超過 46,000 條回歸查詢測試，達到完整相容。pgrust 在磁碟格式上與 PostgreSQL 18.3 相容，可直接從現有的 Postgres 18.3 資料目錄啟動，目標是讓 Postgres 更易於嵌入且降低整體架構複雜度。原文：[https://ift.tt/nPy7IjA]

5. 用 Rust 與 ClickHouse 解析 5GB Apple Health XML 資料

iPhone 健康資料匯出後動輒超過 5GB 的 XML 檔案，對 Python ElementTree 或 pandas 而言是一大記憶體考驗。這篇實務文章介紹如何使用 Rust 建構高效能 Apple Health 資料解析器，搭配 ClickHouse 進行儲存與分析，在記憶體使用效率與解析速度上均大幅超越 Python 方案。原文：[https://ift.tt/iuc6pxM]

6. This Week in Rust #659

本週 Rust 社群週報第 659 期，彙整本週最值得關注的函式庫更新、RFC 討論、部落格文章以及社群活動。適合想快速掌握 Rust 生態系動態的讀者定期追蹤。原文：[https://ift.tt/gSsJziQ]

7. smallvec：被嚴重低估的 Rust crate

smallvec 是一個讓向量在堆疊（stack）上儲存少量元素、超出容量後才移至堆積（heap）的 crate。在許多實務場景中，它能顯著降低記憶體配置開銷，特別適合嵌入式系統或高效能服務開發。作者認為這是 Rust 生態系中被低估最嚴重的 crate 之一。原文：[https://ift.tt/U9Xz3qx]

8. hot-lib-reloader：不重啟應用程式即時重載 Rust 程式碼

hot-lib-reloader 是一個 Rust 開發工具，讓你在不停止執行中程式的情況下即時修改並重載函式，實現「即時程式設計」（live programming）的體驗。它基於 libloading crate 實作，大幅縮短開發迭代週期，特別適合需要快速驗證邏輯的情境。原文：[https://ift.tt/IFgHMZo]

9. AppCUI-rs：快速跨平台 Rust TUI 函式庫

AppCUI-rs 是一套快速、跨平台的 Rust 文字介面（TUI）函式庫，提供低階主控台引擎處理輸入、色彩與渲染，並附帶豐富的現成控制元件工具包，包括彈性版面配置、選單、工具列以及多種預設主題，適合建構現代化終端機應用程式。原文：[https://ift.tt/TKbODX2]

10. pon：以 Rust 實作的 Python 3.14 JIT／AoT 原生編譯器

pon 是一個以 Rust 實作的 Python 3.14 JIT 與 AoT 原生編譯器及執行期，採用 Cranelift 後端、ruff 解析器、Green Tea GC，並透過位元組精確（byte-exact）差異測試確保與 CPython 的行為一致性。此專案展示了 Rust 在語言工具鏈實作上的強大潛力。原文：[https://ift.tt/oATz7Rm]

11. CO2：為 C 語言加入 Rust 互通特性的超集語言

CO2 是一個向後相容 C 語言的超集語言，加入了 Rust 互通（interop）特性，使用 cargo 作為建置系統，並支援 cargo test、cargo doc、cargo miri 等常見 Cargo 指令。對於需要在既有 C 程式碼庫中逐步引入 Rust 特性的開發者，這是一個值得關注的實驗性方案。原文：[https://ift.tt/xEFMjIB]

12. 安全公告：CVE-2026-58266 — Anki 25.09.3 及以下版本 Rust 後端資訊揭露漏洞

CVE-2026-58266 影響 ankitects Anki 25.09.3 及以下版本的 Rust 後端元件，被評估為「有問題（problematic）」等級的資訊揭露漏洞，已收錄至 Nessus ID 325690。使用 Anki 的開發者與終端使用者應留意相關安全更新。詳情：[https://ift.tt/Eqcy1vQ]