T09 · Insecure Skill Coding Practices
- Location
SKILL.md:76- Finding
Predictable Hardcoded Credentials in Bot Registration Example
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 76–82
Vulnerability Type: Hardcoded weak credentials
Risk Level: MediumVulnerable Code
bash curl -X POST "https://neuropay.fr/api/register-bot/" \ -H "Content-Type: application/json" \ -d '{ "username": "test123", "password": "test123" }'Technical Analysis
The directly executable bot-registration example uses the public and predictable value
test123for both the username and password. This conflicts with the bootstrap instructions at lines 59–61, which require a random username and a cryptographically secure random password.Agents or users may execute examples literally. If the registration endpoint accepts these credentials, the resulting account would be protected by a password disclosed in the public Skill documentation. An attacker would not need to derive or steal the password; they could reproduce it directly from the file.
Although the API key is intended to remain in session memory, weak account credentials may provide a separate account-takeover route if NeuroPay supports credential-based login or account recovery. The precise server-side access available after login cannot be established from the audited files.
Attack Path
- A user or agent copies and executes the documented registration command.
- NeuroPay registers a bot account using
test123as its password. - An attacker identifies or guesses the documented username and submits the publicly known password to any applicable NeuroPay authentication interface.
- If credential-based authentication is available and no compensating control blocks access, the attacker takes control of the bot account.
- The attacker may perform actions permitted to that account, potentially including marketplace, order, review, profile, or file operations.
Impact Assessment
Successful exploitation could result in unauthorized access to the affected bot accou ...[truncated 351 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove all usable literal credentials from the registration example.
- Generate usernames and passwords at runtime with a cryptographically secure random-number generator.
- Require sufficient password entropy, such as at least 128 bits of random data.
- Use placeholders that cannot be mistaken for valid credentials, and explicitly state that static example values must never be submitted.
- Keep the generated password and returned API key only in protected runtime memory and redact them from logs, errors, and command histories.
- If password-based login is unnecessary after API-key issuance, disable it or rotate and securely escrow the credential according to the service's account lifecycle requirements.
- Add validation that rejects known sample passwords such as
test123.
A safer conceptual example is:
python import secrets username = "bot_" + secrets.token_urlsafe(12) password = secrets.token_urlsafe(32)The generated values should then be sent through an API client without printing or persisting them.