In a sweeping analysis conducted in late 2025, Flare researchers uncovered more than 10,000 Docker Hub container images leaking secrets (including production API keys, cloud tokens, CI/CD credentials, and even AI model access tokens) all pushed into public repositories, often unintentionally by developers.

Non-human identities (NHIs): tokens, API keys, service accounts, and workload identities, are the machine-to-machine credentials that power modern software development and cloud infrastructure.

Unlike human users who authenticate with passwords and MFA, these identities authenticate applications, build pipelines, and automated services continuously, often with broad privileges and indefinite lifespans.

When people read about findings like this, the instinctive reaction is often, “They’ll learn the hard way,” or “These must be small companies or inexperienced developers — not serious enterprises or Fortune 500 firms.”

But the reality is far more complex and far more troubling than a shallow headline suggests. These exposures are not edge cases, but are structural failures of how modern software is built and operated.

To understand why, take a look at these real-world nightmares from recent years involving the exposure of non-human identities.

The Snowflake Breach: 165 Organizations Compromised Through Leaked Credentials

One of the most prominent cases that drew widespread media attention was the 2024 Snowflake incident. It was not driven by a software exploit, but by the silent abuse of long-lived credentials that had been leaking into the criminal ecosystem for years.

The threat actor cluster UNC5537 authenticated into approximately 165 Snowflake customer environments using exposed credentials harvested from historical infostealer malware dumps and cybercrime marketplaces.

These credentials (API-like accounts, automation users, and data-access identities) often lacked multi-factor authentication and were designed to persist indefinitely. The data accessed included highly sensitive corporate and customer information belonging to organizations such as AT&T, Ticketmaster, Santander, and others, which was later advertised for sale or used in extortion campaigns. 

Home Depot’s Year-Long Exposure: When a Single GitHub Token Outlasts Its Creator

In late 2025, it was observed that Home Depot’s internal systems remained accessible for over a year due to a single leaked GitHub access token belonging to an employee, which had been inadvertently published in early 2024 and exposed on a public platform.

Automated scanning telemetry showed that this token granted broad rights, including read and write access to hundreds of private source code repositories, as well as entry into connected cloud infrastructure, order-fulfillment systems, inventory management platforms, and developer pipelines.

Effectively treating the token as a valid non-human identity capable of authenticating without challenge. Despite multiple attempts by an external security researcher to alert Home Depot’s security team, the token remained active and publicly accessible for months, only being revoked after third-party media engagement forced action. 

The prolonged exposure underscores a systemic gap in credential governance and automated secret detection: long-lived machine identities without rotation, expiration, or proactive monitoring allowed a static access token to function as a persistent authentication vector across critical internal systems.

This incident did not involve a software vulnerability in the platform itself, but rather the continued validity of a leaked identity token, illustrating how unmanaged non-human credentials can inadvertently open significant attack surfaces in mature enterprise environments. 

Red Hat GitLab Breach: Consulting Repositories Become Unintentional Credential Stores

In October 2025, a Red Hat GitLab instance used by its consulting organization was compromised by the group calling itself “Crimson Collective,” resulting in the exfiltration of tens of thousands of private repositories and hundreds of Customer Engagement Reports (CERs).

These artifacts contained architectural diagrams, deployment configurations, and crucially embedded credentials such as tokens, database URIs, and service keys that had flowed into the repository over time as part of consulting engagements.

By mixing contextual data with static secrets inside GitLab, what should have been neutral code storage effectively became an unintentional credential store and access map, exposing sensitive material that could be used as valid authentication vectors across customer environments. 

The risks of NHI can’t be ignored.

Let’s go back to the Flare research that uncovered over 10,000 container images related to over 100 organizations and contained thousands of live keys. Below, you can see a further breakdown of the secrets found:

So why do container images contain keys in the first place? Because to function, build, and operate, they must authenticate to many different environments – cloud platforms, APIs, databases, CI/CD systems, and internal services.

Since this access is performed by software rather than people, it relies on non-human identities such as tokens, API keys, and service accounts. These machine identities are now deeply embedded in the modern software development lifecycle and production infrastructure, powering everything from code builds to application runtimes behind the everyday technology we all use.

Non-human identities have become one of the most critical (and least understood) pillars of the modern software development lifecycle. Every build, test, deployment, and production workflow now runs on machine-to-machine authentication: CI runners pulling code, pipelines pushing containers, cloud services provisioning infrastructure, applications calling APIs, and models querying data. 

These processes do not log in with usernames and passwords, instead they rely on tokens, API keys, service accounts, OAuth apps, and workload identities that operate continuously, often with broad and persistent privileges.

Unlike human users, these identities don’t change jobs, don’t get phished, and don’t forget passwords, which is exactly what makes them dangerous when exposed. In a paradoxical way, a non-human identity can far outlive the human who created it.

The admin-level super key issued by a senior DevOps engineer five years ago (who may now be the CTO of a fast-growing startup) is often still alive, fully privileged, and quietly waiting in the shadows.

Unlike people, these machine identities don’t change roles, leave the company, or get deprovisioned unless someone explicitly remembers to do so, making them some of the most persistent and dangerous artifacts in modern infrastructure.

If a non-human identity leaks into a repository, container image, or log file, it can grant attackers silent, durable, and legitimate access deep into an organization’s software development lifecycle (SDLC), often bypassing detection entirely because everything looks like normal automation.

