T09 · Insecure Skill Coding Practices
- Location
scripts/connect.js:7- Finding
Hardcoded Shared Authentication Token Enables Unauthorized Playground Access and Identity Impersonation
- Content
View full analysis
Vulnerability Details
File Location:
scripts/connect.js:7-8andscripts/connect.js:132-139; the same credential is disclosed inSKILL.md:15-18andREADME.md:70-74
Vulnerability Type: Hardcoded shared credential and insufficient identity binding
Risk Level: MediumVulnerable Code
javascript // Configuration const PLAYGROUND_URL = process.env.PLAYGROUND_URL || 'wss://playground-bots.fly.dev/bot'; const PLAYGROUND_TOKEN = process.env.PLAYGROUND_TOKEN || 'playground-beta-2026';The credential is subsequently transmitted during authentication:
javascript ws.on('open', () => { // Authenticate ws.send(JSON.stringify({ type: 'auth', token: PLAYGROUND_TOKEN, agent })); });The same credential is explicitly published in the documentation:
markdown - **WebSocket**: `wss://playground-bots.fly.dev/bot` - **Token**: `playground-beta-2026` - **Dashboard**: https://playground-bots.fly.dev (humans watch here)Technical Analysis
The client embeds a reusable Playground authentication token as a fallback value and publishes it in the project documentation. Consequently, possession of the project is sufficient to recover the credential without accessing a protected secret store.
Authentication also includes an
agentobject whosename,ownerId, anddescriptionvalues are supplied through command-line arguments or environment variables. The reviewed client does not provide cryptographic proof that these identity claims belong to the authenticated user. If the server relies only on the shared token, an attacker can authenticate using arbitrary identity metadata.The default endpoint uses WSS, which protects the credential in transit under normal operation. However, transport encryption does not mitigate public disclosure of the credential. In addition,
PLAYGROUND_URLis environment-overridable, so an untrusted runtime configuration could redirect the client to an attacker-controlled WebSocket en ...[truncated 2021 chars]- Remediation
View remediation
Remediation Suggestions
- Remove the hardcoded fallback token from
scripts/connect.jsand require credentials to be supplied through a protected secret-management mechanism:
javascript const PLAYGROUND_TOKEN = process.env.PLAYGROUND_TOKEN; if (!PLAYGROUND_TOKEN) { console.error('PLAYGROUND_TOKEN is required.'); process.exit(1); }-
Remove the live token from
SKILL.mdandREADME.md. Replace it with setup instructions and a nonfunctional placeholder such asYOUR_PLAYGROUND_TOKEN. -
Immediately rotate and revoke the exposed shared token because it must be treated as compromised after publication.
-
Issue unique, revocable credentials for each owner or agent. Prefer short-lived tokens with narrowly scoped permissions rather than a single global beta credential.
-
Bind each credential to a server-validated owner and agent identity. The server should derive identity from authenticated claims or verify signed identity data instead of trusting arbitrary client-provided
nameandownerIdvalues. -
Add expiration, audience, issuer, and scope validation on the server. Implement rate limits, abuse monitoring, and credential-specific audit logging.
-
Restrict
PLAYGROUND_URLto an approved WSS origin or require explicit user confirmation before connecting to a nonstandard endpoint. Never send a production credential to an untrusted or plaintext endpoint. -
Avoid logging authentication tokens and ensure deployment environments protect
PLAYGROUND_TOKENfrom unauthorized process, shell-history, and configuration-file access.
- Remove the hardcoded fallback token from