ASF董事Justin Mclean：只用開源卻不參與，企業恐承擔更高風險

來源：https://www.ithome.com.tw/news/176433

「如果問題是『企業是否該使用開源？』，其實早就有答案了，因為你已經在使用了」，Apache Software Foundation（ASF）董事Justin Mclean在Computex一場論壇活動中說。他認為真正值得思考的問題是，誰在決定這些技術的未來方向，而你的企業是否參與其中，「這正是使用開源與參與開源之間的差別」。

在他看來，企業最該問的不是採用開源與否，而是選擇成為被動的使用者，還是積極參與的貢獻者。當開源已成為AI與數位基礎設施的核心，後者正逐漸成為企業降低技術風險的重要能力。

將開源視為免費且低風險是種危險的誤解

Justin指出，開源軟體過去或許只是可以隨時替換的工具，但如今已逐漸演變成企業核心基礎設施的一部分。企業可以在幾個月內更換一套應用程式，但很難在短時間內替換底層的資料平臺、AI框架或雲端架構。當企業業務愈來愈依賴這些開源技術時，與開源專案的關係也從單純採購關係，轉變為長期依存關係。

Justin直言，許多企業將開源視為免費且低風險的選項，這其實是一種危險的誤解。「開源讓人感覺是免費的，也讓人感覺是安全的，但事實上兩者都不是（Open source feels free and it feels safe. It is neither.）」。

他指出，當企業將開源視為關鍵基礎設施，卻從未參與相關社群時，不僅無法影響技術發展方向，也難以提前掌握重大變化，反而可能承擔更高的技術與營運風險。 當關鍵功能調整、架構改版或維護策略改變時，企業往往只能被動接受結果。

「如果你從不參與自己依賴的開源專案，那麼產品路徑圖將由其他人的需求決定，而不是你的需求」，Justin表示。

開源最大的風險不是程式碼，而是治理

Justin Mclean指出，許多人認為開源專案的成功來自優秀的技術，但他在Apache Software Foundation超過十年的經驗卻看到另一個事實。

「軟體吸引用戶，社群創造永續（Software attracts users. Communities create sustainability）。」

真正讓專案能夠持續演進的，不是程式碼本身，而是願意維護、貢獻與傳承知識的人。當原始開發者離開、技術環境改變時，只有健全的社群才能讓專案持續發展。

他認為，企業若將關鍵系統建立在這類專案之上，卻從未與社群建立連結，就可能在風險發生時毫無應變能力。

從消費者變成參與者，才能獲得影響力

Justin指出，參與開源社群並不只是出於公益精神，而是一種商業策略。

企業投入開源社群後，除了能夠提前掌握技術演進方向，也能與核心維護者建立關係，甚至對專案未來路徑圖產生影響力。對於高度依賴特定開源技術的企業而言，這種影響力往往比節省授權費用更具價值。

他以開源資料湖格式Apache Iceberg為例說明。該專案最初由Netflix推動，如今包括Amazon、Google、Apple及Snowflake等競爭的企業都投入貢獻。這些企業參與的原因並非出於善意，而是希望共同影響一項產業標準的發展方向，確保自身業務需求能被納入考量。

「最能從開源獲益的企業，不是使用最多開源軟體的企業，而是積極參與並塑造開源專案的企業」，Justin表示。

AI時代，開源參與將成為企業競爭力的一部分

隨著生成式AI快速普及，Justin認為這項議題的重要性只會進一步提高。從模型框架、訓練工具到資料基礎設施，AI產業幾乎完全建立在開源技術生態之上。

因此，企業若希望在AI時代維持技術競爭力，就不能只把開源當成現成可用的資源，而應思考如何參與自己所依賴的開源社群。即使只是回報問題、參與討論、改善文件或分享實務案例，都能逐步建立與社群的連結。

Justin強調，企業不需要一開始就投入大量工程人力成為核心維護者，但至少應該跨出第一步。因為當開源已成為數位基礎設施的一部分時，企業所面對的問題已不再是是否使用開源，而是是否願意參與並共同塑造其未來發展方向。

'

部分App內嵌Bright Data SDK，讓手機與智慧電視成為第三方網頁爬蟲代理

