因應AI加速網路攻擊，印度要求企業組織在漏洞公布12小時內完成修補

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

因應AI加快駭客發現及攻擊軟體漏洞，印度網路安全主管機關CERT-In發布命令，要求企業在漏洞公布12小時內應完成修補。

CERT-In發布38頁的最新指導方針文件（CISG-2026-02）說明，AI輔助的工具加速攻擊者尋找、武器化和濫用漏洞、曝露服務、弱點、不安全API和配置錯誤系統，新一代攻擊時間大幅縮短，伴隨自主化攻擊出現，漏洞公開後數小時內就被武器化會變成常態。

CERT-In相信傳統數週的修補週期已不具備防禦力，並提出極嚴格的修補時間要求。其中，若得知風險值9.0的重大漏洞或是影響內部系統的已知漏洞，應於24小時內修補，已遭公開利用（Known Exploited）且暴露在網際網路上的「核心關鍵資產（Crown Jewel）」系統，更須在發現後12小時內進行修補、緩解或隔離。其他高價值系統的關鍵漏洞應於3天內修補，高風險（High）的一般漏洞則須於5天內完成。

印度官方並重申現有要求，所有組織與企業一旦偵測到或意識到資安事件發生時，必須在6小時內向CERT-In通報。

其次，印度官方要求組織採取零信任（Zero Trust）架構、全面導入多因素驗證（MFA）、最小權限管理、硬體身分驗證，以及內網微分段（micro-segmentation），避免駭客攻破一臺主機後在整個網路橫向移動。文件也點名舊式VPN與遠端存取設備是高風險入口，建議強化或淘汰。

CERT-In也鼓勵企業使用AI防禦工具，例如AI漏洞偵測或攻擊表面（attack surface）分析。此外，也要求企業定期進行AI輔助攻擊的安全教育，深偽（deepfake）辨識教育、AI紅隊演練（red teaming）等。

The Register引述資安專家表示，12小時實在太短，不足以完成修補程式的測試和部署。

但是也有資安專家認為，這類法規不無道理，因為AI出現後，駭客可能在幾小時內就可以發現並攻擊，新法規迫使組織必須重新調整其安全策略，使其轉向持續性防禦態勢（posture）。

'

Hadrian開源AI漏洞研究框架OpenHack，可搭配Claude Code與Cursor執行白箱安全審查

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

荷蘭資安公司Hadrian上周宣布開源AI漏洞研究框架OpenHack，透過多代理人（Multi-Agent）工作流程協助研究人員自動化執行原始碼安全審查與白箱滲透測試（White-box Pentesting）。

Hadrian成立於2021年，總部位於荷蘭阿姆斯特丹，主要提供攻擊面管理（Attack Surface Management，ASM）與自動化滲透測試服務。所謂的白箱安全審查，是指在能夠存取原始碼的情況下，直接分析程式邏輯與設計缺陷，以尋找安全漏洞。

該研究團隊先前即曾利用與OpenHack類似的方法，分析荷蘭政府機關使用的十多個開源應用程式，在數小時內發現數百項漏洞，其中最嚴重的一項重大漏洞曝露伺服器憑證，並可進一步存取底層Azure資料庫。OpenHack即是將這套AI輔助漏洞研究流程整理後開源，讓資安社群能以較低成本進行類似的原始碼安全審查。

Hadrian指出，許多人在利用大型語言模型（LLM）進行安全分析時，會直接要求模型閱讀整個程式碼庫並找出漏洞，但這種方式經常產生大量誤判。模型可能提出不存在的漏洞、錯誤解釋真實漏洞，或產生看似合理卻無法驗證的結果，導致研究人員花費大量時間進行人工複核。

為了解決上述問題，OpenHack採用以情境（Scenario）為核心的多代理人工作流程。系統先由偵察代理人（Recon Agent）找出可能的攻擊面，再由路由代理人（Router Agent）將其轉換為特定測試情境，接著交由專門負責不同漏洞類型的專家代理人（Expert Agent）進行驗證，最後再由獨立的複核代理人（Triage Agent）重新審查結果。

OpenHack最大的特色在於提出漏洞的代理人無法自行確認漏洞成立，而必須經過另一個獨立代理人的驗證，同時每個階段都需取得人工批准。OpenHack目前支援Claude Code、Codex與Cursor等AI程式代理工具。

