Application Security 2026: Recent Hacks and Fixes

Application security is the work of keeping the software you build, and the systems that build it, from being turned against you. In 2026 the headlines keep telling the same story. The attacker did not need a clever exploit. They found a key, borrowed a token, or walked through a build pipeline that nobody had locked.

This guide walks through the biggest incidents of the past few months, from the GitHub credential campaign that started on November 10 to the platform breaches of October. Then it shows what they have in common, and how Puaro (our secret scanner for GitHub and GitLab) helps you close those gaps. We also say where a secret scanner does not help, because that matters just as much.

💡

A note on scope. No list of 2026 incidents is complete. We picked the ones where a credential, a code repository, or a build pipeline played the central part, and we link the original reports so you can check our reading. All figures come from those reports, and several investigations are still open.

Key takeaways

Every incident below involved a credential. It was either the way in or the prize.
Deleting a secret from a file does not revoke it. LiteLLM's key stayed valid for more than four months after the file was removed.
Rotation has to be complete. Zeabur's August cleanup missed the keys used in October, and the wfx-loot malware plants access that survives a secret rotation.
Your build pipeline, your laptop, and your AI coding tools hold secrets too. Attackers know it.
One set of detectors misses a lot. In a scan of 7.25 million public repositories, either of two well known scanners alone found only about half of the working credentials.
Puaro scans pull requests, merge requests, pushes, full repositories, and git history on both GitHub and GitLab. Git Notes scanning is built and in final testing.

The recent hacks, newest first

wfx-loot: hijacked GitHub accounts plant a CI secret stealer (November 2026, ongoing)

Aikido named this campaign wfx-loot. Starting November 10, an attacker used stolen GitHub credentials from 4,837 accounts to open probe pull requests in 61,764 repositories. The stealer actually ran in more than 1,800 of them, according to Help Net Security's report.

The malware goes after GitHub Actions secrets, cloud and SSH credential files, shell histories, and tokens for AI tools such as OpenAI, Anthropic, Cursor, and Copilot. It then uses them to reach AWS, GCP, and Azure.

What makes it hard to clean up is the persistence. It rewrites an AWS role's trust policy so that any AWS account can assume the role. It adds federated identity credentials to Azure applications. It forges passing status checks to get past branch protection. Rotating your secrets will not remove any of that.

Aikido says it does not yet know how the attacker got the GitHub credentials in the first place. If one of your workflows ran the payload, the advice is to treat every secret and cloud role that workflow could reach as compromised.

Claude Code settings files leak secrets into public repositories (November 2026)

Security firm Apiiro found more than 104,000 copies of a Claude Code settings file, .claude/settings.local.json, in public GitHub repositories. Of those, 1,122 held real, active secrets, and the wider search counted 2,539 credentials across nearly 2,000 repositories, as Tech Times reported. Database passwords, cloud tokens, SSH credentials, and infrastructure keys were among them.

This is not a breach of Anthropic. The file stores the shell commands a developer approved, and a command can contain a password. When the file is committed, the password goes public with it.

The lesson is bigger than one tool. AI coding assistants write settings, logs, and session files into your project folder, and people commit them without reading them. We covered the human side of this in our post on vibe coding and security.

Gitee: 26,400 working credentials in 7.25 million public repositories (October 28)

Independent researcher Ben Zimmermann, working with the Kingfisher team at MongoDB, scanned 7,256,531 public Gitee repositories. He verified that 26,400 unique credentials still worked. The most common were Alibaba Cloud keys (9,473), YouTube API keys (3,805), and DeepSeek keys (3,170), according to the MongoDB write up.

The number that matters most for defenders is the overlap. TruffleHog found 12,737 credentials and Kingfisher found 14,664, but only 1,001 were found by both. In the author's words, either scanner alone would have caught only about half. Detector coverage is not a detail. It decides what you see.

LiteLLM: a key deleted from a repository, never revoked (May 27 to October 21)

LiteLLM published its own timeline, and it reads like a checklist of what not to do. An opencode.json file containing an administrative key was committed to a public repository on May 27. About three hours later a second commit deleted the file. The original commit stayed in public history until October 22, and the key was never revoked, which LiteLLM calls human error.

On October 10 an attacker used the key and received the GitHub token of an organization owner. On October 21 a malicious litellm==1.107.0 reached PyPI and container registries and stayed live for about two hours. Read the full LiteLLM attack chain.

