4,837 Hijacked GitHub Accounts Ran a CI Secret Stealer in 1,806+ Repositories, then Wiped the Logs
A credential leak at Ran is now a trust-relationship problem between its systems and connected services, not just a contained internal issue.
A credential leak at Ran is now a trust-relationship problem between its systems and connected services, not just a contained internal issue.
Starting Tuesday, an attacker used stolen credentials for 4,837 GitHub accounts to plant a 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.
In 7,309 of those repositories, the stealer was added to an existing workflow.
More pull requests with the same title were opened early today, after the company's own GitHub search ended on Wednesday, a check by The Hacker News found.
The stealer sends data by HTTP POST to the addresses above or to a Telegram chat, the SafeDep researchers found.
Anyone connected to Ran through the compromised trust relationship is potentially affected, not just Ran itself.
This kind of compromise doesn't stay contained to one company; it travels to everyone who installed the affected package or image, often without any direct relationship to the original leak.
Each attack started with a pull request titled docs: dependency audit notes, opened from a branch named wfx-docs to test whether the account could write to the repository.
A leaked key doesn't need an exploit to be dangerous -- it just needs to still work before someone notices and revokes it.
These test pull requests were opened in 61,764 repositories, and the stealer followed in some of them.
That count covers every repository that received malicious commits, not only those where the stealer ran.
The trust mechanism involved here is a federated identity (SSO/SAML) trust relationship, which is what let access move between otherwise unrelated systems.
It ran in at least 1,806 repositories, where the attacker has likely collected those credentials, the company says.
The analysis does not explain how the attacker obtained the credentials.
Ran says the credential has been revoked, and no exploitation has been confirmed so far.
Three that were checked, opened between 05:04 and 05:38 UTC, came from wfx-docs branches.
Owners should also rotate every secret and variable the repository can read.
If you have any integration or dependency involving Ran, rotate any credentials shared with it as a precaution, even without confirmation you were directly affected.
Whether you installed any package, image, or update from the affected registry during the exposure window is worth checking, since the compromise travels through the artifact, not just the original leak.
Your own credential inventory is worth auditing for keys or tokens with broader access than they actually need -- the same blast-radius problem applies to anything your own organization leaks.
What happened
A credential leak at Ran is now a trust-relationship problem between its systems and connected services, not just a contained internal issue.
Starting Tuesday, an attacker used stolen credentials for 4,837 GitHub accounts to plant a 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.
What changed
In 7,309 of those repositories, the stealer was added to an existing workflow.
More pull requests with the same title were opened early today, after the company's own GitHub search ended on Wednesday, a check by The Hacker News found.
The stealer sends data by HTTP POST to the addresses above or to a Telegram chat, the SafeDep researchers found.
Who is affected
Anyone connected to Ran through the compromised trust relationship is potentially affected, not just Ran itself.
This kind of compromise doesn't stay contained to one company; it travels to everyone who installed the affected package or image, often without any direct relationship to the original leak.
Each attack started with a pull request titled docs: dependency audit notes, opened from a branch named wfx-docs to test whether the account could write to the repository.
Why it matters
A leaked key doesn't need an exploit to be dangerous -- it just needs to still work before someone notices and revokes it.
These test pull requests were opened in 61,764 repositories, and the stealer followed in some of them.
That count covers every repository that received malicious commits, not only those where the stealer ran.
Technical details
The trust mechanism involved here is a federated identity (SSO/SAML) trust relationship, which is what let access move between otherwise unrelated systems.
It ran in at least 1,806 repositories, where the attacker has likely collected those credentials, the company says.
The analysis does not explain how the attacker obtained the credentials.
Response
Ran says the credential has been revoked, and no exploitation has been confirmed so far.
Three that were checked, opened between 05:04 and 05:38 UTC, came from wfx-docs branches.
Owners should also rotate every secret and variable the repository can read.
What security teams should do
If you have any integration or dependency involving Ran, rotate any credentials shared with it as a precaution, even without confirmation you were directly affected.
What remains unknown
It is not clear whether the stealer followed.
The precise vulnerability used to achieve code execution on the IIS server is not known.
What to watch next
Watch for additional victim details, indicators of compromise and follow-on exploitation reports.
Watch for revised vendor guidance, fixed versions and mitigation updates.