來源：https://www.ithome.com.tw/news/176437

資安公司Include Security揭露，部分消費者App可能透過Bright Data的SDK，在取得使用者同意後，讓手機或智慧電視成為住宅代理（Residential Proxy）網路的一部分，協助第三方客戶透過一般家庭IP執行網頁資料抓取。研究人員指出，該功能可用於蒐集公開網頁資料，並可能支援AI模型訓練、檢索或搜尋等用途。

Bright Data是一家資料蒐集與代理網路服務業者，對外銷售住宅代理網路存取能力，作法是讓網頁抓取流量不再從資料中心IP送出，而是經由一般寬頻或行動網路用戶的IP連線到目標網站。由於許多網站會限制或封鎖已知雲端資料中心IP，住宅代理成為網頁爬蟲業者避開封鎖的一種方式。

部分App開發者會在應用程式內嵌入SDK，使用者若同意App內與Bright Data相關的說明或選項，裝置就可能成為代理出口。研究者逆向分析iOS版Bright Data SDK，並觀察30天的執行流量發現，SDK啟動後會取得遠端設定檔，接著建立到Bright Data相關網域的WebSocket連線，回報裝置是否連上Wi-Fi、電量、CPU與記憶體使用率與SDK版本等資訊。當裝置狀態符合條件時，伺服器可派送網頁抓取工作，由該裝置透過使用者家中的網路連線送出請求。

除了智慧電視，研究者也在iOS版SDK發現額外的檢測可視性問題。SDK可使用Apple提供的網路介面指定機制，讓部分代理流量直接走Wi-Fi或行動網路介面，而不是依照系統預設路由，因此即便使用者開啟VPN，也不一定能攔截該連線。

以PlayWorks為例，研究者指出，部分合作發布商會在隱私權政策中揭露與Bright Data的關係，但對智慧電視使用者而言，隱私權政策文件未必是有效的告知方式。智慧電視通常透過遙控器操作，使用者不易在電視畫面上閱讀完整法律文件，也未必能理解第三方客戶可能透過自己的家庭網路執行網頁抓取。

想降低風險的家庭或企業，可在DNS或網路閘道層封鎖Bright Data SDK相關網域，但該作法只適用於會經過網路邊界的流量，受管裝置則可掃描是否存在特定SDK符號。研究者同時提醒，公開設定檔中的合作夥伴名稱，只能證明整合可能曾經存在，不能直接推論特定App目前仍在正式版本中搭載SDK。

'

微軟遭遇Miasma蠕蟲供應鏈攻擊，73個儲存庫在2分鐘遭到停用

來源：https://www.ithome.com.tw/news/176432

上週惡意程式Miasma接連攻擊許多NPM套件，涵蓋Red Hat雲端服務相關套件、用於串接LLM框架Ollama與雲端AI網頁程式開發平臺Vercel AI的ai-sdk-ollama，以及由Vapi推出的AI語音助理軟體開發套件（SDK）vapi-ai/server-sdk，不過值得留意的是，這波攻擊似乎仍在進行，而且導致GitHub停用一系列微軟Azure的儲存庫。

資安社群平臺OpenSourceMalware發布部落格文章表示，GitHub於6月5日停用了微軟73個儲存庫，用戶存取這些儲存庫只會看到此儲存庫已被停用的訊息，宣稱儲存庫違反GitHub服務條款，使得該公司停用存取權限。OpenSourceMalware指出，由於這些儲存庫分布於Azure、Azure-Samples、microsoft、MicrosoftDocs等4個微軟的GitHub帳號，停用的時間都集中在世界協調時間（UTC）16時0分50秒至16時2分35秒，這代表上述現象是GitHub自動化偵測機制執行，同時將所有儲存庫標記為有問題並停用。

從儲存庫的數量來看，Azure帳號經營的儲存庫最多，有49個，而且大部分與Azure Functions開發團隊的相關專案有關。但真正引起研究人員注意的部分，是另一組被稱為Durable Task家族的工具，所有的儲存庫也遭到停用，OpenSourceMalware強調，這些專案與儲存庫才是本次事故攻擊者的主要目標。值得留意的是，Durable Task並非首度遭到入侵，相關活動最早可追溯到5月19日，當時駭客團體TeamPCP於PyPI上架3個有問題的Azure Durable Task SDK套件，他們濫用竊得的GitHub Actions機密資料而得逞。

