T09 · Insecure Skill Coding Practices
- Location
tests/pre-submit-check.sh:16- Finding
Hardcoded Credentials Embedded in Pre-Submission Scanner
- Content
View full analysis
Vulnerability Details
File Location:
tests/pre-submit-check.sh, lines 16–17
Vulnerability Type: Hardcoded credentials
Risk Level: HighVulnerable Code
bash real_keys=$(grep -r "cli_a9f1c3a7c\|diLMNYl2nzbL1nEtQNhjMeQp6rtQdzA7\|DHqybLBGCaINAWscdLkcGDGwn9g\|tbldoED8qoLnkpZC" "$skill_dir" 2>/dev/null | grep -v "Binary file")Technical Analysis
The pre-submission scanner embeds four literal values that the surrounding script identifies as “real keys.” Although they are used as search patterns intended to detect accidental credential inclusion elsewhere, placing the complete values in the scanner itself discloses them in every copy of the Skill.
No attacker-controlled input is required. Anyone able to download, clone, inspect, or receive the project can extract the values from the shell script. The use of these values as
greppatterns does not protect or transform them. Static analysis cannot establish whether they remain active, but their disclosure is concrete regardless of current validity.Attack Path
- An unauthorized party obtains a distributed copy of the Skill or accesses its repository.
- The party reads
tests/pre-submit-check.sh. - The party extracts the literal credential values from the
grepexpression. - If one or more credentials remain valid, the party submits them to their corresponding service.
- The party gains whatever access the affected credentials authorize.
This path crosses the boundary between secrets intended for their owner or associated services and all recipients of the distributable Skill package.
Impact Assessment
If valid, the exposed credentials could allow unauthorized access to associated service accounts, APIs, or data. The exact privileges and affected services cannot be determined from the audited files. Potential scope is bounded by the permissions assigned to each credential and may include account impersonation, data access or mod ...[truncated 234 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate every embedded value immediately; do not rely solely on deleting the source text.
- Remove the literal values from the current file and all repository history, release archives, caches, and published Skill packages.
- Replace exact-secret matching with non-sensitive detection methods, such as credential-format patterns, provider-specific prefixes, entropy checks, or hashes that cannot be directly reused for authentication.
- For regression tests, use unmistakably synthetic fixtures that cannot authenticate to any service.
- Store any necessary private detection indicators outside the repository in a protected secret store and inject them only into trusted CI jobs.
- Add automated secret scanning before commits and releases, ensuring that the scanner does not itself contain production credentials.
- Review access and audit logs for the affected services to identify unauthorized use since the values were first committed.