LiteLLM had a rougher year than most. In March, versions 1.82.7 and 1.82.8 were published with malicious code by a group called TeamPCP and sat on PyPI for about three hours, per Zscaler.

Railway: build infrastructure breach exposes environment variables (October 20 to 22)

Railway's preliminary report describes a possible privilege escalation in its build infrastructure. The attacker queried encrypted environment variables and decrypted a subset. Railway says at most 1.85% of workspaces, about 100,000, may have had variables exposed. The attacker also reached credentials for Railway's own CI environment, and Railway has not ruled out access to user source code.

Railway revoked every access token and asked customers to rotate the keys they stored there. The full root cause is left for a final report.

Zeabur: plaintext admin keys in a private repository (October 14 to 15)

Zeabur's incident report says its cluster admin tokens and several cloud keys sat in plaintext in a private configuration repository. The admin tokens had no expiry and dated back to 2024, and the admin interface was reachable from the public internet.

This was the company's second breach in about two months. Its August cleanup had not covered these keys, and Zeabur now says its August statement that all internal admin keys were rotated was incomplete. The attacker read 321,810 accounts and 3,218,965 environment variable records. BleepingComputer reports that Zeabur is shutting down.

Qubole: old cloud roles open the door to customers (October 14 to 26)

According to SecurityWeek, attackers used compromised IAM credentials from a Qubole associated AWS account to assume cross account roles that customers had created for Qubole. Sentra noted that those roles stayed in place long after companies stopped using Qubole. Over a dozen organizations lost files, secrets, keys, and environment variables.

TanStack and Mini Shai-Hulud: a trusted pipeline publishes the malware (May 11)

