An automated campaign is stealing private repository secrets through an unlikely side channel: the build logs of GitHub Actions itself. In an analysis by cloud security company Wiz, surfaced via The Hacker News, the researchers detail an automated campaign the company has dubbed Gheist, in which attackers use stolen GitHub tokens to plant workflows that print a repository's secrets into their own Actions logs, download those logs, and then delete the runs to cover their tracks.
One detail the available reporting does not settle is how the tokens are obtained in the first place. Neither Wiz's analysis nor the source coverage specifies an initial access vector — infostealer malware, session compromise, or otherwise — so the entry point into the victims' accounts remains an open question pending independent confirmation.
The manoeuvre is notable less for how the attackers get in than for how they get the data out. Rather than pulling secrets through a suspicious outbound connection or a repository export — the patterns conventional monitoring often focuses on — the campaign abuses a channel that few organisations watch at all: CI logs, which are treated as routine engineering artefacts and rarely classified as an exfiltration path.
The attack chain
The sequence Wiz describes is compact. A stolen GitHub token grants access to a target repository. Using that token, the attacker plants a workflow in GitHub Actions. When the workflow runs, it prints the repository's configured secrets directly into the job's log output. The attacker then downloads the logs containing those secrets and deletes the run so the artefact disappears from the repository's workflow history.
Wiz reports that the campaign has succeeded against private repositories and within GitHub Enterprise environments, underscoring that repository-level privacy settings alone do not stop an actor holding a valid token.
GitHub has introduced a safeguard related to this activity according to the source coverage; we will update this article once its exact behaviour is verified.
Why existing controls miss it
The strength of this technique is that every individual step can look legitimate. Workflow runs are created, executed, and removed constantly in an active repository. Log download is a normal developer action. The token used is a real credential, not an obvious forgery. Detection is likely to fail when an organisation's monitoring focuses on authentication anomalies or unusual data egress while leaving the CI/CD subsystem — where secrets are deliberately made available to code — effectively unobserved.
For teams, the lesson is that GitHub Actions logs should be treated with the same sensitivity as the secrets themselves, because in this attack they become exactly that.
What to check now
A practical audit for engineering and security teams covers four areas:
- Prefer OIDC over long-lived personal access tokens. Federated, short-lived credentials issued per workflow run dramatically shrink the window and value of a stolen token, and remove static secrets that can be replayed elsewhere.
- Scope and rotate tokens aggressively. Where personal access tokens remain necessary, use fine-grained tokens with minimal repository permissions, short expiry, and an enforced rotation schedule.
- Audit
pull_request_targetusage. Workflows triggered by this event run with write access to the base repository in many configurations and are a well-known path for untrusted code to reach privileged secrets; review every instance and apply environment protection rules so sensitive secrets require approval before release to a job. - Monitor run creation and deletion patterns. Alerting on workflows that appear and are removed shortly afterwards, unusual log-download activity, and unexpected printing of secret values gives defenders a chance to catch this chain mid-flight rather than after the logs are gone.
Why it matters beyond the immediate campaign
The relevance here is not confined to this campaign. Any organisation running GitHub Actions effectively holds infrastructure in which a build log can become an uncontrolled copy of credentials protecting customer-facing systems. The underlying weakness does not depend on sector or regulator: secrets pipeline through subsystems that security teams rarely inventory, and Gheist simply demonstrates what happens when an attacker treats those subsystems as an egress route.
The full analysis is attributed to Wiz and surfaced via The Hacker News. Details of GitHub's safeguard, the campaign's scale and timeline, and the initial token-acquisition vector remain to be independently confirmed and will be added as this story develops.
一項自動化攻擊行動正透過一個出人意料的側通道竊取私有 repository 的機密：GitHub Actions 自身的 build logs。雲端安全公司 Wiz 的分析（由 The Hacker News 披露）詳述了一項該公司命名為 Gheist 的自動化攻擊行動：攻擊者利用 stolen GitHub tokens 植入 workflows，將 repository 的 secrets 直接列印到其自身的 Actions logs 之中，下載這些日誌，隨後刪除相關 runs 以掩飾行蹤。
現有報導尚未釐清的一個細節是，這些 tokens 究竟從何而來。無論是 Wiz 的分析還是原始報導，都沒有指明初始入侵途徑——infostealer 惡意軟件、session 被入侵，抑或其他途徑——因此受害者帳號的入侵入口點仍有待獨立確認，暫屬懸而未決的問題。
這手法值得注意之處，與其說是在攻擊者如何入侵，不如說是在他們如何將資料帶出去。這項攻擊行動並非透過可疑的 outbound connection 或 repository 匯出來轉移 secrets——即傳統監控通常聚焦的模式——而是濫用極少機構會監察的渠道：CI logs。這些日誌一般被視為例行的工程 artefacts，極少被列為資料外洩途徑。
攻擊鏈
Wiz 描述的過程相當簡潔。一個 stolen GitHub token 授予對目標 repository 的存取權限。攻擊者利用該 token 在 GitHub Actions 植入 workflow。workflow 執行時，會將 repository 已配置的 secrets 直接列印到該 job 的 log output。攻擊者隨後下載載有這些 secrets 的日誌，並刪除該 run，令相關 artefact 從 repository 的 workflow 歷史中消失。
Wiz 報告指出，該攻擊行動已成功入侵私有 repository 及 GitHub Enterprise 環境，凸顯僅憑 repository 層級的私隱設定，並不能阻止持有有效 token 的攻擊者。
根據原始報導，GitHub 已就相關活動引入一項 safeguard；待其確切運作方式獲證實後，我們將更新本文。
現有防禦機制為何失效
此技術的強大之處在於每一個個別步驟都看似合理。在活躍的 repository 中，workflow runs 不斷被建立、執行和刪除。下載 log 是開發人員的正常操作。所用的 token 是真實憑證，並非明顯的偽造品。當機構的監控聚焦於認證異常或不尋常的資料外傳，卻令 CI/CD 子系統——即 secrets 被刻意提供予代碼使用的地方——實質上處於無人監察的狀態時，偵測很可能失效。
對團隊而言，教訓是 GitHub Actions logs 應當與 secrets 本身以同等的敏感度處理，因為在這次攻擊中，前者確實變成了後者。
現在應檢查什麼
工程及安全團隊的實務審核涵蓋四個範疇：
- 優先採用 OIDC 而非長期有效的 personal access tokens。 按每次 workflow run 發出的聯邦式短期憑證，能大幅縮小 stolen token 的時效和價值，並消除可在其他地方重放的靜態 secrets。
- 嚴格限定 token 範圍並積極輪換。 如仍需使用 personal access tokens，應選用具有最小 repository 權限、短期有效期並強制執行輪換排程的 fine-grained tokens。
- 審核
pull_request_target的使用情況。 在許多配置下，由此事件觸發的 workflows 具有對 base repository 的寫入權限，是不可信代碼接觸高權限 secrets 的眾所周知途徑；應逐一檢視每個實例，並套用 environment protection rules，令敏感 secrets 在釋放到 job 前須先獲批。 - 監察 run 的建立及刪除模式。 對於短時間內出現隨即被移除的 workflows、不尋常的 log-download 活動，以及 secrets 數值的意外列印發出警示，可讓防禦方有機會在攻擊鏈進行途中而非日誌消失之後將其截獲。
為何此事的影響不限於本次攻擊
這裡的關聯並不侷限於這項攻擊行動。任何運行 GitHub Actions 的機構，實際上都持有一項基礎設施，其中 build log 可能成為保護面向客戶系統之憑證的失控副本。根本弱點並不取決於行業或監管機構：secrets 經由安全團隊極少盤點的子系統流動，而 Gheist 只是展示了當攻擊者將這些子系統視為外傳路徑時會發生什麼。
完整分析由 Wiz 提供，並經 The Hacker News 披露。GitHub safeguard 的細節、攻擊行動的規模和時間表，以及初始 token 取得途徑，仍有待獨立確認，並將隨著事態發展補充。