OpenHack也內建12種對應OWASP Top 10 2025與MITRE CWE的安全專家代理人，涵蓋權限控管、注入攻擊（Injection）、密碼學錯誤、供應鏈安全及路徑穿越等常見漏洞類型。此外，系統會將偵察結果、測試情境、候選漏洞、複核決策與最終報告保存為一般檔案，讓整個漏洞研究流程可追蹤與稽核。

Help Net Security分析，隨著Claude Code、Codex與Cursor等AI程式代理工具逐漸普及，原始碼導向的漏洞研究也愈來愈仰賴代理人執行程式碼審查。OpenHack則將這類流程包裝成可在不同工具中執行的檔案化工作空間，強調可追蹤、多代理人分工與獨立複核。

'

Gogs存在尚未修補的零時差漏洞，攻擊者可用於遠端執行任意程式碼

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

談到自建Git程式碼版本管理系統，除了GitHub與GitLab，許多開發團隊採用主打輕量化的Gogs，近日資安公司Rapid7表示，兩個月前他們向Gogs開發團隊通報的重大漏洞，迄今尚未修補，並警告一旦攻擊者成功利用此漏洞，就可能入侵伺服器、跨租戶竊取資料與身分憑證、橫向移動，甚至發動供應鏈攻擊。

資安公司Rapid7發布部落格文章提出警告，這個被歸類為參數注入（argument injection）漏洞，Rapid7是在3月下旬找到，通過身分驗證的攻擊者，可藉此在合併前重設程式碼基礎（Rebase before merging）的操作流程中，建立具有惡意分支（branch）名稱的拉取請求，之後就有機會遠端執行任意程式碼（RCE），無須事先取得管理員權限，利用漏洞的過程也不需與使用者互動，甚至能完全自動化執行，CVSS v4.0評分達到9.4（滿分10分），該弱點目前尚未登記CVE編號。由於Gogs開發團隊尚未進行修補，他們呼籲用戶應採取行動因應，包括：限制用戶註冊與建立儲存庫，以及審核合併及重設程式碼基礎的組態設定。

關於漏洞的影響範圍，Rapid7指出，無論在Windows、macOS、Linux作業系統上建置，以及採用預先組建二進位檔、Docker或用原始碼等安裝方式的Gog，都無法例外；而在Gog的版本上，他們驗證0.14.2版與0.15.0+dev都存在相同的資安風險——他們在Ubuntu 24.04架設Docker環境，並建置最新的0.14.2版Gogs成功驗證此漏洞，並發現測試版本0.15.0+dev也存在相同的資安風險。

'

美物流業者SpeedX敏感資料庫網上曝光，內含8.4億筆消費者、司機資料

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

美國最後一哩（Last Mile）電商物流業者SpeedX（極速達）一個內含超過8.4億筆送貨資料的雲端儲存桶，被發現因配置問題曝露於網路上，可能影響電商客戶、包裹及送貨司機。研究人員相信可能是歷來最大的資料外洩案之一。

SpeedX成立於2022年，是一家由華人在美國創立的技術驅動電子商務物流公司，多個城市設有據點。其核心業務專注於電商「最後一哩」（Last Mile）配送解決方案，核心業務是將Amazon、Temu、TikTok Shop等電商平臺及SHEIN等快時尚商品寄往美國及全球市場，最多曾一天處理35萬到40萬件商品。

資安媒體Cybernews報導，該公司研究人員三月間發現一個屬於SpeedX的Microsoft Azure儲存桶曝露於網際網路上。問題出於該公司的Azure Blob儲存桶配置設定為公開，任何只要知道該儲存桶名稱的人，無需特定權限或路徑即可直接存取。這個儲存桶內含包裹相關的資料超過8.4億份檔案，可能成為有史以來最大規模的物流資料外洩事件之一。

分析SpeedX公開的資料庫，大部分是和其運送包裹相關資訊。該資料庫內有11個資料群組，最大的群組包含近6.2億個檔案，次大為2.2億個。這些檔案包含包裹資訊如收件人姓名、住址、住家照片、出貨標籤、送貨司機證件、SpeedX App憑證等。另一包括380萬檔案的群組，則包含商品訂單追蹤碼、零售商、配銷機構住址及收件人資訊。

