LiteLLM supply chain attack, Zeabur breach, Gheist: Unrevoked credentials

Illustration of a speech bubble featuring the text “Cybersecurity News Weekly” and a yellow lightning bolt, representing a weekly cybersecurity news roundup.

A key committed to a public repository in May helped poison a release of a widely used AI gateway in October. Days apart, a hosting platform admitted that admin tokens untouched since January 2024 opened its production systems.

These incidents share one flaw: credentials that stayed valid long after they should have been revoked, scoped or rotated. Below are five incidents, what each one shows, and what to check first.

LiteLLM: An unrevoked master key led to a stolen GitHub owner token and a malicious release, according to LiteLLM and Microsoft.
Zeabur: Plaintext admin tokens with no expiry exposed 321,810 accounts, says Zeabur.
Gheist: Stolen GitHub tokens plant workflows that print repository secrets into logs, reports Help Net Security.
PingCAP: Stolen credentials gave attackers access over a 28-day reported window, per PingCAP.
Aokigahara: An infostealer collects AI coding tool credentials and cloud keys, writes Check Point Research.

LiteLLM 1.107.0: A leaked master key became a poisoned release

What happened: On 27 May 2026, a master key for the LiteLLM Agent Platform was committed to a public GitHub repository. LiteLLM's attack-chain write-up says the commit was overwritten, but The Hacker News reports that the key itself was never revoked. On 10 October an attacker used it to read a GitHub CLI OAuth token belonging to an organization owner. LiteLLM says the token was not scoped down, so it opened every repository in the organization.

The attacker then pushed short-lived workflows that posted repository secrets to an external endpoint. Socket counts 20 distinct secret names across the recovered 10 and 12 October workflows, from GitHub tokens to Anthropic, OpenAI and database credentials, and puts the compromise window at "at least eleven days" before the release. LiteLLM's own timeline is narrower: the first 10 October run posted six secrets, including GH_TOKEN, the second posted RELEASE_PLEASE_TOKEN, and later runs on 12 October across private repositories posted more.

On 21 October the attacker pointed the release pipeline at a lookalike repository, Berri-AI instead of BerriAI. According to The Hacker News, a stricter approval rule had recently been relaxed so that any two engineers could trigger and approve a release. Stolen tokens did the rest: the owner's token triggered the release, a second maintainer's token (stored as GH_TOKEN) approved the production gate, and a third's (RELEASE_PLEASE_TOKEN) deleted the run records afterwards. Seven malicious wheels of LiteLLM 1.107.0 reached PyPI around 11:40 UTC, and Microsoft's analysis shows the payload ran at Python startup, even if LiteLLM was never imported. PyPI had quarantined the version by 13:23 UTC, so the wheels were live for about 1 hour 43 minutes.

Why it matters: The stealer targets cloud and Kubernetes credentials, Git and package registry tokens, SSH keys, dotenv files, browser credentials and AI tool configuration. Anyone who installed 1.107.0 on a host with internet access should assume everything that host could reach is exposed. Microsoft states that removing the package or a release tag is not sufficient recovery, because the startup files sit outside the LiteLLM directory.

The defensive takeaway: Do not start with pip install, because any Python start reruns the payload. Pin to 1.106.2, as LiteLLM advises. Check for cook.pth and sitecustomize.py in every environment, plus cook.py, matching pycache files and the detached loader holding /tmp/remote_code_loader.lock, and rebuild from clean images instead of cleaning in place. Rotate everything the host could reach from a clean machine, and check CloudTrail for the instance role being used from outside your infrastructure. Microsoft's findings on stolen session material make revoking sessions, not only keys, sensible too. Then ask the harder question: if a secret leaks into a repository, who revokes it, and how do you confirm it no longer works?

Sources: LiteLLM; Microsoft Security; Socket; The Hacker News; LiteLLM incident post

Zeabur: Admin tokens unrotated since January 2024 expose 321,810 accounts

What happened: On 14 and 15 October 2026 (UTC), an attacker used internal credentials that Zeabur says were stored in plaintext in a private configuration repository, with GCP root passwords kept in server initialization settings. The shared-cluster admin tokens had no expiry, the admin interface was reachable from the public internet, and Zeabur has not confirmed how the attacker first obtained them, treating a link to its August incident as a hypothesis. The attacker read environment variables across shared clusters, signed in as root to 101 dedicated servers on GCP, affecting 92 users, and read the platform database: 3,218,965 environment-variable records and 321,810 accounts, per Zeabur's report.

BleepingComputer reports that this was the platform's second breach in less than two months. Zeabur's shutdown notice says dedicated-server renewals are disabled and shared clusters paused from 1 December, each dedicated server expires between 1 and 31 December, and everything stops by 31 December. Zeabur says its August rotation did not cover the credentials used this time. The counts above show what was in scope, not proof that every value was downloaded, and Zeabur says its logs are incomplete in places.

Why it matters: The August incident was the warning, and the rotation after it was incomplete. Zeabur also reports more than 16 hours of attacker activity on 14 October that raised no alerts. Every environment variable on the platform held a customer's own secrets, so one platform breach became thousands of downstream credential leaks.

The defensive takeaway: The next steps are our advice rather than Zeabur's: build a complete inventory of admin tokens and cloud keys before you need to rotate them. Put an expiry on every long-lived token, keep admin interfaces off the public internet, and keep credentials out of repositories and server initialization settings. If you host on a platform like this, treat every variable you stored there as exposed and replace it.

Sources: Zeabur; BleepingComputer; Zeabur shutdown notice

Gheist: Stolen GitHub tokens turn CI workflows into secret harvesters

