T09 · Insecure Skill Coding Practices
Error
- Location
- lib/wallet.ts:27
- Finding
- Hard-Coded Shared Oracle API Key<![CDATA[ ## Vulnerability Details **File Location**: `lib/wallet.ts:27-30` **Vulnerability Type**: Hard-coded credential **Risk Level**: High ### Vulnerable Code ```ts oracle: { trustBasePath, apiKey: process.env.UNICITY_API_KEY ?? 'sk_06365a9c44654841a366068bcfc68986', }, ``` ### Technical Analysis The Skill embeds a live-looking API key directly in its source code and automatically uses it whenever the `UNICITY_API_KEY` environment variable is absent. A credential distributed with the Skill cannot be considered secret. Anyone with access to the package, source repository, installation cache, or audit artifact can extract and reuse it independently of the Skill. The fallback also causes all users without an explicit API key to share the same credential, preventing reliable attribution and per-user revocation. The key is supplied to the Sphere SDK's oracle provider. The exact server-side permissions and billing scope of the credential cannot be determined from the audited files, but exposing it violates secure secret-management principles regardless of its current scope. ### Attack Path 1. An attacker downloads or otherwise accesses the Skill source. 2. The attacker opens `lib/wallet.ts` and extracts the embedded `sk_...` credential. 3. The attacker identifies the associated oracle service through the Sphere SDK or observes legitimate SDK requests. 4. The attacker submits requests directly using the exposed credential. 5. Requests are attributed to the shared key until the service revokes it or applies another control. No local access to the victim's wallet is required for this attack. ### Impact Assessment Depending on the credential's server-side permissions, exploitation may permit: - Unauthorized use of the oracle service. - Consumption of shared quotas or rate limits. - Charges against the credential owner if the service is billable. - Service disruption for legitimate users after quota exhaustion. - Loss of attribution because multiple i ...[truncated 348 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Immediately revoke and rotate the exposed API key. 2. Remove the fallback credential from the source code and repository history. 3. Require `UNICITY_API_KEY` to be supplied explicitly: ```ts const apiKey = process.env.UNICITY_API_KEY; if (!apiKey) { throw new Error('UNICITY_API_KEY is required'); } ``` 4. Store credentials in the platform's secret-management facility rather than source files, command-line arguments, or plaintext configuration committed with the Skill. 5. Issue separate, narrowly scoped credentials for each user or installation. 6. Apply server-side rate limits, usage alerts, expiration, and origin or account restrictions where supported. 7. Review service logs for unauthorized use of the exposed key. 8. Add secret scanning to CI and pre-commit checks to prevent recurrence. ]]>