研究人員相信這些資料可能涉及美國各地的網購消費者以及該公司的外送司機。此外，加拿大合作夥伴Raven Force Couriers的部分物流標籤也包含在內。

SpeedX已於2026年5月11日關閉該儲存桶公開存取管道。SpeedX宣稱，經調查未發現資料被惡意外流或濫用的證據。

'

IBM與Red Hat推出企業開源軟體供應鏈安全服務Project Lightwell，標榜AI輔助第三方套件漏洞修補

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

IBM與Red Hat（紅帽）合作推出企業開放原始碼軟體供應鏈安全服務Pro ject Lightwell，標榜結合AI輔助漏洞分析， 協助企業處理第三方開放原始碼套件漏洞， 並將已驗證的修補整合至既有軟體供應鏈。

這項服務延伸IBM與紅帽過去在Red Hat Enterprise Linux、OpenShift等企業開源平臺上的維護模式， 將過去針對平臺內開放原始碼元件提供的生命週期管理、 漏洞修補驗證與發布工程（release engineering）， 擴大到企業應用程式常用的第三方開放原始碼函式庫、 程式語言工具鏈、AI框架與資料串流平臺。IBM與紅帽表示， Project Lightwell將透過商業訂閱方式提供相關能力， 讓企業能將這類套件漏洞修補納入既有的軟體供應鏈管理流程。

Project Lightwell鎖定的問題， 是如何把漏洞發現轉化為企業可實際部署的修補成果。 依IBM說明，企業可在可信任的中介框架下， 回報實際使用版本中發現的敏感安全問題； IBM與紅帽則結合工程團隊與AI能力， 針對企業實際使用的開放原始碼套件版本，進行漏洞審查、分流、 優先排序、修補開發與驗證， 並交付針對正式環境最佳化的已驗證修補， 涵蓋紅帽產品與獨立社群程式碼。

Project Lightwell也把上游通報與修正協調納入運作流程， 讓IBM與紅帽在完成企業所需的套件漏洞修補後， 可將相關修正內容回饋給上游開放原始碼社群， 供社群納入後續長期維護。 這種模式讓企業可委託IBM與紅帽處理關鍵安全問題， 同時透過負責任揭露，降低企業自行維護修補分支的負擔， 並強化整體開源生態系。

IBM並將Project Lightwell定位為既有漏洞掃描與程式碼安全工具的補強， 而非取代Snyk、Sonatype、GitHub Advanced Security等工具。其差異在於，Project Lightwell交付的是針對企業既有套件版本完成修補、 具備簽章驗證且納入服務水準協議（SLA）的套件， 協助企業從發現漏洞進一步進入可部署到正式環境的修補階段。

Project Lightwell的設計也參考Anthropic Project Glasswing與OpenAI Trusted Access for Cyber等計畫經驗， IBM希望藉此把代理式安全技術用於開放原始碼套件風險管理， 協助企業保護支撐現代應用程式與AI系統的基礎開放原始碼元件。 技術支援範圍方面，Project Lightwell初期鎖定Maven與Java生態系， 未來預計擴展至PyPI、NPM、Go等更多套件生態系。

IBM與紅帽已與一批早期採用企業合作，包括Bank of America、Goldman Sachs、JPMorganChase、 Mastercard、Morgan Stanley、Royal Bank of Canada、Visa與Wells Fargo等。雙方表示，這些初期部署經驗， 將作為Project Lightwell在複雜軟體供應鏈中，大規模識別、 驗證與修補開放原始碼套件漏洞的參考。

'

遊輪旅行業者Carnival、有線電視業者Charter分別證實資料被竊

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

在勒索軟體駭客組織ShinyHunters宣稱自己的戰果後，全球最大遊輪營運業者Carnival及第三大美國有線電視業者Charter本周先後證實發生資料外洩事件。

ShinyHunters駭客4月份宣稱竊得遊輪營運業者Carnival子公司荷美遊輪（Holland America）客戶資料，近一個月後，本週Carnival透過向美國緬因州政府檢察長辦公室申報文件證實此消息。Carnival同時間對消費者發出電子郵件通知。

