CyberSecurity SEE

Claude Code’s Don’t Ask Again Feature Reveals 2,539 Secrets in 1,994 GitHub Repositories

Claude Code’s Don’t Ask Again Feature Reveals 2,539 Secrets in 1,994 GitHub Repositories

Investigation Reveals Major Security Risks on GitHub: Over 2,500 Secrets Exposed

Recent findings have shed light on a staggering security vulnerability affecting a vast number of public GitHub repositories. Researchers have identified 2,539 distinct secrets across 1,994 repositories that have been exposed, primarily due to coding-agent configuration files, Git history, and saved transcripts. This alarming revelation poses significant risks to the security of numerous organizations.

The research conducted on November 5 highlighted a particularly concerning feature of Claude Code, which utilizes a mechanism dubbed “Yes, and don’t ask again” for its approval workflow. This feature has the inherent flaw of allowing credential-bearing shell commands to persist within the file designated as .claude/settings.local.json. As a result, sensitive information, including production database passwords, API tokens, cloud credentials, and SSH logins, has been compromised, impacting at least 63 organizations. Notably, one organization confirmed that its exposed key had been live, potentially leading to severe consequences.

Mechanism of Exposure

The exposure of these secrets often starts when Claude Code proposes a command that integrates credentials extracted from configuration files. This command, once approved by the user, does not rid itself of sensitive arguments but rather stores them as an “allowlist” rule. Such a method of persistent command execution not only leaves developers vulnerable but also creates a false sense of security, as the settings file is added to a global Git ignore list when created; however, this measure fails to accompany the project across forks.

Further compounding the issue is the already existing threat posed by infostealer malware, which specifically targets authentication artifacts within Claude Code. The security analysis conducted by Apiiro noted that out of 104,185 public copies of .claude/settings.local.json inspected across 103,617 repositories, 1,122 files contained 1,379 distinct secrets. Among these were 636 provider-format keys and 743 passwords or tokens that were associated with public hosts. Database access threats were particularly pronounced, with the discovery of 379 database passwords and 122 Supabase service-role keys, not to mention an alarming 103 Supabase account tokens.

The Depth of the Problem

Researchers found the consequences of this vulnerability extend well beyond files presently on GitHub. Historical analysis revealed that previous versions contained an additional 734 secrets that are currently absent. In addition, shared .claude/settings.json files and agent transcripts contributed to an increase in the overall count of exposed secrets. Forked repositories further proliferated the credentials by reproducing them from 74 original repositories into an additional 211 copies.

This proliferation of sensitive information has sparked concerns about potential credential-harvesting supply-chain attacks. Such vulnerabilities can be exploited through malicious packages that monitor developer environments, as evidenced by recent instances involving Nx packages that scanned for vulnerabilities in locally installed AI tools.

Detection Gaps and Challenges

Detection methodologies are also falling short. Security tools such as Gitleaks flagged just 564 secret-bearing files and TruffleHog identified 643, with 215 files escaping detection entirely. Common secrets such as passwords following PGPASSWORD=, sshpass -p, or mysql -p frequently lacked identifiable provider prefixes, contributing to the blurred lines in their detection. According to Apiiro, this highlights the need for a distinction between structured API-key detection and nuanced command-line credential analysis.

Furthermore, teams need to prioritize the rotation of exposed credentials before embarking on cleanup efforts. They should untrack the .claude/settings.local.json file and establish new local ignore rules within their repositories. Inspecting historical commits and shared settings, as well as conducting a thorough review of transcripts, will also be critical steps in mitigating risks. Developers are encouraged to replace hardcoded secrets with secret-manager-backed environment-variable references.

Incorporating pre-commit and continuous integration (CI) scanning into workflow processes should be a strategic priority, aiming to detect any exposed passwords within command-line instructions. Although Apiiro has not conducted tests on credential validity, their classification of "real secrets" provides credible indicators of potential security threats.

As the digital landscape continues to evolve, organizations relying on GitHub should heighten their security measures to ensure that such vulnerabilities are effectively addressed, safeguarding their sensitive information from unnecessary exposure.

Source link

Exit mobile version