Security vulnerabilities and automated fixes for credential exposure issues
4 posts found
A critical credential exposure vulnerability was discovered in `cli/src/utils/github.ts`, where three GitHub API fetch calls were made without any safe token-loading mechanism, risking accidental hardcoding or token leakage in logs and CI/CD pipelines. The fix introduces a centralized `getAuthHeaders()` function that reads the token exclusively from the `GITHUB_TOKEN` environment variable and safely injects it into all outbound API requests. This ensures credentials never touch source code, buil
A medium-severity vulnerability in `tools/cli/aroma.py` allowed keystore passwords entered via the `get_input()` function to be displayed in plaintext on the terminal, stored unmasked in memory, and potentially recorded in shell history files. The fix introduces Python's `getpass` module and a new `secret` parameter to `get_input()`, ensuring sensitive credential input is properly masked during entry. This change directly protects users of the CLI tool from credential exposure during routine key
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 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.