研究人員警告稱，在GitHub上托管代碼倉庫的開發者仍在不安全地使用GitHub Actions，設置了可能被利用來提取敏感認證令牌的自動工作流。

與GitHub Actions工作流相關的安全風險并非新鮮事，然而，Sysdig的研究人員已經識別出了數十個存在漏洞的項目，其中包括來自知名且具備安全意識的高調企業MITRE和Splunk的項目。

Sysdig的研究人員在本周的一份報告中寫道：“這些工作流往往包含機密信息，如API密鑰或憑證，這些信息可能被用于提升權限或在倉庫內橫向移動，甚至如果被竊取，還可能在整個企業內橫向移動。盡管已有工具、技術和公開研究詳細說明了如何識別和利用這些漏洞，但許多開源項目的整體成熟度仍然令人擔憂地低?！?/p>

Sysdig調查的一個攻擊向量涉及在pull_request_target事件上觸發的GitHub Actions工作流。據Sysdig稱，這個攻擊向量會泄露機密和一個具有倉庫寫入權限的GitHub令牌，并且，由于該操作在基礎倉庫而非觸發拉取請求的分支中執行，因此如果未設置防護措施，它可能導致整個倉庫被接管。

“在分析結果時，我們對發現的易受攻擊的pull_request_target工作流數量感到驚訝，”研究人員寫道，“你可能會認為這些僅限于不知名或不活躍的倉庫，但事實并非如此，我們發現，幾個擁有數萬顆星的高調項目仍在使用不安全的配置?！?/p>

GitHub Actions攻擊成為現實

GitHub Actions是一種CI/CD(持續集成和持續交付)服務，它使開發者能夠通過設置在指定事件(如新代碼提交到倉庫)發生時觸發的工作流來自動化軟件構建和測試，這些工作流被稱為Actions，是打包在.yml文件中的指令，通常在GitHub的基礎設施上的虛擬容器中執行，并返回編譯后的二進制文件、測試結果、日志等。

為了操作，工作流必須能夠克隆倉庫并對其執行操作，為此，系統會在本地.git文件夾中創建并保存一個臨時的GITHUB_TOKEN，以允許執行經過認證的git命令，這個令牌本應是短暫的，并且應該在工作流完成后停止工作。

多年來，研究人員已經展示了GitHub Actions如何被濫用，包括通過域名拼寫錯誤(typosquatting)、未清除機密信息的構建產物以及在工作流之間轉移時的產物污染等方式，并且，這些不僅僅是理論上的攻擊。去年12月，攻擊者通過GitHub Actions腳本注入漏洞，成功入侵了GitHub上Ultralytics YOLO AI庫的構建過程，這導致被污染的庫版本被上傳到了PyPI倉庫。

危險的拉取請求工作流觸發器

當開發者從他們分叉的代碼倉庫版本提交新代碼回主倉庫以供包含時，就會發生拉取請求，然后，項目的開發者會對拉取請求進行審查和評論，之后才會接受請求進行提交。

在GitHub Actions中，pull_request觸發器會促使工作流在分叉分支的上下文中執行，創建一個僅具有主倉庫讀取權限的GITHUB_TOKEN，然而，pull_request_target觸發器會促使工作流在目標分支(通常是主分支)的上下文中執行，具有對倉庫中存儲的所有機密信息的完全訪問權限，以及一個具有讀取和寫入權限的GITHUB_TOKEN。開發者在使用此觸發器時需要謹慎，特別是對于那些嘗試從拉取請求中檢出、運行或構建代碼的工作流，因為代碼可能是惡意的，并且將獲得工作流的機密信息、令牌和權限。

GitHub Actions文檔實際上已經警告了這種危險行為，Sysdig發現，許多開發者仍然以這種方式使用它來測試拉取請求中的代碼更改。

Sysdig發現的一個例子是Spotipy，這是一個用于與Spotify Web API交互的開源Python庫，該項目在GitHub上相當受歡迎，擁有超過5000顆星和近1000個分支。

Spotipy的工作流integration_tests.yml在pull_request_target上觸發，在從拉取請求的倉庫檢出代碼之前，執行pip install(Python包安裝器)命令以安裝依賴項。

如果攻擊者在他們的倉庫中放置了一個惡意的setup.py文件，他們就可以在工作流的pip install操作期間執行惡意代碼。研究人員的概念驗證部署了一個memdump.py腳本，該腳本從內存中提取了憑證，包括SPOTIPY_CLIENT_ID、SPOTIPY_CLIENT_SECRET以及具有讀寫權限的特權GITHUB_TOKEN。

研究人員還在他們的惡意代碼中添加了sleep命令，以延長工作流的執行時間，從而延長GITHUB_TOKEN的有效性，以便在它過期之前被濫用，該漏洞被評為嚴重級別，并被分配了CVE-2025-47928。

MITRE和Splunk修正倉庫配置錯誤

另一個值得注意的例子是MITRE CAR(網絡分析倉庫)，它諷刺地托管了一個分析集合，包括檢測規則和邏輯，旨在幫助安全團隊識別映射到MITRE ATT&CK框架的對手行為。

這個倉庫包含一個類似于Spotipy的工作流，它在pull_request_target上觸發，以從拉取請求中檢出代碼并發出pip install -r ./scripts/requirements.txt命令。由于requirements.txt文件是檢出代碼的一部分，因此它完全處于潛在攻擊者的控制之下。

“再次，我們成功竊取了默認的高特權GITHUB_TOKEN和其他機密信息，最終在倉庫內獲得了提升的權限，”Sysdig團隊表示，“在向MITRE報告該漏洞后，它得到了確認并迅速被MITRE團隊修復?！?/p>

第三個例子是Splunk的一個名為security_content的倉庫，它有一個類似的可濫用工作流，在這種情況下，提取的GITHUB_TOKEN僅限于讀取權限，但研究人員設法從倉庫中提取了其他憑證，名為APPINSPECTUSERNAME和APPINSPECTPASSWORD，該問題在報告后得到了修復，但提取的憑證的性質和敏感性尚不清楚。

緩解措施

有幾種方法可以緩解這些配置錯誤風險，首先，如果可能的話，應避免使用pull_request_target，并且在不完全理解其安全影響和風險的情況下不要使用，以這種方式執行的工作流不應檢出不受信任的代碼。

如果仍然需要特權工作流，那么應首先在不特權的工作流中執行不安全任務，如檢出和運行不安全代碼，然后將驗證后的結果傳遞給特權工作流，這被稱為工作流分割，是GitHub推薦的一種策略。

其次，GITHUB_TOKEN的權限應配置為只讀，正如Splunk倉庫中的情況一樣，這將無法保護工作流執行過程中暴露的其他機密信息，但將防止攻擊者獲得對主倉庫的寫入權限。

“一種可以考慮的緩解措施是將工作流配置為僅在拉取請求被分配了特定標簽時才運行，這實際上需要具有倉庫寫入權限的維護者進行手動審查，”Sysdig研究人員建議道，“由于外部貢獻者無法分配標簽，因此這確保了拉取請求在手動審查后才會觸發工作流?！?/p>