Security vulnerabilities and automated fixes for credential exposure issues
9 posts found
A critical vulnerability was discovered in the Bitbucket catalog connector where pagination URLs from API responses were followed without HTTPS validation, potentially exposing HTTP Basic Authentication credentials over unencrypted connections. The fix enforces HTTPS-only URLs for pagination and adds request timeouts to prevent resource exhaustion attacks.
A critical vulnerability in `utils/common.js` allowed API keys to be transmitted over unencrypted HTTP connections to remote servers, exposing them to network interception. The `buildModelApiRequest` function at line 490 constructed API requests without validating the transport protocol, enabling man-in-the-middle attacks. The fix enforces HTTPS for all remote API endpoints while preserving HTTP access for local development servers on loopback addresses.
A critical vulnerability in `layout/_plugins/global/config.ejs` was exposing Algolia API credentials — including `appId` and `apiKey` — directly in rendered HTML, making them visible to any user who inspects the page source. The fix removes raw credential interpolation from the template and replaces unsafe string embedding with properly sanitized output using `JSON.stringify()`. This eliminates the risk of unauthorized Algolia API access by anyone who visits the page.
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 critical security vulnerability was discovered in all.html where a Yandex Maps API key was embedded directly in client-side HTML at line 68. This pattern exposed API credentials to anyone viewing the page source, enabling unlimited unauthorized API requests. The fix removed the API key from the client-side code, demonstrating proper API key management for JavaScript applications.
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.