Security researchers have disclosed an ongoing credential-theft campaign in which attackers compromised two high-profile open-source maintainer accounts — not GitHub itself — and used that account-level access to push malicious GitHub Actions workflows into more than 340 repositories. The findings come from StepSecurity and were reported by The Hacker News.
The platform behaved as designed; the failure was at the account-security layer. Once armed with a write-capable token from a hijacked maintainer, the attacker's payload was a workflow file — code that GitHub's automation engine would run on ordinary project activity from then on.
The most prominent victim was Takashi Kitao, author of the popular Pyxel game engine, which has amassed roughly 18,400 stars on GitHub. Using Kitao's account, the attacker pushed a malicious workflow into 27 of his repositories, with activity beginning at 13:20 UTC. How either maintainer account was initially compromised remains undisclosed — a gap readers should note when assessing their own exposure around personal access tokens, active sessions, and two-factor authentication.
Why the attack surface is the automation layer
The campaign is a textbook demonstration of a weakness many organizations still underestimate: the CI/CD pipeline itself, not just the reviewed application code. A GitHub Actions workflow inherits the trust and permissions of the project that runs it. A single compromised maintainer credential is therefore enough to plant a workflow that harvests secrets from every build, pull request, or scheduled job that runs afterwards — without touching a line of the code contributors actually review.
For teams that review pull requests carefully but never audit .github/workflows/, this is the blind spot the campaign exploited. Once planted, a malicious workflow becomes self-perpetuating: it re-triggers on ordinary project activity, living outside the diffs most reviewers scrutinize.
Why Hong Kong teams should care
Many Hong Kong development teams store production credentials — AWS, Azure, and GCP access keys, deployment tokens, registry logins — as repository or organization-level GitHub secrets, precisely so CI/CD can use them. A malicious workflow running with default permissions can often reach those secrets directly. In other words, a single hijacked maintainer account upstream can become a fast path to production cloud infrastructure downstream, no application vulnerability required.
A self-audit checklist
The disclosures point to three structural defenses that neutralize this class of attack, and a fourth for detection.
Pin third-party actions by commit SHA. Workflows commonly reference actions using mutable tags such as actions/checkout@v4. Those tags can be silently repointed to different code, including code that exfiltrates GITHUB_TOKEN or secrets to an attacker-controlled endpoint. Referencing a full commit SHA makes the reference immutable. The maintenance cost of updating pins is real, but tools like Dependabot and Renovate can automate version bumps for SHA-pinned actions, removing the usual objection.
Audit every pull_request_target trigger. The pull_request_target event runs in the context of the base repository, meaning it carries the base repo's secrets and a token with its permissions — while the code being tested may come from an untrusted fork. Combined with a checkout of the pull request's head ref, it is effectively a remote code execution primitive handed to outside contributors. Workflows using this trigger should never check out and execute head-ref code; if untrusted-code testing is needed, split it into a separate, standard pull_request workflow, or gate execution behind a trusted label.
Scope GITHUB_TOKEN permissions explicitly. Default token permissions can be broader than a workflow requires. Declaring a minimal permissions: block — or setting restrictive repository defaults — limits the blast radius if a workflow is compromised or abused. For teams managing many repositories, the highest-leverage version of this control is organization-level: Settings → Actions → General → Workflow permissions sets a restrictive default across the entire portfolio in one place, rather than relying on each workflow author to remember. New repositories inherit the org default, closing the gap for projects no one has hardened yet.
Review run history and workflow file changes. Treat this as a credential-exposure event if you maintain popular projects. Rotate any secrets that could have been reachable by affected workflows, inspect the commit history of .github/workflows/ for unexpected additions or modifications, enable branch protection on workflow paths, and turn on secret scanning and push protection where available.
The broader lesson
Supply-chain attacks increasingly target the glue infrastructure between code and deployment rather than the code itself. The maintainer whose account was hijacked may never have published a vulnerable commit; the trust boundary that failed was a set of account credentials and permission defaults that most repositories never review. The research underscores that whatever the initial cause of a single account compromise, the automation layer should be hardened to assume it will happen again — because for active open-source projects, it plausibly will.
安全研究人員披露了一宗正在進行的憑證竊取攻擊：攻擊者入侵了兩名知名開源專案維護者的帳戶（而非 GitHub 平台本身），並利用帳戶層級的寫入權限，將惡意的 GitHub Actions workflow 植入超過 340 個儲存庫。相關發現由 StepSecurity 公布，並經 The Hacker News 報導。
平台本身並無漏洞；失守的是帳戶安全這一層。攻擊者取得被入侵維護者帳戶中具寫入權限的 token 後，便上傳了一個惡意的 workflow 檔案——GitHub 自動化引擎會在專案有任何尋常活動時執行它。
受害維護者中最受矚目的是 Takashi Kitao，知名 Pyxel 遊戲引擎的作者，該專案在 GitHub 上已累積約 18,400 顆 star。攻擊者利用 Kitao 的帳戶，於其 27 個儲存庫中植入惡意 workflow，活動從 UTC 13:20 開始。至於兩名維護者的帳戶最初如何被入侵，目前仍未公開——讀者在評估自身暴露面時（例如 personal access tokens、登入 session 及雙重認證設定），應留意這項資訊缺口。
為何自動化層成為攻擊面
這宗攻擊清楚揭示了許多組織仍低估的弱點：CI/CD 流水線本身，而不只是經過審查的應用程式碼。GitHub Actions workflow 會繼承所在專案的信任與權限。因此，單憑一個被入侵的維護者憑證，攻擊者就足以植入一個 workflow，從此後每一次 build、pull request 或排程任務中竊取 secrets——全程毋須碰觸貢獻者真正會審查的程式碼。
對於會認真審查 pull request、卻從不檢查 .github/workflows/ 目錄的團隊來說，這正是此次攻擊利用的盲點。惡意 workflow 一旦植入便會自我延續：它會隨專案的尋常活動重新觸發，藏身於大多數審查者不會留意的 diff 之外。
為何香港團隊需要關注
許多香港開發團隊將生產環境憑證——AWS、Azure 及 GCP 的存取金鑰、部署 token、container registry 登入資料——以 repository 或 organization 層級的 GitHub secrets 形式儲存，正是為了讓 CI/CD 使用。一個以預設權限運行的惡意 workflow 往往能直接讀取這些 secrets。換言之，上游一個被入侵的維護者帳戶，可以成為通往下游生產環境雲端基礎設施的捷徑，全程毋須利用任何應用程式漏洞。
自我審計清單
研究揭露了三項能有效阻斷此類攻擊的結構性防禦措施，以及一項用於偵測的措施。
以 commit SHA 固定第三方 Action 的版本。 Workflow 常以可變標籤（例如 actions/checkout@v4）引用 Action。這些標籤可被悄悄改指向其他程式碼，包括會將 GITHUB_TOKEN 或 secrets 外傳至攻擊者端點的程式碼。改以完整 commit SHA 引用可確保版本不可變動。固定 SHA 帶來的維護成本確實存在，但 Dependabot 和 Renovate 等工具能自動化 SHA 固定版本的升級通知，消除了過往的主要反對理由。
審計每一個 pull_request_target 觸發器。 pull_request_target 事件會在 base repository 的情境中執行，意味著它攜帶 base repo 的 secrets 及相應權限的 token——但被測試的程式碼可能來自不受信任的 fork。若再加上 checkout 該 pull request 的 head ref，等同把一個 remote code execution（遠端代碼執行）能力交到外部貢獻者手中。使用此觸發器的 workflow 永遠不應 checkout 並執行 head-ref 的程式碼；如有測試不受信任程式碼的需要，應拆分至獨立的標準 pull_request workflow，或以受信任的 label 作為執行閘門。
明確限定 GITHUB_TOKEN 權限。 預設的 token 權限往往超出 workflow 的實際需要。在 workflow 中聲明最小化的 permissions: 區塊——或設定限制性的 repository 預設值——能將 workflow 被入侵或遭濫用時的影響範圍降至最低。對於管理多個儲存庫的團隊，此控制的最高槓桿點位於 organization 層級：在 Settings → Actions → General → Workflow permissions 中設定限制性預設值，可一次性涵蓋整個專案組合，而不必依賴每位 workflow 作者自行記得設定。新建的 repository 會繼承 organization 預設值，補上尚未加固專案的防護缺口。
檢查執行紀錄與 workflow 檔案變更。 若你維護受歡迎的開源專案，應將此視為一宗潛在的憑證外洩事件。輪換所有可能被受影響 workflow 存取的 secrets，檢查 .github/workflows/ 目錄的 commit 歷史，尋找非預期的新增或修改，並在 workflow 路徑上啟用分支保護；如平台提供，亦應開啟 secret scanning 及 push protection。
更廣泛的啟示
供應鏈攻擊越來越針對程式碼與部署之間的「黏合」基礎設施，而非程式碼本身。被入侵帳戶的維護者可能從未發布過含有漏洞的 commit；失守的信任邊界是一組帳戶憑證與權限預設值，而多數 repository 從不檢視它。研究指出，不論單一帳戶被入侵的最初原因為何，自動化層都應以「它會再次發生」為前提來加固——因為對活躍的開源專案而言，這確實隨時可能發生。