雖然資料外洩查詢服務Have I Been Pwned之前稱這波攻擊外洩870萬筆記錄、750萬人，但根據緬因州政府記錄，受影響人數為接近600萬人。

Carnival並未說明外洩的客戶資料有哪些，但根據Have I Been Pwned資料顯示，攻擊者可能竊走了資料類型涵括姓名、出生日期、性別、電子郵件、地區、忠誠方案的客戶級別等。

Carnival在2019年也曾發生客戶及員工資料外洩，但是規模比這次小得多。當時受影響人數18萬人，2022年該公司以125萬美元和美國45州達成和解。

同時間，美國第三大有線電視業者及第二大付費電視公司特許（Charter Communications）也向媒體Bleeping Computer證實發生資料外洩事件。該公司表示得知狀況，將循公司資安規定通報主管機關。

ShinyHunters上星期在其資料外洩網站公告，竊走了Charter 4000萬筆記錄。這群駭客聲稱是利用語音釣魚，騙走Charter一名員工的Microsoft Entra帳號，於4月1日從該公司的Salesforce執行個體中匯出資料。駭客聲稱取得的客戶資料包括姓名、電子郵件、住家地址、電話號碼、方案細節及部分客戶的專線資訊和技術支援工單資料。

Charter雖然坦承有非授權存取資料的情形，但仍表示沒有敏感個資或客戶網路專線資訊（customer proprietary network information）因此外洩。

'

Waymo推出新一代Robotaxi車款Ojai，搭載第6代自駕系統

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

Alphabet旗下自駕車公司Waymo周四（5/28）宣布推出新一代Robotaxi車款Ojai，並將於未來數周開放首批一般乘客試乘。Ojai搭載第6代Waymo Driver自動駕駛系統，首波將在舊金山、鳳凰城與洛杉磯開放部分乘客免費試乘，成為Waymo One自駕叫車服務的新一代車款。

Waymo過去主要是將自動駕駛系統整合至既有車款，包括早期使用的Chrysler Pacifica Hybrid，以及目前商用車隊主力Jaguar I-PACE電動休旅車。相較之下，Ojai是Waymo新一代專為Robotaxi服務打造的車款，車艙從乘客體驗出發重新設計，採用類似電梯的側滑車門、低踏板與全平地板，並配置3個大型LED螢幕，讓乘客可調整空調與音樂等設定。

在無障礙設計方面，Ojai亦整合多項輔助功能，包括點字標示、螢幕閱讀器相容介面，以及座椅旁的輔助把手，以協助視障人士或行動不便乘客更順利地使用服務。

雖然Ojai擁有全新的外觀與車艙設計，但其核心仍是Waymo最新一代自動駕駛平臺Waymo Driver。Waymo指出，第6代Waymo Driver可支援更多氣候與道路環境，包括較多降雪的城市，並有助於進一步擴大營運範圍。

根據TechCrunch報導，Ojai的前身是Waymo與中國電動車品牌Zeekr共同開發的Zeekr RT。Waymo早在2021年即與Zeekr母公司吉利控股集團（Geely Holding Group）建立合作關係，雙方以Zeekr的SEA-M架構為基礎，開發專為Robotaxi等未來移動服務設計的車輛。Waymo亦於2025年的CES上展示Zeekr RT，並在2026年將其更名為Ojai。不過，Waymo在最新新聞稿中完全未提及吉利或Zeekr。

Waymo表示，Ojai目前已接近正式商業化部署，首批Ojai試乘將先向舊金山、鳳凰城與洛杉磯部分用戶開放，後續也將擴展至丹佛、拉斯維加斯與聖地牙哥等城市。該公司同時正在亞利桑那州Mesa工廠擴大搭載Waymo Driver車輛的整合產能，以每年交付數萬輛為目標。

'

GitLab 19.0推出SBOM相依性掃描，鎖定間接相依套件的漏洞風險

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

第三方套件與AI產生的程式碼大量進入企業專案， 也讓軟體供應鏈風險更難追蹤。DevSecOps平臺業者Git Lab於5月26日說明GitLab 19.0的新功能，正式推出以軟體物料清單（Software Bill of Materials，SBOM）為基礎的相依性掃描（depen dency scanning），協助企業盤點直接與間接相依套件， 追蹤有漏洞套件如何進入專案， 並依照程式碼的實際使用情況排定修補優先順序。

