T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:9- Finding
Excessive API Credential Requirements Violate Least Privilege
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 9-11 and 191-197
Vulnerability Type: Excessive credential exposure and privilege scope
Risk Level: MediumVulnerable Code
json "requires": { "env": ["MAILCHIMP_API_KEY", "CONVERTKIT_API_KEY", "ACTIVECAMPAIGN_API_KEY", "SENDGRID_API_KEY"], "bins": ["curl", "jq"] }bash # Email Service Provider APIs (choose at least one) export MAILCHIMP_API_KEY="your_mailchimp_api_key_here" export CONVERTKIT_API_KEY="your_convertkit_api_key_here" export ACTIVECAMPAIGN_API_KEY="your_activecampaign_api_key_here" export ACTIVECAMPAIGN_URL="https://youraccount.api-us1.com" export SENDGRID_API_KEY="your_sendgrid_api_key_here"Technical Analysis
The skill metadata declares API keys for four independent email providers as required environment variables, while the configuration instructions state that the user only needs to choose at least one provider. This inconsistency encourages or requires the runtime to receive credentials unrelated to the selected operation.
API credentials for email marketing platforms can authorize sensitive operations such as reading subscriber information, modifying audience lists, creating campaigns, and sending email. Supplying every provider credential to one skill runtime violates the principle of least privilege and unnecessarily expands the credential exposure surface.
The repository contains no executable implementation, so direct credential theft or misuse by this skill was not demonstrated. Exploitation would require another compromised or untrusted component to gain access to the same process environment.
Attack Path
- A user follows the metadata requirements and configures credentials for all four supported providers.
- The skill runtime exposes those credentials as environment variables, even though a requested task uses only one provider.
- A compromised co-located skill, runtime compon ...[truncated 1059 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the aggregate requirement for all provider API keys from the skill metadata.
- Require only the credential for the provider explicitly selected by the user.
- Implement provider-specific configuration profiles so credentials are injected on demand rather than globally.
- Use narrowly scoped API tokens that authorize only the operations necessary for the requested workflow.
- Keep credentials in an approved secret manager and inject them only into the process performing the relevant API request.
- Prevent secrets from appearing in generated output, command histories, logs, diagnostics, or error messages.
- Document token rotation and immediate revocation procedures.
- Validate the selected provider before requesting credentials and reject ambiguous workflows rather than loading every available key.