Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label GitHub repositories breach. Show all posts
npm
API Keys Credentials Data Breach Gemini GitHub Access Token GitHub repositories breach npm

Half a Million GitHub Credentials Are Still Active, Most Have Been Sitting in the Open for Years





Researchers at Truffle Security tested 543,699 API keys, database passwords, and access tokens found in public GitHub repositories last July. Every single one authenticated. The median credential had been sitting in publicly readable code for 784 days.

The findings come from a scan of The Stack v3, a 224-million-repository snapshot of public GitHub code assembled to train large language models. The crawl closed on August 7, 2025. Eleven months later, when Truffle Security ran live verification against each issuing provider, more than half a million credentials still worked. That number is more than double the 221,303 live credentials the company found when it ran a similar scan against 7.6 petabytes of Hugging Face training data earlier this year.

The oldest credential in the dataset was last touched on June 13, 2009. It lives inside an Erlang web server configuration file, and it was still valid 16.1 years after it was committed. Behind it: an FTP login inside a GPS logger's C source code from September 2009, replicated across 62 repositories, and an AWS key tucked inside a Rails S3 config from November of that same year. Truffle Security declined to name the repositories because the credentials in them still work.


A Protection That Only Faces Forward

GitHub has progressively tightened its defenses around exposed credentials. The platform made secret scanning alerts free for all public repositories in February 2023. Push protection, which blocks a commit before it reaches the remote branch if it carries a recognised secret, became generally available in May 2023 and was switched on by default for all public repositories on February 29, 2024.

GitHub's secret scanning covers more than 200 token types and patterns from over 180 service providers. The rollout had a measurable effect on new leaks. Among credential shapes the system recognises and blocks, Truffle Security found a 53 percent drop in the rate of fresh exposures across the twelve months following the default rollout, compared to the twelve months before it. Slack tokens fell 64 percent, GitHub's own tokens and AWS access keys each fell 59 percent.

But push protection has no mechanism to reach the credentials already there. Of the 543,699 live credentials, 199,843 landed after push protection became the default in February 2024. Developers either bypassed the block or committed credential types the system does not recognise.

That second category is the larger problem. Truffle Security found that 51.8 percent of every live credential in the dataset is a shape that a default-configured public repository will accept without objection. Database connection strings, private keys, and Google API keys all fall outside the default block list. Push protection focuses on specific, highly identifiable secrets and misses generic ones. Connection strings and private keys are classified as generic patterns, and blocking them requires an organisation to go into settings and explicitly opt in.


The Gemini Problem

The Google API key situation illustrates the limits of pattern-based blocking in particularly sharp terms. The 33,343 live Google API keys in Truffle Security's dataset include 31,374 that authenticate specifically to Gemini, Google's AI model platform. Their median leak date is February 2025, meaning the entire population is younger than the push protection rollout.

Google API keys carry the prefix `AIzaSy` whether they were created for Google Maps, Firebase, or Gemini. GitHub's pattern list recognises the prefix but marks it as not push-protected, because a Maps key sitting in client-side JavaScript is not a secret by design. Google's own approach to API keys was historically built around the assumption that these keys would live in client-side code, exposed to anyone who opened a browser's developer tools. The problem is that Gemini runs on the same key format, turning what developers were trained to treat as a non-sensitive identifier into a billable AI credential. One pattern cannot distinguish between the two uses, so nothing gets blocked, and the keys that matter arrive alongside the keys that do not.


Revocation is the Deciding Variable

The most instructive comparison in the data is between providers that automatically revoke leaked tokens and those that do not.

npm committed 101,886 tokens to public code. One remains live. GitHub committed 73,048 tokens; 260 survived. Hugging Face committed 30,437; 15 are still valid. Each of these platforms runs an automated pipeline that kills a token the moment it is detected in public code.

The contrast with database credentials is stark. Of 12,985 Postgres connection strings in the dataset, 11,465 are still live, an 88 percent survival rate. MySQL connection strings survive at 75 percent. MongoDB, where the detector only reports a URI it successfully connected to, returned all 51,067 live.

Push protection blocks secrets at the door. Automated revocation kills them wherever they are. The Truffle Security data shows that the second mechanism is the one that changes the outcome, and for the majority of credential types sitting in public repositories right now, no provider is running it.

The practical guidance from the researchers: treat any committed credential as compromised regardless of whether anything flagged it, scan your own repository history rather than assuming the push-time block was sufficient, and favour credentials that expire automatically. Most of what Truffle Security found would have been harmless long ago if it had ever been given a finite lifetime.