雖然5月19日的事故是TeamPCP所為，不過OpenSourceMalware根據6月1日Aikido與OX Security公布的Miasma活動，指出與另一個相關蠕蟲Mini Shai-Hulud最顯著的差異，就是Miasma加入了Azure與GitHub的憑證收集能力，再加上微軟儲存庫受害的特徵相同，駭客都是透過蠕蟲程式建立公開的GitHub儲存庫，並使用JSON檔案提交竊得的帳密資料，而且這些存放憑證的儲存庫，其描述都是：Miasma: The Spreading Blight，因此OpenSourceMalware推測，這起事故很可能就是Miasma造成。

'

惡意程式Miasma藉由六階段攻擊流程竊取開發環境各式憑證

來源：https://www.ithome.com.tw/news/176427

上週惡意程式Miasma攻擊Ai-sdk-ollama、@vapi-ai/server-sdk等AI工具NPM套件受到關注，多家資安公司揭露有關調查結果，指出駭客使用了最新手法Phantom Gyp，躲過大部分掃描工具的檢測。其中資安公司OX Security指出，這次的攻擊流程變得更加複雜，駭客利用多達15種惡意酬載來挖掘受害者資料。

OX Security強調，一般的NPM供應鏈攻擊流程多半為3個階段，但這次活動多達6個階段。值得留意的是，駭客在Miasma載入工具進行了混淆與加密兩種手法進行雙重處理，首先，採用Phantom Gyp手法執行binding.gyp之後，會執行index.js，解開經混淆處理的酬載，接著，再透過第二階段處理經加密的酬載，然後感染受害電腦（第三階段）。

接著，在第四階段裡，惡意程式載入工具一口氣卸下15種惡意酬載及檔案，藉此於受害電腦截取記憶體內容、使用Bun指令安裝權杖（token）監控工具、與Claude進行掛鉤（hook），以及從GitHub下載新的惡意程式載入工具並執行。此惡意程式載入工具會從GitHub搜尋特定的關鍵字，然後下載另一個酬載並執行setup.py，並下載新的酬載及執行index.js，然後再進行類似第一、二階段解密有效酬載的行為。

'

惡意程式Miasma透過新型態手法Phantom Gyp發動攻擊

來源：https://www.ithome.com.tw/news/176426

6月3日惡意程式Shai-Hulud變種Miasma發動新一波供應鏈攻擊，駭客入侵57個NPM套件，上傳超過286個惡意版本，其中包含了Ai-sdk-ollama與Vapi的AI語音助理軟體開發套件（SDK），引起多家資安公司提出警告，其中一家資安公司StepSecurity指出，這次的攻擊手法與兩天前針對紅帽的事故相當不同，駭客使用了全新攻擊手法Phantom Gyp，他們利用一個僅有157位元組的檔案．而非一般資安工具會掃描的安裝指令碼，藉此逃過大部分生命週期掃描工具的偵測，另也追蹤到，資料外洩路徑指向GitHub帳戶liuende501。

另一家資安公司Wiz也對這種手法進行分析，先前駭客是將惡意程式碼注入package.json，而這次的手段是指令延伸，藉由名為binding.gyp的檔案，使得惡意套件在進行設定的過程裡，會在背景執行經過處理的混淆安裝程式。Wiz解釋，這種手法的原理是，只要套件套件根目錄存在binding.gyp，且package.json在沒有指定自訂安裝指令碼install或preinstall，NPM就會執行node-gyp rebuild，解析binding.gyp內容，並在主機的shell執行任意的命令表達式。

'

微軟揭露代理式AI新興風險，建議以SBOM盤點AI代理元件

來源：https://www.ithome.com.tw/news/176436

隨著企業開始將AI代理導入正式營運流程，相關資安風險與攻擊面也同步擴大。近期微軟彙整過去12個月針對已部署代理式系統進行紅隊測試的經驗，將《代理式AI系統失效模式分類》（Taxonomy of Failure Modes in Agentic AI Systems）文件更新至2.0版，新增7類代理式AI系統失效模式。