What happened: Wiz Research recovered more than 13,500 planted branches from 850+ compromised GitHub accounts and named the campaign Gheist after the user agent it uses. Wiz began tracking it on 15 September and published on 25 October, as Help Net Security reports. The tool takes a stolen token, finds every repository it can open, and pushes a branch named "ci-sync-" plus six characters with a workflow called "sync-check". The workflow prints repository secrets into a run log in Base32-encoded form, a form that GitHub's log masking misses. The tool downloads the log through the API and deletes the run seconds later, so Wiz found no attacker domain or outbound connection to block. GitHub masks secrets only when they appear verbatim, which is why the encoded values print in full.

Since 28 July, GitHub holds certain potentially malicious workflow runs for approval, but only in public repositories on github.com. Wiz says the hold does not cover private repositories or GitHub Enterprise Server, and that it saw exploitation there. In enterprise organizations, Wiz saw the tool cycle through the tokens of several users and automation accounts within minutes, and hours later cloud credentials from the same organization were used to enumerate AWS Secrets Manager. Wiz does not name the organizations or say how many were affected.

Why it matters: One stolen personal token can expose every secret in every repository its owner can reach, including environment-scoped production credentials. Deleting the run does not undo the exposure.

The defensive takeaway: Review the GitHub audit log for the "gheist" user agent and cloud logs for OIDC role assumptions tied to "ci-sync-" branches. Wiz advises rotating every repository, organization and environment secret a compromised token could reach and revoking the tokens themselves. The branch signal only works if your OIDC subject includes the branch. Limit which tokens can push workflows, and alert on new workflow files in new branches.

Sources: Help Net Security; Wiz; GitHub changelog

PingCAP: Stolen credentials, 28 days of reported access

What happened: PingCAP reports that from 9 September to 7 October 2026 an unauthorized party used stolen service account credentials to reach internal systems, copy data and obtain source code. The company learned of it on 7 October and began disabling the credentials that day. Exposed data includes TiDB Cloud account and product-use data, contract and billing details, and encrypted API-key values. PingCAP says there is no evidence that data stored in customer TiDB databases was accessed or impacted, but customer-related records in its internal analytics, storage and support systems were copied, and it is still determining whether other usable credentials were exposed. Its 19 October report does not say how the credentials were stolen. PingCAP's CEO note of 23 October and NebuSec's analysis later describe the initial entry as a compromised GitHub account and exposed credentials, and say the encryption key for the exported API-key values was not exposed, so they could not be decrypted into usable keys. That does not cover credentials customers shared in support materials.

Why it matters: Service accounts rarely have an owner, an expiry or a person who notices odd behavior. The reported access window was 28 days, though not necessarily one uninterrupted session.

The defensive takeaway: Give every service account a named owner, the narrowest permissions that work and a rotation date. Alert on unusual large exports. PingCAP describes wider credential rotation, access reviews and expanded secret scanning as ongoing work, which makes a reasonable template for your own list.

Sources: PingCAP; PingCAP CEO note; NebuSec

Aokigahara: An infostealer that goes after AI coding tool credentials

What happened: Check Point Research documents (23 October) a Windows infostealer it calls Aokigahara, with a dedicated handler for AI tool sessions. It looks for files used by Claude, Codex, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Amazon Q, Kiro and JetBrains AI Assistant, plus AWS credentials and SSO caches. Its IDE handler also collects Git credential files, SSH files that may hold private keys and Azure and Google Cloud credentials. Older functions remain: browser passwords and cookies, crypto wallets and data from password manager applications. Symantec's 15 October report, which Infosecurity Magazine covered, identifies the malware as Aoki (aka Aokigahara), first seen earlier in 2026, and says stolen AI keys can be resold or used to run up charges on a victim's account, a practice sometimes called LLMjacking.

Why it matters: A developer laptop holds the same credentials attackers used against LiteLLM: tokens, cloud keys and SSH keys. Check Point says it could not confirm how operators monetize the data, and lists resale, paid-service abuse and extortion as possibilities. The lists above are what the stealer collects, not proof that every victim's data was exfiltrated.

The defensive takeaway: Treat AI tool credentials and session files as sensitive as browser sessions, cloud credentials and developer keys, as Check Point advises. Keep long-lived keys off developer machines where you can, use short-lived tokens, and rotate fast when a workstation is flagged.

Sources: Check Point Research; Symantec; Infosecurity Magazine

What this means for your team

Every story above ends the same way: a credential that someone assumed was dead was still working. Six checks to run now:

Revoke on exposure. Overwriting a commit does not invalidate a key. Treat any secret that touched a repository, log or chat as burned, and confirm the old value no longer works.
Scope and expire every token. Replace organization-owner tokens with narrow, short-lived ones. Put an expiry on admin and service tokens so a token from January 2024 cannot open anything in October 2026.
Keep approval gates that two stolen tokens cannot satisfy. Release approval should depend on identities and devices that a CI token cannot impersonate, and a relaxed rule should trigger a review.
Lock down CI secrets. Prefer short-lived cloud access over stored keys, restrict who can push workflows, and alert on new workflow files in new branches, including in private repositories.
Treat developer machines and AI tool configs as secret stores. Inventory what sits in dotenv files, SSH directories and AI assistant sessions, and rotate from a clean machine after a compromise.
Rotate completely, not partially. Keep an inventory of every admin token and cloud key, so a rotation after an incident covers all of them.

If API keys, tokens and service credentials still live in config files and chat threads, moving them into one place is the first step toward revoking them on schedule. Passwork keeps them in encrypted vaults with role-based access and an activity log, so you can see who reaches each secret and rotate it once. Try Passwork free.