Read more »
Vulnerabilities and Exploits
API argo CD CVE GitHub repositories breach Kubernetes Vulnerabilities and Exploits

Researchers Warn of Unpatched Argo CD Flaw That Enables Cluster Takeover

 


Organizations using Argo CD to automate application deployments on Kubernetes are being urged to review their network configurations after security researchers disclosed an unpatched vulnerability that could allow attackers to execute arbitrary code on the platform's repo-server component and ultimately seize control of an entire Kubernetes cluster.

The vulnerability was identified by French cybersecurity firm Synacktiv, which says the issue affects the repo-server, a core Argo CD service responsible for retrieving application source code from Git repositories and converting it into Kubernetes manifests before workloads are deployed. Because the repo-server sits at the center of the GitOps deployment process, compromising it gives an attacker an opportunity to interfere with how applications are delivered throughout the cluster.

According to the researchers, exploitation does not require authentication. An attacker only needs network access to the repo-server's internal gRPC service, which accepts requests from other Argo CD components but does not verify the identity of the caller. Once that communication channel becomes reachable, a specially crafted request can be used to trigger remote code execution on the vulnerable service.

Synacktiv reported the vulnerability to the Argo CD maintainers in January 2025 through a responsible disclosure process. However, roughly eighteen months later, the issue remains unresolved, with no official security patch or CVE identifier assigned. The researchers chose to disclose their findings publicly to give administrators time to strengthen their deployments while awaiting a permanent fix.

At the center of the attack is Argo CD's repo-server, which continuously retrieves application definitions stored in Git repositories and prepares them for deployment by generating Kubernetes manifests. These manifests describe the desired state of applications, including containers, services, networking, storage, and other deployment configurations that Kubernetes uses to build and manage workloads. Since every deployment passes through this component, gaining control of the repo-server can provide attackers with extensive influence over the software being deployed inside a cluster.

The vulnerability stems from an unauthenticated internal gRPC interface exposed by the repo-server. gRPC is a high-performance communication framework commonly used for communication between services inside distributed applications. In Argo CD's design, the interface is intended for trusted internal communication. However, Synacktiv found that the service performs no authentication checks, allowing any system capable of reaching the port to submit requests that the repo-server will process.

The researchers demonstrated the attack against Argo CD version 2.13.3. They noted that no patched release currently exists and did not publish a complete list of affected versions, leaving administrators without a definitive inventory of vulnerable deployments.

To achieve code execution, the attack abuses Kustomize, a Kubernetes configuration management tool that Argo CD relies on to generate deployment manifests. Kustomize can also invoke Helm, another widely used package manager for Kubernetes, through the "--helm-command" option that specifies which executable should be launched.

Instead of directing Kustomize to the legitimate Helm binary, Synacktiv discovered that an attacker can send a malicious GenerateManifest request instructing it to execute a script stored inside an attacker-controlled Git repository. When Kustomize begins processing the deployment, it unknowingly launches the attacker's script in place of Helm, providing arbitrary code execution within the repo-server environment.

Although the vulnerable interface is intended to remain internal, the researchers warn that internal services should not automatically be considered secure. Kubernetes clusters frequently host dozens or even hundreds of interconnected workloads, and a compromise affecting a single pod can become the starting point for lateral movement if internal communication is not properly restricted.

Argo CD includes Kubernetes NetworkPolicy resources designed to limit access to sensitive services such as the repo-server and Redis. However, Synacktiv found that these protections are disabled by default when Argo CD is deployed using its Helm chart because the "networkPolicy.create" option is set to "false". As a result, installations that rely on the default configuration may unintentionally leave the repo-server reachable from other workloads running inside the cluster.

In such environments, compromising a single pod may be enough for an attacker to contact the repo-server and exploit the vulnerability.

The researchers also demonstrated that remote code execution represents only the beginning of the attack chain. After obtaining execution on the repo-server, they extracted the Redis password stored in an environment variable, authenticated to Argo CD's Redis instance, and modified cached deployment information. When Argo CD later performed its routine synchronization with the Git repository, the poisoned cache caused the platform to deploy an attacker-controlled workload instead of the intended application.

According to Synacktiv, this technique effectively revives a previously addressed weakness tracked as CVE-2024-31989. That earlier vulnerability, discovered by Cycode, exposed Argo CD deployments where Redis lacked password protection, allowing any pod inside the cluster to manipulate deployment cache data. Although Argo CD later introduced Redis password protection to address that issue, the cache contents themselves remain unsigned. By stealing the Redis credentials through the newly disclosed repo-server vulnerability, attackers can once again tamper with deployment data and recreate a similar compromise path.

