ClawHub
Back to skill

Security audit

Astock Daily

Security checks for vulnerabilities and agentic risk

Overview

This stock-report email skill has a coherent purpose, but it needs review because it mishandles mail credentials and can make persistent system and scheduler changes.

Do not install this as-is for a real mailbox. Before use, remove the hard-coded recipient and test credential, rotate any exposed SMTP password, store mail secrets in a protected secret manager or tightly permissioned config file, stop logging credential-bearing configuration, keep TLS certificate validation enabled, avoid the sudo hosts-file helper, and review any cron or shell-profile persistence before enabling it.

A.I.G

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (10)

T09 · Insecure Skill Coding Practices

Error
Location
test-smtp.js:36
Finding
Hard-Coded SMTP Account Credential<![CDATA[ ## Vulnerability Details **File Location**: `test-smtp.js:36-37` **Vulnerability Type**: Hard-coded secret **Risk Level**: Critical ### Vulnerable Code ```javascript const user = '8@batype.com'; const pass = '960515@ss.com'; ``` ### Technical Analysis A plaintext SMTP username and password are embedded directly in an executable test script. Anyone able to obtain the project files, repository history, packaged Skill, backup, or build artifact can recover the credential without executing the code. The script actively supplies this credential to Nodemailer, so it is not merely example text. If the credential remains valid, it can potentially be used outside the Skill. ### Attack Path 1. An attacker obtains a copy of the project or reads `test-smtp.js`. 2. The attacker extracts the hard-coded username and password. 3. The attacker connects to the associated SMTP service. 4. If authentication succeeds, the attacker sends email as the account, distributes spam or phishing messages, or attempts related account access. 5. Abuse continues until the credential is revoked or rotated. ### Impact Assessment A successful attacker may gain authenticated access to the SMTP account and the ability to send messages under the account's identity. This can cause impersonation, phishing, reputation damage, provider suspension, and disclosure of any information exposed through the SMTP account. Because the credential has already been committed into project content, deleting only the current line is insufficient if repository history or previously distributed artifacts remain accessible. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Immediately revoke and rotate the exposed credential. 2. Review SMTP account activity for unauthorized authentication and sent messages. 3. Remove the secret from the current files and all repository history. 4. Invalidate previously published packages or artifacts containing the credential. 5. Load credentials from an operating-system secret manager or protected runtime environment. 6. Use a dedicated, least-privilege test account rather than a production mailbox. 7. Add automated secret scanning to CI and pre-commit checks. 8. Ensure test fixtures contain only clearly invalid placeholder values. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
index.js:269
Finding
SMTP Password Disclosure Through Console and Cron Logs<![CDATA[ ## Vulnerability Details **File Location**: `index.js:269-279`; related output in `config.js:94-98` **Vulnerability Type**: Sensitive information exposure **Risk Level**: High ### Vulnerable Code ```javascript const config = JSON.parse(smtpConfig); console.log({ host: config.host, port: parseInt(config.port) || 587, secure: config.secure || false, auth: { user: config.user, pass: config.pass, }, }); ``` The configuration utility also prints the complete credential-bearing object: ```javascript console.log(` export SMTP_CONFIG='${JSON.stringify(smtpConfig)}'`); console.log(` export SMTP_CONFIG='${JSON.stringify(smtpConfig)}'`); ``` ### Technical Analysis The main program logs the complete SMTP authentication object, including the password. The configuration utility independently prints the serialized SMTP configuration containing the same secret. Scheduled execution redirects program output to `/tmp/astock-daily.log`, making the credential available through a persistent log rather than only an interactive terminal. Secrets may also be captured by CI systems, terminal recording, OpenClaw session logs, monitoring agents, or support bundles. ### Attack Path 1. A user configures `SMTP_CONFIG` with a valid password. 2. The user or scheduled task runs `index.js`, or the user runs `config.js`. 3. The password is written to terminal output, session history, or the cron log. 4. A local user, monitoring process, backup system, or person with access to captured output reads the credential. 5. The exposed credential is reused against the SMTP provider. ### Impact Assessment An attacker obtaining the logged password may authenticate to the SMTP service and impersonate the configured account. Exposure can extend beyond the local host when logs are collected centrally or included in diagnostic archives. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove all logging of `config.pass`, authentication objects, and serialized SMTP configuration. 2. Log only non-sensitive fields such as host, port, and TLS mode. 3. Introduce a central redaction function that replaces passwords, tokens, and authorization values with a fixed marker. 4. Delete existing logs that may contain credentials and rotate affected passwords. 5. Create cron logs in a private application directory with restrictive permissions rather than a predictable shared `/tmp` path. 6. Prevent configuration utilities from printing commands containing secrets. 7. Review OpenClaw, CI, and centralized logging systems for previously captured copies. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
index.js:276
Finding
SMTP Certificate Validation Is Disabled<![CDATA[ ## Vulnerability Details **File Location**: `index.js:276-278`; repeated in `test-smtp.js:9-21` **Vulnerability Type**: Improper certificate validation **Risk Level**: High ### Vulnerable Code ```javascript const tlsConfig = config.tls || (config.secure ? { rejectUnauthorized: false } : undefined); ``` The SMTP test configurations repeat the unsafe setting: ```javascript { name: 'Port 465', host: 'smtp.mxhichina.com', port: 465, secure: true, tls: { rejectUnauthorized: false }, }, { name: 'Port 587', host: 'smtp.mxhichina.com', port: 587, secure: false, requireTLS: true, tls: { rejectUnauthorized: false }, }, ``` ### Technical Analysis Setting `rejectUnauthorized` to `false` tells the TLS client to accept certificates that cannot be validated against trusted certificate authorities or that do not correctly authenticate the intended server. Encryption without server authentication does not prevent an active man-in-the-middle attack. This weakness is especially dangerous because another project script permanently overrides SMTP hostname resolution. The SMTP test also contains a port 25 configuration without enforced transport encryption, further weakening credential and message confidentiality when that configuration is selected. ### Attack Path 1. An attacker gains a network interception position or influences DNS resolution. 2. The attacker redirects the SMTP connection to an attacker-controlled endpoint. 3. The endpoint presents an arbitrary or self-signed certificate. 4. The Skill accepts the certificate because validation is disabled. 5. The client supplies SMTP authentication data and email contents to the fraudulent endpoint. ### Impact Assessment An attacker can capture SMTP usernames, passwords, recipients, subjects, and message bodies. The attacker may also modify outgoing content or impersonate the SMTP service. No elevated local privilege is required if the attacker can control the network or DNS path. ...[truncated 3 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove every use of `rejectUnauthorized: false`. 2. Use the platform trust store and fail closed when certificate validation fails. 3. Set `servername` correctly if connecting through a controlled address override. 4. Require TLS for authenticated SMTP and remove the unencrypted port 25 test. 5. Do not treat certificate errors as DNS troubleshooting issues to bypass. 6. Add automated tests confirming that self-signed, expired, and hostname-mismatched certificates are rejected. 7. Rotate SMTP credentials after correcting the transport because prior sessions may have been intercepted. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error
Location
fix-hosts.sh:8
Finding
Root-Level Persistent SMTP DNS Overrides<![CDATA[ ## Vulnerability Details **File Location**: `fix-hosts.sh:8-21` **Vulnerability Type**: Excessive privilege and persistent system-wide network modification **Risk Level**: High ### Vulnerable Code ```bash if grep -q "smtp.qiye.aliyun.com" /etc/hosts 2>/dev/null; then echo "Entry already exists" else sudo sh -c 'echo "47.246.165.89 smtp.qiye.aliyun.com" >> /etc/hosts' fi if grep -q "smtp.mxhichina.com" /etc/hosts 2>/dev/null; then echo "Entry already exists" else sudo sh -c 'echo "47.246.165.89 smtp.mxhichina.com" >> /etc/hosts' fi ``` ### Technical Analysis The helper requests root privileges and permanently changes system-wide hostname resolution by appending fixed SMTP mappings to `/etc/hosts`. It does not cryptographically verify that the hard-coded IP is currently operated by the expected provider, preserve the previous state, establish an expiry, or provide an automated rollback. Modifying `/etc/hosts` is not required for the Skill's core stock-reporting function. The change affects every process on the host, not only this application. Combined with disabled TLS certificate verification, it creates a direct path for SMTP credential interception if the address is incorrect, reassigned, or compromised. ### Attack Path 1. A user runs `fix-hosts.sh` and grants `sudo` access. 2. The script permanently maps both SMTP domains to the fixed address. 3. The address later becomes incorrect, is reassigned, or does not belong to the intended SMTP endpoint. 4. The Skill connects to the fixed endpoint instead of using authenticated DNS resolution. 5. Because certificate validation is disabled, a fraudulent endpoint can receive SMTP authentication data. ### Impact Assessment The script obtains root-authorized write access to a security-sensitive system file and changes network behavior for all users and applications. Potential consequences include credential interception, email disruption, persistent traffic redirection, and difficult- ...[truncated 39 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the privileged DNS modification helper from the normal Skill workflow. 2. Correct the proxy or DNS configuration at its source rather than overriding `/etc/hosts`. 3. Preserve strict TLS certificate and hostname validation regardless of DNS configuration. 4. If an override is operationally unavoidable: - Verify address ownership through an authenticated provider source. - Back up the existing file. - Add uniquely marked entries. - Provide an idempotent removal command. - Require explicit confirmation before modification. - Revalidate and expire the mapping automatically. 5. Document all system-wide effects before requesting elevated privileges. 6. Remove existing overrides from affected hosts after validating normal DNS behavior. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
send-mail-applescript.js:17
Finding
Shell and AppleScript Injection in Alternate Mail Sender<![CDATA[ ## Vulnerability Details **File Location**: `send-mail-applescript.js:17-32` **Vulnerability Type**: Command injection **Risk Level**: High ### Vulnerable Code ```javascript const tempFile = path.join(__dirname, 'email-temp.html'); fs.writeFileSync(tempFile, htmlContent); const script = ` tell application "Mail" set newMessage to make new outgoing message with properties {subject:"${subject}", content:"${htmlContent.replace(/"/g, '"')}", visible:true} tell newMessage make new to recipient at end of to recipients with properties {address:"${to}"} end tell send newMessage end tell `.replace(/\n/g, ' '); return new Promise((resolve, reject) => { exec(`osascript -e '${script}'`, (error) => { fs.unlinkSync(tempFile); if (error) { reject(error); } else { resolve(true); } }); }); ``` ### Technical Analysis The `subject`, `htmlContent`, and `to` values are interpolated into AppleScript source. The generated AppleScript is then interpolated again into a shell command passed to `exec`. The expression `htmlContent.replace(/"/g, '"')` replaces a double quote with the same double quote and therefore performs no escaping. A single quote can terminate the shell argument, while AppleScript delimiters can terminate strings and introduce new AppleScript statements. Although this helper is not called by the primary `index.js` flow, it is exported as a reusable project function and becomes exploitable by any caller that supplies untrusted values. ### Attack Path 1. A caller passes attacker-controlled content, subject, or recipient data to `sendViaAppleMail`. 2. The attacker includes shell single quotes or AppleScript string delimiters and executable syntax. 3. The crafted value breaks out of the intended string. 4. `exec` invokes a shell that interprets the injected command, or `osascript` executes injected AppleScript. 5. The payload runs with the privileges of the user executing the Skill. ### Impact ...[truncated 305 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not pass constructed commands through a shell. 2. Replace `exec` with `execFile` or `spawn` using an argument array and `shell: false`. 3. Avoid embedding data in AppleScript source. Pass values through arguments or a structured input channel. 4. Implement correct AppleScript string encoding if AppleScript remains necessary. 5. Validate recipient addresses and constrain subject length and character sets. 6. Prefer Nodemailer's structured API with strict TLS validation. 7. Add tests containing quotes, backslashes, line breaks, command substitutions, and AppleScript delimiters. 8. Apply the same shell-free design to the Sendmail helper. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
index.js:324
Finding
Predictable Temporary Files Permit Symlink and Race Attacks<![CDATA[ ## Vulnerability Details **File Location**: `index.js:324-336`; related instances in `send-mail-applescript.js:17-18` and `send-mail-applescript.js:53-61` **Vulnerability Type**: Unsafe temporary-file handling **Risk Level**: Medium ### Vulnerable Code ```javascript const tempFile = path.join(__dirname, 'email.tmp'); const emailContent = `To: ${CONFIG.email} Subject: ${subject} MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 ${htmlContent} `; fs.writeFileSync(tempFile, emailContent); return new Promise((resolve) => { exec(`/usr/sbin/sendmail -t < "${tempFile}"`, (error) => { fs.unlinkSync(tempFile); ``` Additional fixed names include: ```javascript path.join(__dirname, 'email-temp.html') path.join(__dirname, 'email-temp.txt') ``` ### Technical Analysis The code uses predictable, shared filenames and writes them without exclusive creation or symlink protection. A local attacker with write access to the project directory can pre-create one of these paths as a symbolic link or replace it between the write, send, and delete operations. Concurrent executions can also overwrite or delete each other's temporary content. ### Attack Path 1. An attacker predicts the fixed filename. 2. The attacker creates a symbolic link at that path pointing to another file writable by the victim. 3. The victim runs the Skill. 4. `writeFileSync` follows the link and overwrites the target with generated email content. 5. The subsequent deletion may remove the link, obscuring evidence. 6. Alternatively, concurrent runs replace each other's messages and send unintended content. ### Impact Assessment The practical scope depends on the current user's permissions and project-directory access. Exploitation may overwrite user-owned files, expose report content, corrupt outgoing messages, or cause denial of service. It does not directly grant privileges beyond those held by the Skill process. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Avoid temporary files by sending message content through a child process's standard input. 2. If a file is required, create a private directory with `fs.mkdtemp`. 3. Generate cryptographically unpredictable filenames. 4. Open files with exclusive creation and mode `0600`. 5. Reject symbolic links and verify the opened file descriptor before use. 6. Place cleanup in a `finally` block. 7. Do not reuse a filename between concurrent processes. 8. Apply the same remediation to all three fixed temporary-file paths. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
setup.sh:79
Finding
SMTP Secrets Persisted in Environment Files and Shell Startup Profiles<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:79-110`; related write in `config.js:100-102` **Vulnerability Type**: Insecure credential storage **Risk Level**: High ### Vulnerable Code ```bash SMTP_CONFIG="{\"host\":\"$SMTP_HOST\",\"port\":$SMTP_PORT,\"secure\":false,\"user\":\"$EMAIL_USER\",\"pass\":\"$EMAIL_PASS\",\"from\":\"$EMAIL_USER\"}" cat > .env << EOF SMTP_CONFIG='$SMTP_CONFIG' EOF ``` The setup script can duplicate the password into a shell startup file: ```bash if ! grep -q "SMTP_CONFIG" "$SHELL_RC" 2>/dev/null; then echo "" >> "$SHELL_RC" echo "export SMTP_CONFIG='$SMTP_CONFIG'" >> "$SHELL_RC" fi ``` The JavaScript wizard also writes the complete secret with default permissions: ```javascript const envPath = path.join(__dirname, '.env'); fs.writeFileSync(envPath, `SMTP_CONFIG=${JSON.stringify(smtpConfig)}\n`); ``` ### Technical Analysis SMTP passwords are stored as plaintext without explicitly enforcing restrictive filesystem permissions. The setup process optionally copies the credential into `.zshrc`, `.bashrc`, or `.bash_profile`, increasing its lifetime and exposure. Shell profiles are commonly included in backups, diagnostic bundles, dotfile repositories, and interactive shell processing. Environment variables may also propagate to unrelated child processes. ### Attack Path 1. A user provides an SMTP password to the setup utility. 2. The utility writes it to `.env`. 3. The user optionally allows the same password to be appended to a shell profile. 4. Another local account, backup process, repository operation, support tool, or compromised child process reads the plaintext value. 5. The credential is reused against the SMTP service. ### Impact Assessment Exposure may grant authenticated SMTP access under the configured account. The blast radius is increased by duplicating the secret into persistent user configuration and inherited process environments. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Store SMTP credentials in an operating-system credential manager or dedicated secret service. 2. Do not add SMTP passwords to shell startup files. 3. If `.env` must be supported: - Create it with mode `0600`. - Verify ownership before reading. - Add it to `.gitignore`. - Refuse to operate if permissions are too broad. 4. Keep credentials scoped to the application rather than globally inherited. 5. Use provider-specific application passwords with minimum required privileges. 6. Provide a secure deletion and rotation procedure. 7. Escape or structurally serialize configuration values rather than constructing shell text. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
config.js:52
Finding
Configuration Input Is Written Directly Into Executable JavaScript<![CDATA[ ## Vulnerability Details **File Location**: `config.js:52-60` **Vulnerability Type**: Persistent source-code injection **Risk Level**: Medium ### Vulnerable Code ```javascript indexContent = indexContent.replace( /email:\s*'[^']+'/, `email: '${email}'` ); indexContent = indexContent.replace( /priceLimit:\s*\d+/, `priceLimit: ${price}` ); fs.writeFileSync(indexPath, indexContent); ``` ### Technical Analysis The configuration wizard accepts arbitrary strings for the email address and price limit, then inserts them into `index.js` without validation or JavaScript-safe serialization. A quote in the email value can terminate the intended string literal. The price field can directly contain JavaScript syntax because it is inserted without quoting. The injected source persists and runs during later manual or scheduled executions. This issue requires an attacker to influence configuration input or convince a user to paste a crafted value, but it creates a durable execution path once that occurs. ### Attack Path 1. An attacker supplies or recommends a crafted email or price configuration value. 2. The user enters the value into `config.js`. 3. The wizard rewrites `index.js` with attacker-controlled JavaScript syntax. 4. The modified source remains on disk. 5. A user, cron task, or OpenClaw scheduled job later executes `index.js`. 6. The injected code runs with the Skill user's privileges. ### Impact Assessment Successful exploitation permits arbitrary JavaScript execution as the current user and persists through subsequent scheduled runs. The injected code could read user-accessible files, steal SMTP credentials, alter reports, or establish additional user-level persistence. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Never modify executable source code to store configuration. 2. Store settings in a separate JSON file with a documented schema. 3. Validate email values using a strict address parser. 4. Parse the price as a finite number and enforce an appropriate positive range. 5. Serialize configuration with `JSON.stringify` rather than textual source replacement. 6. Reject unexpected keys and control characters. 7. Create the configuration file with restrictive permissions. 8. Add tests using quotes, semicolons, line breaks, template syntax, and JavaScript expressions. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
index.js:53
Finding
Market Data Is Retrieved Over Plaintext HTTP and Embedded Without HTML Escaping<![CDATA[ ## Vulnerability Details **File Location**: `index.js:53-87`; unsafe rendering at `index.js:175-183` **Vulnerability Type**: Unauthenticated transport and HTML injection **Risk Level**: Medium ### Vulnerable Code ```javascript const apiData = await httpGet( 'http://datacenter-web.eastmoney.com/api/data/v1/get?' + 'sortColumns=APPLY_DATE,SECURITY_CODE&sortTypes=-1,-1&' + 'pageSize=20&pageNumber=1&reportName=RPTA_APP_IPOAPPLY&' + 'columns=SECURITY_CODE,SECURITY_NAME,APPLY_DATE,ISSUE_PRICE,LISTING_DATE&' + 'source=WEB&client=WEB' ); ``` ```javascript const apiUrl = 'http://vip.stock.finance.sina.com.cn/quotes_service/api/json_v2.php/Market_Center.getHQNodeData?' + 'page=1&num=500&sort=symbol&asc=1&node=hs_a&symbol=&_s_r_a=page'; ``` Remote values are inserted directly into HTML: ```javascript <tr> <td>${stock.code}</td> <td>${stock.name}</td> <td>${stock.applyDate || '-'}</td> <td class="price">¥${stock.issuePrice || '-'}</td> <td>${stock.listingDate || '-'}</td> </tr> ``` ### Technical Analysis The data feeds use plaintext HTTP, so the client does not authenticate the server and provides no transport integrity. A network attacker can alter the returned JSON or text. The resulting fields are interpolated into the generated HTML without entity encoding. An attacker able to modify a feed can inject arbitrary HTML into the outgoing report. Mail clients commonly restrict active content, but injected links, images, formatting, and deceptive text can still support phishing or tracking. The same transport weakness also permits manipulation of prices and stock-selection results without requiring markup injection. ### Attack Path 1. An attacker intercepts or redirects one of the plaintext HTTP requests. 2. The attacker returns syntactically valid modified market data. 3. A stock field contains attacker-selected financial information or HTML markup. 4. The Skill accepts the response and embeds the field into the report. 5. The g ...[truncated 501 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace all plaintext HTTP endpoints with provider-supported HTTPS endpoints. 2. Reject redirects that downgrade HTTPS to HTTP. 3. Validate response status codes, content types, maximum sizes, and JSON schemas. 4. HTML-escape every externally sourced value before adding it to the report. 5. Apply numeric and format validation to stock codes, prices, dates, and percentages. 6. Consider adding a Content Security Policy where the output environment supports it. 7. Avoid externally loaded images or links unless explicitly allowlisted. 8. Fail visibly when authenticated data retrieval is unavailable rather than silently sending incomplete or untrusted output. ]]>

T08 · Insecure Dependencies

Note
Location
package-lock.json:15
Finding
Dependency Lockfile Uses a Non-Default Package Mirror<![CDATA[ ## Vulnerability Details **File Location**: `package-lock.json:15-22` **Vulnerability Type**: Additional dependency supply-chain trust boundary **Risk Level**: Low ### Vulnerable Code ```json "node_modules/nodemailer": { "version": "6.10.1", "resolved": "https://registry.npmmirror.com/nodemailer/-/nodemailer-6.10.1.tgz", "integrity": "sha512-Z+iLaBGVaSjbIzQ4pX6XV41HrooLsQ10ZWPUehGmuantvzWoDVBnmsdUcOIDM1t+yPor5pDhVlDESgOMEGxhHA==", "license": "MIT-0", "engines": { "node": ">=6.0.0" } } ``` ### Technical Analysis The lockfile resolves Nodemailer from a non-default npm mirror. The integrity hash provides meaningful protection against an artifact that differs from the locked content, so this is not evidence that the dependency itself is malicious. However, installation relies on an additional distribution service and creates a broader supply-chain trust boundary. Risk increases if integrity enforcement is disabled, the lockfile is regenerated through the mirror, or the resolved artifact and hash are changed together in a future update. ### Attack Path 1. A user follows the documented `npm install` instruction. 2. npm retrieves the dependency from the mirror specified in the lockfile. 3. If the mirror, lockfile update process, or project maintenance account is compromised, a future artifact and matching lock entry may be substituted. 4. The substituted package executes within the Node.js process when required by the Skill. ### Impact Assessment A malicious mail dependency would execute with the same permissions as the Skill and could access SMTP credentials, local report data, and network resources. The currently pinned integrity value reduces immediate exploitability, so the present risk is rated Low. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Regenerate the lockfile using the official npm registry or an organization-controlled verified registry. 2. Pin the dependency to an exact reviewed version rather than a broad range in `package.json`. 3. Retain lockfile integrity verification and use deterministic clean installs. 4. Review lockfile changes during code review, especially changes to `resolved` and `integrity`. 5. Run dependency vulnerability and provenance checks in CI. 6. Restrict who can modify dependency metadata and release artifacts. ]]>

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (84)

Credential Access

High
Category
Privilege Escalation
Content
文件位置：`.env`

```bash
# 编辑 .env 文件，将 YOUR_PASSWORD_HERE 替换为你的邮箱密码
SMTP_CONFIG={"host":"smtp.qiye.aliyun.com","port":465,"secure":true,"user":"8@batype.com","pass":"你的密码","from":"8@batype.com"}
```
Confidence
89% confidence
Finding
The documentation instructs users to place SMTP credentials, including the mailbox username and password, into a `.env` file in plaintext. While common in development, this is dangerous because plaintext secrets are easily exposed through accidental commits, weak file permissions, shell history, backups, or local compromise.

Credential Access

High
Category
Privilege Escalation
Content
cd /Users/batype/.openclaw/workspace-work/skills/astock-daily

# 加载环境变量并运行
source .env && node index.js
```

### 预期输出
Confidence
86% confidence
Finding
The instruction `source .env && node index.js` loads secrets into the shell environment, increasing exposure to subprocess inheritance, debugging output, and accidental leakage during interactive use. In a skill context, this also normalizes handling credentials in an unsafe way without discussing protections.

Credential Access

High
Category
Privilege Escalation
Content
测试运行：
```bash
cd /Users/batype/.openclaw/workspace-work/skills/astock-daily
source .env && node index.js
```
Confidence
86% confidence
Finding
Repeating the `source .env && node index.js` pattern reinforces insecure credential handling and increases the chance that users will expose secrets in shell sessions or automation. The danger is amplified because the file specifically contains SMTP authentication material.

Credential Access

High
Category
Privilege Escalation
Content
# 测试 SMTP 发送
cd /Users/batype/.openclaw/workspace-work/skills/astock-daily
source .env && node index.js
```

---
Confidence
92% confidence
Finding
Sourcing .env imports all variables into the current shell session, which commonly includes credentials such as SMTP usernames, passwords, API keys, or tokens. In combination with running the application, this can expose secrets to logs, child processes, shell history patterns, or unintended code paths, making it more dangerous in an automation skill that users may trust and execute directly.

Credential Access

High
Category
Privilege Escalation
Content
编辑 `.env` 文件：
```bash
cd /Users/batype/.openclaw/workspace-work/skills/astock-daily
vi .env
```

将 `YOUR_PASSWORD_HERE` 替换为你的邮箱密码：
Confidence
97% confidence
Finding
This step explicitly instructs the user to edit a `.env` file and insert their actual email password in plaintext. In the context of a skill repository, that is sensitive credential material that can be leaked via source control, local file exposure, backups, or accidental sharing, making the issue more dangerous than a generic configuration example.

Credential Access

High
Category
Privilege Escalation
Content
```bash
cd /Users/batype/.openclaw/workspace-work/skills/astock-daily
source .env && node index.js
```

检查邮箱是否收到邮件！
Confidence
98% confidence
Finding
Using `source .env && node index.js` loads the secret into the current shell environment, which broadens exposure of the credential to child processes, shell debugging, process inspection in some environments, and user mistakes during troubleshooting. Combined with the prior instruction to store the password in plaintext, this creates a practical credential-handling weakness.

Credential Access

High
Category
Privilege Escalation
Content
```bash
# 编辑文件
vi .env

# 将 YOUR_PASSWORD_HERE 替换为你的邮箱密码
SMTP_CONFIG={"host":"smtp.qiye.aliyun.com","port":465,"secure":true,"user":"8@batype.com","pass":"你的密码","from":"8@batype.com"}
Confidence
95% confidence
Finding
The README instructs users to place an SMTP password directly into a .env file and even includes a real-looking corporate email account in the sample configuration. Storing credentials in plaintext increases the risk of accidental disclosure through local file compromise, shell history, backups, screenshots, or committing the file to version control.

Credential Access

High
Category
Privilege Escalation
Content
console.log('\n或者添加到 ~/.zshrc 或 ~/.bashrc:');
    console.log(`  export SMTP_CONFIG='${JSON.stringify(smtpConfig)}'`);
    
    // 保存到 .env 文件
    const envPath = path.join(__dirname, '.env');
    fs.writeFileSync(envPath, `SMTP_CONFIG=${JSON.stringify(smtpConfig)}\n`);
    console.log(`\n💾 配置已保存到：${envPath}`);
Confidence
98% confidence
Finding
At this point the script persists SMTP_CONFIG containing host, username, and password/auth code to a .env file in plaintext. Because these credentials enable authenticated access to an email-sending account, exposure can lead to account abuse, spam, phishing, mailbox-related compromise, and possible pivoting into other systems that trust that mailbox.

Credential Access

High
Category
Privilege Escalation
Content
console.log(`  export SMTP_CONFIG='${JSON.stringify(smtpConfig)}'`);
    
    // 保存到 .env 文件
    const envPath = path.join(__dirname, '.env');
    fs.writeFileSync(envPath, `SMTP_CONFIG=${JSON.stringify(smtpConfig)}\n`);
    console.log(`\n💾 配置已保存到：${envPath}`);
  }
Confidence
94% confidence
Finding
This finding is effectively the same underlying issue: the generated configuration string includes live SMTP credentials and is then written to a .env file. In the context of a skill setup helper, users may trust the wizard and store sensitive mail credentials locally without realizing the exposure risk, making credential theft more likely through routine development practices.

Known Vulnerable Dependency: nodemailer==6.10.1 — 12 advisory(ies): CVE-2026-82661 (Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary); GHSA-2x7j-588g-ccc2 (Nodemailer: Quadratic (O(n²)) time complexity in addressparser allows remote den); GHSA-8m3c-c648-2xjj (Nodemailer: resolveContent() on a MailMessage bypasses disableFileAccess/disable) +9 more

High
Category
Supply Chain
Confidence
98% confidence
Finding
The lockfile pins nodemailer to version 6.10.1, and the finding indicates multiple published advisories affecting that version, including header injection, denial of service, and security-control bypass issues. Because this is a dependency manifest rather than dead code, the vulnerable package is very likely to be installed and used by the skill at runtime, making this a true supply-chain vulnerability unless mitigations are separately proven.

Known Vulnerable Dependency: nodemailer==6.10.1 — 12 advisory(ies): CVE-2026-82661 (Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary); GHSA-2x7j-588g-ccc2 (Nodemailer: Quadratic (O(n²)) time complexity in addressparser allows remote den); GHSA-8m3c-c648-2xjj (Nodemailer: resolveContent() on a MailMessage bypasses disableFileAccess/disable) +9 more

High
Category
Supply Chain
Confidence
97% confidence
Finding
The project depends on nodemailer in a version range that can include known vulnerable releases, and this skill's stated purpose includes sending email, making the dependency directly relevant to runtime behavior. If a vulnerable version is installed, issues such as header injection, denial of service, or file/content access bypasses could be exploitable through crafted mail inputs or message construction.

Credential Access

High
Category
Privilege Escalation
Content
# 添加新任务
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
CRON_LINE="30 9 * * 1-5 cd $SCRIPT_DIR && source .env && /opt/homebrew/bin/node index.js >> /tmp/astock-daily.log 2>&1"

# 添加到 crontab
(echo "$CURRENT_CRON"; echo "$CRON_LINE") | crontab -
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
# 添加新任务
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
CRON_LINE="30 9 * * 1-5 cd $SCRIPT_DIR && source .env && /opt/homebrew/bin/node index.js >> /tmp/astock-daily.log 2>&1"

# 添加到 crontab
(echo "$CURRENT_CRON"; echo "$CRON_LINE") | crontab -
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
# 添加新任务
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
CRON_LINE="30 9 * * 1-5 cd $SCRIPT_DIR && source .env && /opt/homebrew/bin/node index.js >> /tmp/astock-daily.log 2>&1"

# 添加到 crontab
(echo "$CURRENT_CRON"; echo "$CRON_LINE") | crontab -
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
# 添加新任务
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
CRON_LINE="30 9 * * 1-5 cd $SCRIPT_DIR && source .env && /opt/homebrew/bin/node index.js >> /tmp/astock-daily.log 2>&1"

# 添加到 crontab
(echo "$CURRENT_CRON"; echo "$CRON_LINE") | crontab -
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
echo ""
echo "⚙️  正在保存配置..."

# 保存到 .env 文件
cat > .env << EOF
SMTP_CONFIG='$SMTP_CONFIG'
EOF
Confidence
99% confidence
Finding
At this point the script writes SMTP credentials into a .env file in plaintext. Secrets stored this way are easy to exfiltrate by any local process with access to the working directory, may be accidentally committed to source control, and can persist long after the user expects.

Missing User Warnings

High
Confidence
99% confidence
Finding
The script stores entered email credentials in plaintext in .env and may also append them to shell startup files without warning about the sensitivity of those actions. Plaintext secret storage makes credential theft easier through local compromise, backups, shell history exposure via sourced environments, or accidental inclusion in version control.

Credential Access

High
Category
Privilege Escalation
Content
echo "⚙️  正在保存配置..."

# 保存到 .env 文件
cat > .env << EOF
SMTP_CONFIG='$SMTP_CONFIG'
EOF
Confidence
99% confidence
Finding
This finding reflects the same credential-write operation into .env, which contains the SMTP username and password. Persisting mail credentials in plaintext unnecessarily creates a durable credential exposure point and increases the blast radius of any local compromise.

Credential Access

High
Category
Privilege Escalation
Content
SMTP_CONFIG='$SMTP_CONFIG'
EOF

echo "✅ 配置已保存到 .env 文件"

# 添加到 shell 配置文件
SHELL_RC=""
Confidence
98% confidence
Finding
The script confirms that configuration has been saved to .env, reinforcing that credentials are intentionally persisted in plaintext. In the context of an automation/setup script, this is especially dangerous because users may run it in project directories that are shared, backed up, or version-controlled.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
This markdown file instructs users to run `crontab -r`, which deletes all cron jobs for the user, but the surrounding guidance does not clearly warn about the irreversible impact beyond a brief parenthetical. Under the markdown warning criteria, destructive behavior affecting system configuration should be explicitly disclosed so users understand the risk before running it.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
This is a markdown file, so SQP-2 applies to user-facing documentation. The instructions explicitly tell the user to delete the old task before adding a new one, but they do not warn that `openclaw cron rm` is a destructive action that removes the existing schedule and may interrupt automation if re-creation fails.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The document instructs users to append entries to /etc/hosts using sudo, which makes persistent system-level networking changes with elevated privileges. Even if the goal is legitimate troubleshooting, the guidance lacks warnings about privilege use, rollback steps, and the risk of hard-coding DNS results that may become stale or redirect traffic incorrectly.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
或手动执行：

```bash
sudo sh -c 'echo "47.246.165.89 smtp.qiye.aliyun.com" >> /etc/hosts'
sudo sh -c 'echo "47.246.165.89 smtp.mxhichina.com" >> /etc/hosts'
```
Confidence
89% confidence
Finding
This command uses sudo to modify /etc/hosts, a privileged system configuration file controlling name resolution. If copied without scrutiny, users grant elevated privileges to a shell command that permanently alters network behavior and could enable traffic redirection or operational breakage.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
```bash
sudo sh -c 'echo "47.246.165.89 smtp.qiye.aliyun.com" >> /etc/hosts'
sudo sh -c 'echo "47.246.165.89 smtp.mxhichina.com" >> /etc/hosts'
```

### 方案二：FlClash 规则配置
Confidence
89% confidence
Finding
This is a second privileged /etc/hosts modification for another mail domain, carrying the same risk of persistent DNS override under root privileges. Hard-coded mail server IPs can also age poorly and silently redirect mail traffic if infrastructure changes.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The validation step sources the local .env file and immediately runs the application, which can expose sensitive credentials into the current shell and execute behavior dependent on secrets without any cautionary note. In a skill context, this is risky because users may run it blindly and leak or misuse SMTP credentials stored in .env.

Static analysis

Detected: suspicious.dangerous_exec, suspicious.insecure_tls_verification

Shell command execution detected (child_process).

Critical
Code
suspicious.dangerous_exec
Location
index.js:335

Shell command execution detected (child_process).

Critical
Code
suspicious.dangerous_exec
Location
send-mail-applescript.js:32

HTTPS certificate verification is disabled.

Warn
Code
suspicious.insecure_tls_verification
Location
index.js:280

HTTPS certificate verification is disabled.

Warn
Code
suspicious.insecure_tls_verification
Location
test-smtp.js:14