Security vulnerabilities and automated fixes for secrets management issues
9 posts found
A critical vulnerability was discovered in `ghs/91Pornad.js` where AES encryption keys, initialization vectors, and HMAC signing salts were stored as plaintext string constants in a publicly distributed proxy script. Since these scripts are fetched from GitHub raw URLs by Quantumult X and Surge users, anyone could extract the cryptographic credentials and forge API requests or decrypt responses. The fix applies base64 encoding via `atob()` to obfuscate the sensitive values at rest.
A GitHub Actions workflow in Node.js was storing authentication tokens in plain variables without masking them in logs, creating a critical security risk. When debug mode was enabled or errors occurred, tokens could be exposed in console output and GitHub Actions logs. The fix uses the `setSecret()` API to automatically mask sensitive credentials throughout the execution.
A critical hardcoded API key for ipregistry.co was discovered embedded as a fallback value in `src/utils.js` at line 65 of a Node.js library. This key (`f8n4kqe8pv4kii`) was visible to anyone inspecting the JavaScript bundle, allowing unauthorized use of the service. The fix removes the hardcoded fallback, requiring callers to explicitly provide their own API key.
A critical security vulnerability was discovered in `js/douban.js` where the Douban API key (`0ac44ae016490db2204ce0a042db2916`) was hardcoded directly in client-side JavaScript. This exposed the API credential to any user who could view the page source or use browser developer tools. The fix removed the hardcoded key, preventing unauthorized API access and potential abuse.
A high-severity security finding was identified in `templates/claude-workflow/workflows/claude.yml` where `secrets: inherit` passed every repository secret to a reusable workflow, violating the principle of least privilege. The fix explicitly passes only `CLAUDE_CODE_OAUTH_TOKEN`—the single secret the called workflow actually needs—drastically reducing the blast radius if the reusable workflow is ever compromised.
A hardcoded AWS Access Key ID (`AKIAVCODYLSA53PQK4ZA`) was discovered embedded in a signed S3 URL within the `CVE-2024-51482.yaml` nuclei template file. This credential, while part of a pre-signed URL reference link, was flagged as a high-severity finding because it exposes a real AWS access key in a public repository. The fix removes the entire reference URL containing the embedded credential.
A critical security vulnerability was discovered and patched in the nullclaw-init script, where API keys were hardcoded directly into the source code at multiple locations. This type of exposure means anyone with read access to the repository or installed files can silently extract and abuse credentials without any technical hacking required. The fix eliminates this risk by removing hardcoded secrets in favor of secure credential management practices.
A critical vulnerability in an application using @octokit packages left GitHub API tokens vulnerable to exposure through hardcoding, version control commits, and insecure configuration management. This security flaw could allow attackers to gain unauthorized access to GitHub repositories and organizational resources. Learn how proper secrets management prevents token leakage and protects your GitHub integrations.
A medium-severity security vulnerability was discovered where a Google OAuth access token was inadvertently exposed in documentation files. This incident highlights the critical importance of secrets management and demonstrates how even non-code files can become vectors for credential leakage, potentially granting unauthorized access to Google APIs and user data.