What Happened
An attacker used stolen credentials for 4,837 GitHub accounts to plant a GitHub CI secret stealer in repositories those accounts could write to, according to Aikido Security, a security software company. The stealer is built to take the secrets and cloud credentials that a repository's CI workflows can reach. It ran in at least 1,806 repositories.
For an MSP, the code is not the loss. The credentials are. A pipeline runs with whatever access the repository gives it, so one write to a workflow file can put cloud keys, deployment tokens and package publishing tokens in an attacker's hands. Those do not come back with a restore. They have to be rotated, and until they are rotated, the attacker keeps the access the pipeline had.
The activity started Tuesday, according to the report. The report was published on 2026-11-12.
Timeline
- Tuesday: The attacker began using stolen credentials for GitHub accounts to plant the secret stealer in repositories those accounts could write to, according to Aikido Security.
- 2026-11-12: The report is published.
Who Is Affected
The source lists three groups: 4,837 GitHub accounts with stolen credentials, at least 1,806 repositories those accounts could write to, and the secrets and cloud credentials reachable by a repository's CI workflows.
That third group is the one that spreads. A workflow secret is often a cloud credential that can reach production data, or a token that can publish to a package registry. If a client's repository was one of the 1,806, the pipeline secrets inside it should be treated as exposed.
No public list of affected accounts or repositories has been published, so you cannot check a name against a list. The practical approach is to assume exposure wherever an account with write access was compromised, then rotate from there. MSPs whose clients build software on GitHub should also find out whether developers used personal accounts with write access, because those sit outside the controls you manage.
Why the GitHub CI Secret Stealer Works So Well
CI is where automation lives, and automation is handed credentials so it can do its job. In general, that makes a repository a credential store with a git front end. Whoever can change what the pipeline runs can usually reach everything the pipeline can read.
The second reason is trust. Code that arrives through a normal commit is not treated as hostile by the pipeline. There is no flaw to patch, because nothing was broken. The attacker held valid credentials for an account with write access, and the pipeline did what pipelines do.
The third reason is quiet. A stolen cloud credential does not break anything on the way out. There is no crash, no ransom note and no outage that would send someone to look at the repository. Detection depends on logs that many small environments do not read until they have a reason to.
Technical Details
- No CVE identifier is named in the source for this campaign. No patched software flaw is named either.
- GitHub is the platform named in the source. No product version is given, because the activity is not tied to a version of a product.
- Attack vector: stolen credentials for GitHub accounts, used to plant a secret stealer in repositories those accounts could write to. The stealer runs in the repositories' CI workflows and takes the secrets and cloud credentials those workflows can reach.
- Scale as stated in the source: 4,837 GitHub accounts with stolen credentials and at least 1,806 repositories.
What MSPs Should Do
Work on the assumption that any client account with write access may have been among the 4,837. The steps below are the standard response to stolen developer credentials, ordered so the damage is limited fastest.
- Map write access. Find out which client accounts can push to which repositories, including personal accounts and old service accounts nobody owns.
- Review recent commits to workflow files and build scripts. A change that runs on push or on a schedule deserves a close look.
- Rotate every secret those workflows can reach, including cloud keys, deploy keys, access tokens and the cloud roles the pipelines assume.
- Rotate the credentials of any account with write access that you cannot fully account for. Do not wait for proof of use.
- Cut token permissions back to what each pipeline needs, and remove tokens that are not used at all.
- Turn on phishing-resistant MFA and review personal access tokens for long expiry dates and broad scope.
- Check cloud and package registry logs for activity from unfamiliar locations or at unusual times.
- Pin third-party actions to full commit SHAs, and require approval for workflows that run from outside contributors.
- Enable secret scanning and alerting so a new credential in a repository or workflow is noticed quickly.
- Test the restore path for the client systems that depend on those pipelines, so a rebuild is a planned operation rather than a surprise.
How EnterProtect Helps
EnterProtect backup keeps clean, restorable copies of client systems, so a rebuild starts from something known good rather than from whatever is left after an incident. Recovery gets the client running again, on a timeline you can plan with them instead of explaining afterwards.
EnterProtect vulnerability scanning, as a standing practice, keeps a current view of what is exposed across client environments, so patching work is driven by what is actually there.
Be clear with clients about the limit here. A stolen token cannot be restored. It has to be rotated. Backup and recovery cover the systems that token could reach, and that is the part you can control on the day.
Frequently Asked Questions
What Is a CI Secret Stealer?
It is code planted in a repository that runs as part of that repository's CI workflow and takes the secrets and cloud credentials the workflow can reach, instead of changing how an application behaves. Aikido Security describes the stealer in this campaign as built for exactly that. It is quiet, because the pipeline is expected to read those secrets anyway.
How Were the 4,837 GitHub Accounts Compromised?
Aikido Security says the attacker used stolen credentials for the accounts, and the report does not describe how those credentials were obtained. What matters is the access each account carried, which was write access to repositories. If any of your clients' accounts fall into that group, treat the pipeline secrets they could reach as exposed.
Which Repositories Were Affected?
Aikido Security says the stealer ran in at least 1,806 repositories that the 4,837 accounts could write to. No public list of affected accounts or repositories has been published. The secrets and cloud credentials reachable by those repositories' CI workflows are the target.
Is There a CVE for This Attack?
No CVE identifier appears in the source for this campaign. There is no version to patch, because the attacker used valid credentials rather than exploiting a software flaw. That is why the response is access review and credential rotation rather than a vendor update.
Should I Rotate CI Secrets After a Developer Account Is Compromised?
Yes. Treat every secret a pipeline could read as exposed, including cloud keys, access tokens and deploy keys. Rotate them, then review logs for the period before rotation. A backup will not recover a stolen token, but it does help if you have to rebuild a system.
What Should MSPs Check First?
Start with which accounts can write to which repositories, then look at recent changes to workflow files and build scripts. Those two things tell you where the exposure sits. After that, rotate the tokens those workflows use and cut their permissions back to what is needed.
Sources
- Attacker Used 4,837 Hijacked GitHub Accounts to Run a CI Secret Stealer in 1,806+ Repositories (Hackernews)