Attackers published 84 malicious versions across 42 @tanstack/* npm packages in six minutes. They did not steal an npm token. As Snyk explains, a fork pull request triggered a workflow that used pull_request_target (a GitHub Actions trigger that runs with the base repository's permissions). That workflow poisoned a build cache. A later release run restored the cache, and the malware read a short lived identity token (an OIDC token) from the runner's memory and used it to publish.

The malicious packages carried valid provenance records. The malware then harvested credentials from GitHub Actions, AWS, Vault, Kubernetes, ~/.npmrc, ~/.git-credentials, and SSH keys, and kept its foothold through .claude/settings.json hooks and .vscode/tasks.json.

GitHub internal repositories (May 18 to 20)

GitHub said it "detected and contained a compromise of an employee device involving a poisoned VS Code extension," and that the activity involved GitHub internal repositories only. The attacker group TeamPCP claimed roughly 4,000 repositories and later cited about 3,800, a figure GitHub called "directionally consistent" with its investigation. GitHub later linked the incident to the TanStack attack. All of this is from BleepingComputer's coverage of GitHub's statements.

Earlier in 2026

Axios (March 30 to 31): an attacker took over a lead maintainer's npm account, changed its email, and published two malicious versions by hand, skipping the project's GitHub Actions pipeline. Zscaler attributes it to a North Korean actor.
Trivy (February and March): Aqua Security traced its compromise to a misconfigured GitHub Actions environment, and an incomplete credential rotation left access behind, as GBHackers summarizes.

For older cases, see our write ups of the GhostAction attack, the GlassWorm supply chain attack, the Claude Code source map leak, prompt injection through git push, and the Zealot autonomous cloud break in.

What these hacks have in common

1. A credential was the way in or the prize

LiteLLM's admin key, Zeabur's admin tokens, Qubole's IAM credentials, the Axios maintainer's npm account, the TanStack release token, the GitHub credentials behind wfx-loot. Different companies, same ingredient. Attackers rarely break in when they can log in.

2. Deleting is not revoking

LiteLLM removed the file in three hours. The key stayed valid for more than four months. Git remembers every commit, so a secret removed from the latest version of a file is still readable in history. The only fix is to revoke the key with its provider.

3. Rotation was late, partial, or never finished

LiteLLM never revoked. Zeabur's August rotation missed the keys used in October. Aqua's Trivy cleanup left residual access. wfx-loot builds access that survives rotation on purpose. A rotation you cannot prove is finished is a rotation you should not trust.

4. Secrets live outside your source files

CI environments, laptops, shell histories, ~/.npmrc, AI tool settings, and environment variable stores all hold live credentials. A scanner that reads only your main branch sees a fraction of them.

5. Old access lingers

Qubole's roles outlived the vendor relationship. Zeabur's admin tokens never expired. Access that nobody remembers is access that nobody watches.

6. One detector set is not enough

The Gitee scan showed two good scanners agreeing on only 1,001 of 26,400 credentials. Ask any vendor, including us, how its detectors were built and where they are weak.

What a secret scanner can and cannot do

A secret scanner is one layer of application security, not the whole stack. Here is an honest map of the incidents above.

wfx-loot

Where secret scanning helps: Shows which secrets live in your repositories and workflows, so you know what to rotate first.
Where it does not: Cannot stop hijacked accounts or remove cloud trust policy changes.

Claude Code settings

Where secret scanning helps: Flags credentials in a committed settings file, on push, in pull requests, and in full scans.
Where it does not: Cannot change how a tool stores approved commands.

LiteLLM

Where secret scanning helps: Flags a key in a pushed commit, and still reports it as Found in history after the file is deleted.
Where it does not: Cannot revoke the key for you. You or your provider must do that.

Zeabur

Where secret scanning helps: Finds plaintext tokens and cloud keys in private repositories and in their history.
Where it does not: Cannot close an admin interface that faces the internet.

Gitee scan

Where secret scanning helps: Shows how much is exposed in public repositories, so you can check your own first.
Where it does not: Gitee is not a supported host.

TanStack, Axios, GitHub

Where secret scanning helps: Finds long lived credentials committed to your repositories, so there is less for malware to harvest.
Where it does not: Is not a package firewall, does not fix pull_request_target workflows, and cannot see tokens that exist only on a laptop or a runner.

Railway, Qubole

Where secret scanning helps: Helps you keep an inventory of what you stored where, and track rotation.
Where it does not: Cannot stop a breach inside someone else's platform.

Puaro does not replace penetration testing, dependency scanning, or workflow hardening. It covers one job: finding hardcoded credentials early and helping you close them for good.

What is new in Puaro

Puaro is a cloud hosted secret scanner for GitHub and GitLab. It runs on pull requests, merge requests, pushes, full repository scans, and historical commit walks. There is nothing to install and no scanner infrastructure to run. Here are the recent capabilities that map to the incidents above.

Git Notes scanning (in final testing)

Git notes are small pieces of text attached to a commit. They live under refs/notes/*, outside your branches and your file tree, so they never show up in a pull request diff or in the repository file browser. Some AI coding and developer tracking tools can attach session logs to commits as notes. If a developer pasted a key into that session, the key can end up in a note and then be pushed with the repository.

Scanners that read only the file tree never see these notes. Puaro's Git Notes scanning reads them. In the first phase, a full repository scan on GitHub or GitLab fetches the notes refs and checks each note with the same engine as your files: pattern checks, entropy checks, and AI review. A finding from a note is its own kind. It links to the commit the note is attached to, and Open fix is turned off for it, because a note is not a line in your code. Puaro shows cleanup steps instead: revoke the key first, then remove the notes ref.

⚠️

Status as of November 12, 2026: Git Notes scanning is built and in final testing. It is not in production yet, and the first phase covers full repository scans only. Scanning notes on pull requests and merge requests is planned for a later phase. You can check the features page for what is live today.

You can already look for notes yourself:

git ls-remote origin 'refs/notes/*'
git log --show-notes='*'

GitLab next to GitHub, in one workspace

GitLab is live in production. You can connect GitLab.com with OAuth, or connect a self managed GitLab instance that is reachable over public HTTPS with a Personal Access Token. Puaro scans merge requests, posts a commit status named Puaro and a note on the merge request, and can open a fix merge request with Open fix MR. Merge request alerts can go to Slack.

If your code lives on both hosts, you get one list of findings instead of two tools. GitLab behind a private network and Bitbucket are not supported today. See integrations for the current status.

Git history walks for keys you thought were gone

LiteLLM's key was deleted and still dangerous. Puaro's historical commit scan walks past commits for secrets that are gone from the current branch. Those findings are labeled Found in history, and the guidance is to rotate the credential and record it with Mark as rotated, not to edit code. We completed a full history and AI scan of the Linux kernel repository (1,462,177 commits) to prove the walk holds up on very large histories.

Blast radius maps

When a credential leaks, the first question is "what else does this touch?" Puaro's secret flow analysis shows where a secret is declared, where it is used, and which files import it. That is the map you need when a campaign like wfx-loot tells you to treat everything a workflow could reach as compromised.

Low noise findings with an AI Context Engine

Puaro starts with more than 2,000 detection patterns (regex and entropy), then adds code structure analysis and an AI review that reads the surrounding code. The AI marks likely test fixtures, mocks, documentation examples, and placeholders with an AI false positive flag. It never deletes a finding row, and it never lowers a critical pattern match below high severity. Fewer false alarms mean developers keep trusting the check. See the methodology and our benchmark report for how we measure this.

Policy, validity checks, and alerts

You can set a block, warn, or notify policy per repository on pull requests and merge requests. Puaro runs read only validity checks for seven providers (GitHub, GitLab, OpenAI, Slack, SendGrid, Stripe, and AWS access key pairs), so you can see whether a leaked key still works. Coverage depends on the provider and credential type, so it is not a promise for every secret. Alerts reach you through Slack and email.

Repository snapshots are discarded after each scan by default. Puaro keeps the finding details and the matched line it needs to show you the result.

A practical checklist for this week

You can run any of these, or skip the ones that do not fit your team.

Keep the native protections on. GitHub push protection and GitLab secret detection are good first gates. Puaro works alongside them.
Run a full repository scan and a history scan. The history scan is where forgotten keys like LiteLLM's show up. You can start on the free plan.
Check for AI tool files in your repositories. The two commands under this list show whether a Claude Code settings file is tracked and when it first appeared.
Revoke, then clean up. Revoke the exposed key with its provider first. Then remove it from files and history. Then record the rotation so you can show it finished.
Audit pull_request_target workflows. If a workflow runs fork code with repository permissions, consider moving that work to a safer trigger. Pin third party actions to a full commit SHA.
Prefer short lived credentials. OIDC federation and tokens that expire shrink the window an attacker has.
Remove stale access. List cloud roles and tokens for vendors you no longer use, and delete the ones nobody owns.
Look for notes. Run the two git notes commands from the Git Notes section on a few repositories, especially ones where AI tools are used heavily.

For step 3, these commands list tracked settings files and their history:

git ls-files | grep -E '\.claude/|settings\.local\.json'
git log --all --oneline -- .claude/settings.local.json

If a settings file is tracked, you may want to run git rm --cached on it and add it to .gitignore. Then revoke any credential it held, because the old commits still contain it. Puaro does not skip .claude/ folders, so a committed settings file is checked like any other file.

Frequently asked questions

What is application security?

Application security is the set of practices and tools that protect software across its life: how it is designed, built, tested, deployed, and run. It includes code scanning, dependency checks, secret scanning, and protecting the build pipeline. This guide focuses on the credential and pipeline side, which drove most of the 2026 incidents above.

What caused most of the 2026 breaches?

Credentials. Leaked keys, plaintext admin tokens, hijacked accounts, and stolen CI tokens were the entry point or the target in every incident in this post.

Does deleting a leaked secret from my repository fix it?

No. Git keeps the old commit, so the secret stays readable in history. Revoke the key with its provider, then clean up the files and history, then record the rotation.

Can a secret scanner stop supply chain attacks?

Not alone. A scanner finds hardcoded credentials in your repositories, which are what a worm harvests. It does not block a poisoned package or fix a risky workflow trigger. Use it together with workflow hardening, pinned dependencies, and short lived credentials.

Does Puaro work with GitLab?

Yes. GitLab.com connects with OAuth, and self managed GitLab connects with a Personal Access Token when it is reachable over public HTTPS. Puaro scans merge requests, posts a status and a note, and can open a fix merge request. Private network GitLab and Bitbucket are not supported today.

Is Puaro free to try?

Yes. The free plan covers up to 5 developers and 10 repositories, with unlimited seats and no credit card. See pricing for the paid plans.

The bottom line

The 2026 incidents are not exotic. A key was committed and not revoked. A token sat in plaintext in a private repository. A pipeline trusted something it should not have. A rotation stopped one step early. Each one is the kind of problem that a steady habit of scanning, revoking, and tracking can shrink.

You do not have to fix everything this week. A good first step is to scan your repositories and their history, then see what a scanner finds that your team had forgotten. Start free on Puaro, read the getting started guide, or talk to us about a larger team.