T09 · Insecure Skill Coding Practices
- Location
index.js:97- Finding
Credentials Exposed Through Command-Line Arguments and Standard Output
- Content
View full analysis
Vulnerability Details
File Location:
index.js, lines 97, 118, 134, 145–146, and 158
Vulnerability Type: Plaintext credential exposure
Risk Level: HighVulnerable Code
js const password = args.password || DEFAULT_PASSWORD;js return { username, password, content, name, targetDate, weekInfo, dayOfWeek, dayName, steps: [ { action: 'open', url: BASE_URL }, { action: 'wait', ms: 2000 } ] };js const args = process.argv.slice(2);js } else if (args[i] === '--password' || args[i] === '-p') { params.password = args[i + 1]; i++; }js executeDailyReport(params).then(result => { console.log(JSON.stringify(result, null, 2)); }).catch(err => { console.error('Error:', err.message); process.exit(1); });Technical Analysis
The script accepts the iHub password through a command-line option and retains it in the object returned by
executeDailyReport. The entire object is subsequently serialized to standard output without redaction.Command-line secrets can be exposed through shell history, process inspection facilities, diagnostic tooling, and process-monitoring systems. Printing the returned object creates an additional disclosure channel through terminal scrollback, redirected output, CI/CD logs, orchestration logs, and centralized log collectors.
Because the returned object contains the original plaintext password, callers that log or otherwise persist the result may also disclose the credential even when the CLI entry point is not used.
Attack Path
- A user runs the script with a password, such as
node index.js --username USER --password SECRET. - The plaintext password is stored in the process argument vector and may be recorded in shell history or observed through local process-monitoring mechanisms.
- The argument parser assigns the plaintext value to `params. ...[truncated 1087 chars]
- A user runs the script with a password, such as
- Remediation
View remediation
Remediation Suggestions
-
Remove support for supplying passwords through command-line arguments. Read the password from a protected secret manager, a narrowly scoped environment mechanism where appropriate, or an interactive hidden-input prompt.
-
Never include passwords in returned execution metadata. Keep the credential in the smallest possible scope and discard the reference immediately after authentication.
-
Redact all sensitive fields before logging or serializing objects. Prefer an explicit allowlist of safe output properties rather than attempting to remove known secret fields afterward.
-
Change the returned object to omit
password, for example:js return { username, content, name, targetDate, weekInfo, dayOfWeek, dayName, steps: [ { action: 'open', url: BASE_URL }, { action: 'wait', ms: 2000 } ] }; -
Ensure diagnostic and error paths do not serialize argument objects, authentication request data, headers, cookies, tokens, or credentials.
-
Review existing shell histories, CI/CD output, terminal captures, and centralized logs for previously exposed credentials. Remove accessible copies where feasible and rotate any password that may have been logged.
-
Add automated tests that fail if result objects or log output contain fields named
password,token,secret, or equivalent sensitive values.
-