With no software update currently available, researchers recommend treating network segmentation as the primary line of defense. Administrators should enable Kubernetes NetworkPolicy rules to ensure that only legitimate Argo CD components can communicate with the repo-server and Redis services. Organizations deploying Argo CD through Helm should verify that these policies have been explicitly enabled rather than relying on the chart's default configuration.

Administrators can inspect active network policies by running:

"kubectl get networkpolicy -A"

A properly secured deployment should display dedicated network policies protecting each Argo CD component, including both the repo-server and Redis. Missing policies may indicate that sensitive internal services remain accessible to other workloads inside the cluster.

To help organizations evaluate their exposure, Synacktiv developed a proof-of-concept tool named argo-cdown, capable of automating the complete attack chain. The researchers have postponed its public release to provide defenders with additional time to secure vulnerable environments. The tool is expected to be published on GitHub later, allowing administrators to validate the effectiveness of their own security controls.

The newly disclosed vulnerability is the latest in a series of security issues affecting Argo CD's privileged position within Kubernetes environments. In September 2025, the project patched CVE-2025-55190 after researchers found that an API token with only basic read permissions could retrieve Git repository credentials associated with a project. Several months later, in May 2026, another flaw tracked as CVE-2026-42880 enabled read-only users to access plaintext Kubernetes secrets.

Taken together, these incidents point to a recurring challenge rather than isolated implementation flaws. Argo CD occupies one of the most privileged positions within Kubernetes deployments, maintaining access to source repositories, deployment pipelines, cluster resources, and sensitive credentials. As a result, weaknesses affecting its internal services can quickly become pathways to broader infrastructure compromise.

Until an official patch becomes available, organizations should assume that internal cluster traffic cannot always be trusted. Restricting communication between workloads, enabling Kubernetes NetworkPolicy protections, and limiting access to critical Argo CD services remain the most effective measures for reducing exposure to this newly disclosed attack technique.

Read more »
Technology
AI AI prompt injection attack Copilot GitHub GitHub repositories breach Microsoft Technology

GitHub Fixes AI Flaw That Could Have Exposed Private Repository Tokens

 



A now-patched security weakness in GitHub Codespaces revealed how artificial intelligence tools embedded in developer environments can be manipulated to expose sensitive credentials. The issue, discovered by cloud security firm Orca Security and named RoguePilot, involved GitHub Copilot, the AI coding assistant integrated into Codespaces. The flaw was responsibly disclosed and later fixed by Microsoft, which owns GitHub.

According to researchers, the attack could begin with a malicious GitHub issue. An attacker could insert concealed instructions within the issue description, specifically crafted to influence Copilot rather than a human reader. When a developer launched a Codespace directly from that issue, Copilot automatically processed the issue text as contextual input. This created an opportunity for hidden instructions to silently control the AI agent operating within the development environment.

Security experts classify this method as indirect or passive prompt injection. In such attacks, harmful instructions are embedded inside content that a large language model later interprets. Because the model treats that content as legitimate context, it may generate unintended responses or perform actions aligned with the attacker’s objective.

Researchers also described RoguePilot as a form of AI-mediated supply chain attack. Instead of exploiting external software libraries, the attacker leverages the AI system integrated into the workflow. GitHub allows Codespaces to be launched from repositories, commits, pull requests, templates, and issues. The exposure occurred specifically when a Codespace was opened from an issue, since Copilot automatically received the issue description as part of its prompt.

The manipulation could be hidden using HTML comment tags, which are invisible in rendered content but still readable by automated systems. Within those hidden segments, an attacker could instruct Copilot to extract the repository’s GITHUB_TOKEN, a credential that provides elevated permissions. In one demonstrated scenario, Copilot could be influenced to check out a specially prepared pull request containing a symbolic link to an internal file. Through techniques such as referencing a remote JSON schema, the AI assistant could read that internal file and transmit the privileged token to an external server.

The RoguePilot disclosure comes amid broader concerns about AI model alignment. Separate research from Microsoft examined a reinforcement learning method called Group Relative Policy Optimization, or GRPO. While typically used to fine-tune large language models after deployment, researchers found it could also weaken safety safeguards, a process they labeled GRP-Obliteration. Notably, training on even a single mildly problematic prompt was enough to make multiple language models more permissive across harmful categories they had never explicitly encountered.

Additional findings stress upon side-channel risks tied to speculative decoding, an optimization technique that allows models to generate multiple candidate tokens simultaneously to improve speed. Researchers found this process could potentially reveal conversation topics or identify user queries with significant accuracy.