微軟建議，企業的AI代理應用涉及正式營運資料（production data）或外部介面時，應將其中4類新興風險列為必要測試類別：目標劫持（Goal Hijacking），這是指對抗性指令表面上符合合法任務流程，實際卻暗中改變AI代理的最終目標；電腦使用代理（Computer Use Agent，CUA）視覺攻擊，則是利用人眼無法辨識的內容，例如極小字體、隱藏在視窗外的介面元素，或圖片中的提示注入，影響AI代理的判斷結果。

其餘兩類則是工作階段上下文污染（Session Context Contamination），以及能力與架構揭露（Capability / Architecture Disclosure）。前者是攻擊者在多步驟工作階段早期置入資料，使代理在後續推理受到影響，但單一步驟未必會觸發安全控管；後者則是AI代理外洩工具名稱、系統提示結構、記憶介面，或觸發人工介入審核（Human-In-The-Loop，HitL）的邏輯，讓攻擊者能從原本的黑箱測試進一步推導系統內部運作，發動更具針對性的白箱攻擊路徑。

至於緩解措施方面，微軟說明企業應比照軟體供應鏈管理模式，為AI代理建立軟體物料清單（SBOM），完整盤點其使用的外掛、MCP伺服器、提示模板、工具描述，以及程式碼相依元件，並將可能影響AI代理決策與行為的自然語言工具描述，納入版本控管、變更追蹤與安全審查流程。

'

eBPF基金會推動eBPF安全稽核，強化雲端原生底層技術安全

來源：https://www.ithome.com.tw/news/176431

Linux基金會旗下、推動eBPF生態發展的eBPF基金會揭露eBPF安全強化進展，說明該組織在開源安全計畫Alpha-Omega支持下，透過外部安全評估與執行階段（runtime）強化，改善eBPF技術堆疊的安全防護。

eBPF是源自Linux核心的技術，可讓通過驗證的沙箱程式在Linux核心安全執行，常用於高效能網路、可觀測性、安全監控與效能分析。隨著eBPF逐漸成為雲端原生與資安工具的重要基礎技術，eBPF基金會指出，其安全模型高度仰賴執行在Linux核心的驗證器（kernel verifier），以及各硬體架構專屬的即時編譯器（Just-in-Time compiler，JIT）是否正確運作。

這次精進eBPF安全性的工作，分為兩大主軸。第一項是由STAR Labs主導的外部安全評估，聚焦eBPF的JIT後端與驗證器之間的互動。評估涵蓋x86-64與arm64 eBPF JIT編譯器，並分析驗證器與JIT後端之間的共用假設。初步結果顯示，研究人員並未在x86-64、arm64或riscv64的JIT實作本身當中，發現獨立安全漏洞，但也確認eBPF安全性不只取決於JIT，驗證器正確性同樣關鍵。

截至目前，這項評估共發現14項問題，包括8項高風險、2項中風險與4項低風險問題。相關問題涵蓋驗證器繞過、記憶體與指標洩漏、可能造成記憶體毀損的競爭條件，以及影響驗證器行為的阻斷服務問題。其中2項低風險問題已在上游完成修補，其餘問題仍在揭露與修補流程中。

第二項工作，聚焦改善核心位址清理器（Kernel Address Sanitizer，KASAN）對於經JIT編譯的eBPF程式的支援。KASAN是用於偵測越界存取與釋放後使用等記憶體安全錯誤的工具，eBPF基金會表示，相關工程仍在開發中，目標是將KASAN涵蓋範圍延伸至經JIT編譯的eBPF執行路徑，強化eBPF程式經JIT轉譯後，在核心執行路徑中的記憶體錯誤偵測能力。

'

研究人員揭露Hugging Face Transformers高風險RCE漏洞

來源：https://www.ithome.com.tw/news/176430

資安業者Pluto Security近日揭露Hugging Face旗下函式庫Transformers存在一項遠端程式碼執行漏洞CVE-2026-4372。駭客只需於模型設定檔config.json中植入特製欄位，即可在使用者載入模型時執行任意程式碼，甚至繞過Hugging Face長期以來作為安全防線的trust_remote_code=False機制。