GitLab指出，近期多起軟體供應鏈事件顯示， 單一套件一旦遭到入侵，可能連帶影響所有依賴該套件的專案。 另一方面，AI產生程式碼的應用增加， 也讓企業更難掌握程式碼與相依套件風險。 一般而言，傳統的相依性掃描工具， 包括GitLab既有的Gemnasium分析器， 主要用來檢查專案宣告使用的套件是否存在已被通用漏洞揭露（Common Vulnerabilities and Exposures，CVE）記錄的漏洞； 但在相依套件層級變深、軟體發布速度加快後， 企業還需要知道漏洞套件是透過哪一條相依鏈進入專案， 以及應用程式是否真的會使用到這些套件。

GitLab 19.0的SBOM相依性掃描分析器， 會將專案使用的第三方函式庫與套件整理成SBOM，並以Cycl oneDX格式輸出SBOM檔案，再與GitLab維護的漏洞資 料庫GitLab Advisory Database比對，標示已知漏洞。 掃描結果可顯示在合併請求（Merge Request，MR）、漏洞儀表板與報告中， 讓開發者能在程式碼發布前修正， 也讓資安團隊集中檢視不同專案的風險。CycloneDX是常用 於描述軟體元件清單與供應鏈資訊的機器可讀格式，可供GitLa b內部流程、法規遵循報告或其他供應鏈安全工具使用。

這項新功能的重點之一，是追蹤間接相依套件來源。GitLab舉 例，若library-a依賴library-b，而libra ry-b又依賴有漏洞的library-c， 分析器會呈現這條相依路徑，協助團隊判斷應從哪一層套件介入。 針對Java、JavaScript／TypeScript與P ython專案， 分析器也會檢查程式碼是否直接匯入或引用有漏洞套件， 區分哪些套件是程式碼可觸及的，哪些只是被間接帶入、 但未被應用程式引用， 讓團隊能把修補資源優先放在程式碼實際會用到的套件上。

這項相依性掃描也支援持續風險檢查。GitLab文件指出， 當新的安全公告發布時，系統可針對已回報的SBOM元件進行持續 漏洞掃描；而在每次MR或管線（pipeline）執行時， 分析器也會重新檢查專案相依套件， 讓企業不只在導入套件或修改程式碼時掌握風險， 也能追蹤既有專案是否因後續發布的新漏洞公告而增加安全風險。 這項機制對於開發活動已放緩、 但仍在正式環境運作的專案尤其重要，因為即使程式碼沒有更新， 既有相依套件仍可能因新的安全公告而暴露於漏洞風險。

此外，GitLab 19.0也提供相依性掃描的安全組態設定檔（security configuration profile）， 讓資安與平臺團隊能以標準化設定集中管理掃描規則， 並一次套用到多個專案，減少逐一調整每個專案管線設定的負擔。

GitLab表示，SBOM相依性掃描功能提供給GitLab Ultimate客戶，已在GitLab.com上線， 並依標準發布時程提供給GitLab Dedicated與自行管理部署用戶。

'

Google發布Chrome 148更新，修補逾150個資安漏洞

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

5月27日Google發布Chrome電腦版與Android版更新，一口氣修補了151個資安漏洞，數量較一週前的安全更新修補16個漏洞多出不少。從危險程度來看，這次有22個重大漏洞、123個高風險漏洞，其餘6個評為中度風險。用戶應儘速更新，Windows版為148.0.7778.216或148.0.7778.217、macOS版為148.0.7778.215或148.0.7778.216，Linux與Android版為148.0.7778.215。

從漏洞的類型來看，記憶體相關的漏洞仍是大宗，其中又以記憶體釋放後再存取利用（Use After Free）類型的弱點66個最多，數量超過本次修補漏洞的三分之一。未受信任的使用者輸入驗證不充分與不當實作類型的弱點，各有17與15個；記憶體越界寫入與讀取各有12個弱點，整數溢位類型弱點有11個。

根據出現弱點的元件來看，ANGLE（Almost Native Graphics Layer Engine）有33個，數量位居第一，GPU、Skia、WebGL分別有12個、11個、9個。

'