In today’s cloud-native world, controlling non-human identities is no longer a hygiene task – it is the security boundary of the SDLC itself.

What This Means for Security Teams and Incident Response

The key takeaway from this incident is simple: Attackers are already authenticating with leaked secrets found in public container registries. This isn’t a theoretical risk – it’s happening now.

We ought to treat non-human identities as human identities and monitor their behavior, limit their access, and delete them when they are no longer needed.

For defenders, the imperative is clear:

• Treat container images like code AND credentials. They are no longer just deployable artifacts — they are potential leak vectors for sensitive keys.

• Integrate automated secret scanning at every stage of the SDLC. Catch leaks before images are pushed anywhere public.

• Adopt short-lived, ephemeral credentials backed by identity federation rather than long-lived tokens baked into images.

• Monitor for exposed keys in public registries and revoke them proactively – don’t wait for an attacker to misuse them.

Fortunately, the security industry has responded with specialized tooling. Platforms designed for Threat Exposure Management—such as Flare and similar solutions—continuously scan public registries and code repositories for exposed credentials, map them to real attack surfaces, and enable rapid remediation.

For organizations managing thousands of non-human identities across their SDLC, automated detection and revocation capabilities are no longer optional.

Learn more by signing up for our free trial.

Sponsored and written by Flare.

Ravie LakshmananFeb 02, 2026Developer Tools / Malware

Cybersecurity researchers have disclosed details of a supply chain attack targeting the Open VSX Registry in which unidentified threat actors compromised a legitimate developer’s resources to push malicious updates to downstream users.

“On January 30, 2026, four established Open VSX extensions published by the oorzc author had malicious versions published to Open VSX that embed the GlassWorm malware loader,” Socket security researcher Kirill Boychenko said in a Saturday report.

“These extensions had previously been presented as legitimate developer utilities (some first published more than two years ago) and collectively accumulated over 22,000 Open VSX downloads prior to the malicious releases.”

The supply chain security company said that the supply chain attack involved the compromise of the developer’s publishing credentials, with the Open VSX security team assessing the incident as involving the use of either a leaked token or other unauthorized access. The malicious versions have since been removed from the Open VSX.

The list of identified extensions is below –

• FTP/SFTP/SSH Sync Tool (oorzc.ssh-tools — version 0.5.1)
• I18n Tools (oorzc.i18n-tools-plus — version 1.6.8)
• vscode mindmap (oorzc.mind-map — version 1.0.61)
• scss to css (oorzc.scss-to-css-compile — version 1.3.4)

The poisoned versions, Socket noted, are designed to deliver a loader malware associated with a known campaign called GlassWorm. The loader is equipped to decrypt and run embedded at runtime, uses an increasingly weaponized technique called EtherHiding to fetch command-and-control (C2) endpoints, and ultimately run code designed to steal Apple macOS credentials and cryptocurrency wallet data.

At the same time, the malware is detonated only after the compromised machine has been profiled, and it has been determined that it does not correspond to a Russian locale, a pattern commonly observed in malicious programs originating from or affiliated with Russian-speaking threat actors to avoid domestic prosecution.

The kinds of information harvested by the malware include –

• Data from Mozilla Firefox and Chromium-based browsers (logins, cookies, internet history, and wallet extensions like MetaMask)
• Cryptocurrency wallet files (Electrum, Exodus, Atomic, Ledger Live, Trezor Suite, Binance, and TonKeeper)
• iCloud Keychain database
• Safari cookies
• Data from Apple Notes
• user documents from Desktop, Documents, and Downloads folders
• FortiClient VPN configuration files
• Developer credentials (e.g., ~/.aws and ~/.ssh)

The targeting of developer information poses severe risks as it exposes enterprise environments to potential cloud account compromise and lateral movement attacks.

“The payload includes routines to locate and extract authentication material used in common workflows, including inspecting npm configuration for _authToken and referencing GitHub authentication artifacts, which can provide access to private repositories, CI secrets, and release automation,” Boychenko said.

A significant aspect of the attack is that it diverges from previously observed GlassWorm indicators in that it makes use of a compromised account belonging to a legitimate developer to distribute the malware. In prior instances, the threat actors behind the campaign have leveraged typosquatting and brandjacking to upload fraudulent extensions for subsequent propagation.

“The threat actor blends into normal developer workflows, hides execution behind encrypted, runtime-decrypted loaders, and uses Solana memos as a dynamic dead drop to rotate staging infrastructure without republishing extensions,” Socket said. “These design choices reduce the value of static indicators and shift defender advantage toward behavioral detection and rapid response.”

Update

Secure Annex researcher John Tuckner told The Hacker News that three of the aforementioned extensions were still available for download as of February 2, 2026, 6:30 a.m. UTC. They have since been removed from Open VSX as of writing –

• oorzc.mind-map@1.0.61
• oorzc.i18n-tools-plus@1.6.8
• oorzc.scss-to-css-compile@1.3.4

“This is also tricky because victims will have to wait until the real developer publishes a new higher version in order for an auto update to be triggered,” Tuckner said. “Even if the extensions are removed from the marketplace, they won’t uninstall from editors.”

(The story was updated after publication to include details of the extension status.)