Hugging Face成立於2016年，是目前全球最大的AI模型分享平臺之一。旗下以Python打造的開源函式庫Transformers為AI模型的通用載入工具，開發者可透過它從Hugging Face Hub取得並載入Meta的Llama、Google的Gemma或Mistral等各種模型，讀取模型設定檔config.json，組裝模型架構並執行文字生成、摘要、翻譯、問答等任務。迄今Transformers在Python套件庫PyPI上的累計下載量已超過22億次，顯示它是AI開發社群廣泛使用的核心工具之一。

研究人員指出，CVE-2026-4372漏洞源自於Transformers載入模型時會先讀取config.json，並將其中欄位寫入內部組態物件。駭客可在config.json中加入名為_attn_implementation_internal的特殊欄位，讓Transformers誤以為需要載入外部Kernel套件，進而從Hugging Face Hub下載並匯入駭客所控制的Python程式碼。

更嚴重的是，整個攻擊過程並不需要使用者手動執行惡意程式，也不會跳出警告。只要使用者透過Transformers載入遭植入惡意設定檔的模型，攻擊者就可能在背景執行任意程式碼，並取得該載入程序所擁有的使用者權限，讀取本機檔案、環境變數、雲端服務憑證、SSH私鑰、Kubernetes設定檔或資料庫連線資訊等。

CVE-2026-4372最受關注之處在於，它繞過了Transformers原本用來限制遠端程式碼執行的trust_remote_code安全機制。研究人員解釋，trust_remote_code限制的是模型自帶程式碼，但該漏洞改走Kernel載入路徑，因而避開了該防線。

CVE-2026-4372影響Transformers 4.56.0至5.2.x版本，且環境中已安裝kernels套件時才可利用。Hugging Face已於2026年3月4日發布Transformers 5.3.0修補漏洞，將非官方Kernel載入也納入trust_remote_code控管。

'

Redis 8.8補齊陣列資料結構，內建限流與串流訊息釋放機制

來源：https://www.ithome.com.tw/news/176428

Redis發布開源版Redis 8.8，該版本新增通用Array資料結構，並把限流計數與串流訊息NACK納入內建能力，也替有序集合的聯集與交集操作加入COUNT聚合器。官方說明，Redis 8.8改善多項操作效能，涵蓋字串、Hash、Streams、Sorted Set、Bitmap、HyperLogLog與掃描類命令，並強化持久化與複寫完整同步速度。

Redis終於補上原生陣列（Array）資料結構。過去開發者雖可用List、Hash或JSON等方式處理類似陣列的資料，但Redis 8.8新增的Array是以數字索引存取字串值的通用容器，可動態增減，也可支援稀疏索引。官方提到，Array適合用於需要快速依索引或索引範圍讀寫、保留近期資料的滑動視窗、伺服器端區間聚合與搜尋等情境，像是近期記錄保存、即時感測資料、金融報價或日誌資料處理。

Redis 8.8加入Window Counter Rate Limiter。過去常見的Redis限流設計，多半需要Lua腳本搭配客戶端邏輯，而新版提供INCREX命令，可在計數遞增時處理上限、下限與過期時間，並回傳新的計數值與實際套用的遞增量，讓固定窗口或滑動窗口等限流實作，可更直接地由Redis命令處理。

在串流資料處理方面，Redis 8.8新增XNACK命令。由於串流系統通常會由多個程式分工處理訊息，要是其中一個程式讀取訊息後無法完成處理，過去這筆訊息可能會先留在待處理清單中，其他程式需要再透過回收機制接手，而在新版機制，讓處理失敗的程式主動釋放訊息，使其更快交由其他程式重新處理。

其他更新包括雜湊資料的欄位層級通知，讓系統可接收個別欄位更新、刪除與過期事件，而時間序列資料查詢可在一次命令中同時計算多種聚合結果，減少重複查詢。JSON浮點數陣列可指定不同精度的浮點數格式，例如BF16、FP16、FP32或FP64，以便在記憶體用量與數值精度之間取捨。