Further concerns were raised by AI security firm HiddenLayer, which documented a technique called ShadowLogic. When applied to agent-based systems, the concept evolves into Agentic ShadowLogic. This approach involves embedding backdoors at the computational graph level of a model, enabling silent modification of tool calls. An attacker could intercept and reroute requests through infrastructure under their control, monitor internal endpoints, and log data flows without disrupting normal user experience.

Meanwhile, Neural Trust demonstrated an image-based jailbreak method known as Semantic Chaining. This attack exploits limited reasoning depth in image-generation models by guiding them through a sequence of individually harmless edits that gradually produce restricted or offensive content. Because each step appears safe in isolation, safety systems may fail to detect the evolving harmful intent.

Researchers have also introduced the term Promptware to describe a new category of malicious inputs designed to function like malware. Instead of exploiting traditional code vulnerabilities, promptware manipulates large language models during inference to carry out stages of a cyberattack lifecycle, including reconnaissance, privilege escalation, persistence, command-and-control communication, lateral movement, and data exfiltration.

Collectively, these findings demonstrate that AI systems embedded in development platforms are becoming a new attack surface. As organizations increasingly rely on intelligent automation, safeguarding the interaction between user input, AI interpretation, and system permissions is critical to preventing misuse within trusted workflows.

Read more »
TruffleHog leak
Data Breach GitHub repositories breach NPM malware Shai-Hulud attack Supply Chain Attack TruffleHog leak

Shai-Hulud 2.0 Breach Exposes 400,000 Secrets After Massive NPM Supply-Chain Attack

 

The second wave of the Shai-Hulud malware attack last week led to the exposure of nearly 400,000 raw secrets after compromising hundreds of NPM (Node Package Manager) packages and leaking stolen data across more than 30,000 GitHub repositories.

While only around 10,000 of those secrets were confirmed as valid using the TruffleHog open-source scanning tool, cloud security company Wiz reports that over 60% of the NPM tokens leaked in this incident were still active as of December 1st.

Shai-Hulud first surfaced in mid-September, infecting 187 NPM packages with a worm-like payload. The malware scanned systems for account tokens using TruffleHog, injected a harmful script into the targeted packages, and then automatically republished them.
In the latest attack, the threat escalated—impacting more than 800 packages (including all affected versions) and adding a destructive feature capable of wiping a victim’s home directory under specific conditions.

During their review of the secrets spilled by Shai-Hulud 2.0 into over 30,000 GitHub repositories, Wiz researchers found several types of sensitive files exposed:

  • About 70% of repositories contained a contents.json file with GitHub usernames, tokens, and file snapshots

  • Around 50% stored truffleSecrets.json with TruffleHog scan results

  • Nearly 80% included environment.json, which revealed OS details, CI/CD metadata, npm package information, and GitHub credentials

  • 400 repositories had actionsSecrets.json, exposing GitHub Actions workflow secrets

Wiz notes that the malware used TruffleHog without the --only-verified flag, meaning the full set of 400,000 leaked secrets only matched valid formats—they weren’t necessarily functional. Even so, the dataset still contained active credentials.

“While the secret data is extremely noisy and requires heavy deduplication efforts, it still contains hundreds of valid secrets, including cloud, NPM tokens, and VCS credentials,” Wiz explained.

“To date, these credentials pose an active risk of further supply chain attacks. For example, we observe that over 60% of leaked NPM tokens are still valid.”

From the 24,000 environment.json files analyzed, nearly half were unique. About 23% originated from developer machines, with the remainder linked to CI/CD systems or similar automated environments.

The investigation also showed that 87% of compromised machines were running Linux, and 76% of infections occurred within containerized environments. Among CI/CD services, GitHub Actions was the most affected, followed by Jenkins, GitLab CI, and AWS CodeBuild.

When examining which packages were hit hardest, Wiz identified @postman/tunnel-agent@0.6.7 and @asyncapi/specs@6.8.3 as the most impacted—together accounting for over 60% of all infections. Researchers believe the overall damage could have been significantly reduced if these key packages had been flagged and taken down early.

The infection pattern also revealed that 99% of attacks triggered during the preinstall event, specifically through the node setup_bun.js script. The few anomalies observed were likely test runs.

Wiz warns that the operators behind Shai-Hulud are likely to continue refining their methods. The team expects more waves of supply-chain attacks powered by the extensive trove of leaked credentials gathered so far.

Read more »
Subscribe to: Posts (Atom)