官方也在效能上有所著墨，包括一次讀取多筆字串資料時，在啟用輸入輸出執行緒的情況下吞吐量最高提升68%；串流資料在一次讀取100筆資料的條件下，吞吐量最高提升83%。另外，部分有序集合操作效能最高提升74%，以及持久化與完整同步最高提升60%。

'

Brave推59.99美元極簡版瀏覽器，引發使用者兩極反應

來源：https://www.ithome.com.tw/news/176429

隱私瀏覽器開發商Brave上周四（6/4）發表全新付費產品Brave Origin，以一次性59.99美元價格提供更精簡的瀏覽器版本，保留阻擋網站追蹤與部分廣告載入的核心功能，但移除或停用AI、VPN、加密貨幣錢包（Wallet）等多項附加服務，引發使用者兩極反應。

Brave成立於2015年，由JavaScript程式語言發明者、前Mozilla執行長Brendan Eich與Brian Bondy共同創辦。該公司以隱私保護為核心定位，主張封鎖跨站追蹤與侵入式廣告，但並非完全排斥廣告，而是試圖建立不依賴蒐集使用者資料的廣告與加值服務模式。Brave宣稱每月活躍用戶已超過1.15億人。

相較於Chrome、Safari或Firefox等主流瀏覽器，原版Brave瀏覽器內建功能更為多元，除了基本瀏覽與隱私保護外，也整合Brave Search搜尋引擎、Leo AI助理、Brave News新聞聚合、Brave Talk視訊會議、Brave VPN、Brave Wallet加密貨幣錢包與Brave Rewards獎勵計畫等服務。其中Brave VPN、部分Leo AI功能與Brave Search Premium屬於付費或進階服務。

Brave表示，Brave Origin是為了回應使用者對極簡瀏覽器的需求而推出。這些使用者希望保留Brave的隱私保護能力，但不想管理AI、加密貨幣、VPN等附加功能，因此Brave改以付費產品提供更精簡的瀏覽器選項。

Brave Origin保留Brave Shields廣告與追蹤防護機制、Chromium安全更新與其他核心隱私功能，但移除Leo AI、Brave News、Brave Rewards、Brave Wallet、Brave VPN、Brave Talk、Tor私密視窗等功能，主打更簡潔的使用體驗，未來新增的非核心功能也會預設排除在Origin之外。Brave Origin採一次性59.99美元收費模式，購買後可在不限數量的個人裝置上啟用。

Brave Origin支援Windows、macOS、Android、iOS及Linux等平臺，其中，Brave Origin for Linux可免費使用。

此事引發了使用者的兩極回應，有使用者批評，Brave花了許多年移除了Chrome擁有的功能，又在自家瀏覽器加入大量附加服務，最終卻還要用戶花錢購買一個乾淨的Brave；不過也有使用者認為他並不介意付費購買喜歡且經常使用的產品，也願意支持創作者。

'

NPM套件再傳遭惡意程式Miasma供應鏈攻擊，AI程式碼工具被鎖定

來源：https://www.ithome.com.tw/news/176422

6月1日資安公司Aikido與OX Security揭露惡意程式Shai-Hulud的變種Miasma攻擊行動，駭客鎖定與Red Hat雲端服務相關的NPM套件，事隔數日，這些駭客再度發起新一波攻擊，引起多家資安公司關注。

資安公司Endor Labs、OX Security、SafeDep、StepSecurity於6月3日至5日提出警告，他們偵測到最新一波的Miasma攻擊，有57個套件被入侵，駭客上傳超過286個版本的惡意套件。其中最受到關注的部分，是感染了由社群維護的NPM套件ai-sdk-ollama，用於串接LLM框架Ollama與雲端AI網頁程式開發平臺Vercel AI，每月下載量超過12萬次；另一個受到研究人員關注的受害套件，是由Vapi推出的AI語音助理軟體開發套件（SDK）vapi-ai/server-sdk，每月下載量超過40.8萬次，StepSecurity指出，vapi-ai/server-sdk是本次事故受害最嚴重的套件。

總體而言，OX Security表示，至少有118個GitHub儲存庫被感染，駭客用於存放竊得憑證；Endor Labs於17秒內看到駭客上傳4個惡意套件。

'