T09 · Insecure Skill Coding Practices
- Location
lib/tier-detection.sh:87- Finding
<![CDATA[Twitter tier detection can publish an unauthorized tweet before confirmation]]>
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a real social-posting skill, but it needs Review because it can post unexpectedly and gives unsafe local code access to powerful social and wallet credentials.
Install only if you are comfortable granting public posting authority and Farcaster wallet signing authority to shell scripts and external helper code. Prefer waiting for fixes that remove the Twitter write-endpoint tier probe, stop sourcing .env as shell, verify or vendor external helpers, use safer secret storage, and clearly disclose all image and link destinations.
lib/tier-detection.sh:87<![CDATA[Twitter tier detection can publish an unauthorized tweet before confirmation]]>
lib/twitter.sh:6<![CDATA[Credential files are executed as arbitrary shell code]]>
lib/farcaster.sh:53<![CDATA[Sensitive credentials and wallet signing authority are delegated to unverified external code]]>
lib/links.sh:4<![CDATA[Link shortening transmits complete URLs over plaintext HTTP]]>
lib/farcaster.sh:85<![CDATA[Farcaster image uploads disclose files to anonymous third-party hosting services]]>
The documentation directly states that the feature bypasses Twitter anti-spam duplicate-content protections. A skill that markets or supports defeating abuse protections materially increases misuse potential for spam, coordinated amplification, and account network abuse.
The Quick Reference table discloses exact local credential storage locations for both platforms. In isolation this is mild, but in an agent ecosystem it meaningfully lowers the effort for any compromised tool, prompt-injected agent, or local attacker to target known secret paths.
| Platform | Cost | Credentials Location | Setup Time |
|----------|------|---------------------|------------|
| **X/Twitter** | Pay-per-use (consumption-based) | `~/.openclaw/.env` | 5-10 min |
| **Farcaster** | 0.001 USDC/cast | `~/.openclaw/farcaster-credentials.json` | 15-20 min |
**Before first use:**
1. Set up credentials for your platforms (see below)
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
**Step 2: Create App & Generate Keys**
1. Create a new App in Developer Portal
2. Set permissions to "Read and Write"
3. Generate Consumer Key/Secret and Access Token/Secret
**Step 3: Add to .env file**
Location: `/home/phan_harry/.openclaw/.env`
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
**Step 2: Create App & Generate Keys**
1. Create a new App in Developer Portal
2. Set permissions to "Read and Write"
3. Generate Consumer Key/Secret and Access Token/Secret
**Step 3: Add to .env file**
Location: `/home/phan_harry/.openclaw/.env`
The X setup section gives the exact .env path and instructs users to place API secrets there. While common, this exposes a predictable location for credential theft in environments where multiple skills or agents may access the same home directory.
Step 3: Add to .env file
Location: /home/phan_harry/.openclaw/.env
X_CONSUMER_KEY=your_consumer_key
The README explicitly states that another skill will save Farcaster credentials to ~/.openclaw/farcaster-credentials.json, advertising the location of wallet- and signer-related secrets. Because those credentials include private keys capable of spending funds and posting as the user, path disclosure increases the blast radius of any other local compromise.
Option B - Use existing account:
The sample credentials JSON includes fields for custodyPrivateKey and signerPrivateKey, which are highly sensitive and directly security-relevant. Even though the values are truncated examples, documenting the exact schema in plaintext encourages storage and manual handling of secrets that could enable account takeover or wallet abuse if exposed.
Step 2: Verify Credentials File
Location: /home/phan_harry/.openclaw/farcaster-credentials.json
{
"fid": "2684290",
The README tells users to query ~/.openclaw/.env and ~/.openclaw/farcaster-credentials.json directly to verify setup. In an agent-oriented environment, repeatedly identifying these exact secret locations increases the chance that another component targets them for exfiltration or misuse.
1. Check credentials exist:
# Check X/Twitter credentials
grep "^X_CONSUMER_KEY" ~/.openclaw/.env
# Check Farcaster credentials
ls -la ~/.openclaw/farcaster-credentials.json
The verification step directs users to inspect the presence of the Farcaster credentials file at a known location. In a security-sensitive skill that handles private keys, documentation that normalizes direct interaction with secret files increases the risk of accidental disclosure and makes those files easier targets for malicious local tooling.
grep "^X_CONSUMER_KEY" ~/.openclaw/.env
ls -la ~/.openclaw/farcaster-credentials.json
**2. Check Farcaster wallet balance:**
Troubleshooting for .env again discloses the precise secret file path and encourages direct interaction with the file. That is risky because it can lead to accidental display of tokens and makes credential targeting easier for any adversarial local process or prompt-injected agent.
.env file exists: ls -la ~/.openclaw/.envgrep "^X_" ~/.openclaw/.env
chmod 600 ~/.openclaw/.envTroubleshooting guidance again points users to the exact Farcaster credential file path and suggests validating it with jq, which can encourage opening and handling a file that contains private keys. This increases the chance of accidental exposure in terminals, logs, screen shares, or agent-collected command history.
**"Error: Farcaster credentials not found"**
1. Check file exists: `ls -la ~/.openclaw/farcaster-credentials.json`
2. Verify JSON is valid:
```bash
jq . ~/.openclaw/farcaster-credentials.json
The README enumerates required fields including custodyPrivateKey and signerPrivateKey, emphasizing that raw private keys are part of the expected operational setup. In context, these are powerful secrets tied to identity and funds, so normalized plaintext key management is a real security concern, not just a documentation detail.
ls -la ~/.openclaw/farcaster-credentials.jsonjq . ~/.openclaw/farcaster-credentials.json
fid, custodyAddress, custodyPrivateKeyThe skill is presented as a posting tool, but the analyzed behavior reportedly includes local credential reads and blockchain balance checks not clearly foregrounded in the main description. Hidden or underemphasized resource access is security-relevant because it expands the trust boundary beyond what a user expects when enabling a 'social posting' skill.
The skill is presented as a posting tool, but the analyzed behavior reportedly includes local credential reads and blockchain balance checks not clearly foregrounded in the main description. Hidden or underemphasized resource access is security-relevant because it expands the trust boundary beyond what a user expects when enabling a 'social posting' skill.
The skill is presented as a posting tool, but the analyzed behavior reportedly includes local credential reads and blockchain balance checks not clearly foregrounded in the main description. Hidden or underemphasized resource access is security-relevant because it expands the trust boundary beyond what a user expects when enabling a 'social posting' skill.
The instructions direct users to place live API secrets in a plaintext .env file under the home directory. This is a common but risky pattern because local compromise, accidental backups, permissive file permissions, or tool overreach can expose credentials that enable account takeover or abuse.
echo "X_CONSUMER_KEY=xxx" >> ~/.openclaw/.env
echo "X_CONSUMER_SECRET=xxx" >> ~/.openclaw/.env
The documented storage of consumer and access secrets in ~/.openclaw/.env exposes powerful API credentials to any process or actor that can read that file. In an agent ecosystem with shell and file capabilities, plaintext credential storage substantially increases blast radius.
echo "X_CONSUMER_KEY=xxx" >> ~/.openclaw/.env
echo "X_CONSUMER_SECRET=xxx" >> ~/.openclaw/.env
echo "X_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env
echo "X_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
Access tokens stored in plaintext are directly usable to post or act on behalf of the account if disclosed. Because this skill automates public actions, leaked tokens could be immediately abused for spam, impersonation, or reputational damage.
echo "X_CONSUMER_KEY=xxx" >> ~/.openclaw/.env
echo "X_CONSUMER_SECRET=xxx" >> ~/.openclaw/.env
echo "X_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env
echo "X_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
Storing token secrets in ~/.openclaw/.env is sensitive because these secrets are sufficient to authenticate write operations to external social APIs. Any unintended read access by other skills, logs, or system users could enable account compromise.
echo "X_CONSUMER_KEY=xxx" >> ~/.openclaw/.env
echo "X_CONSUMER_SECRET=xxx" >> ~/.openclaw/.env
echo "X_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env
echo "X_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
The general instruction to append secrets into a home-directory .env file reinforces insecure secret-handling practices. While documentation itself is not exploitation, it normalizes a storage pattern that weakens overall credential hygiene in the deployment environment.
echo "X_CONSUMER_KEY=xxx" >> ~/.openclaw/.env echo "X_CONSUMER_SECRET=xxx" >> ~/.openclaw/.env echo "X_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env echo "X_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
**Test your credentials:**
Multi-account support multiplies the number of plaintext credentials stored in one file, increasing the impact of a single file disclosure. A compromise would expose multiple social identities at once, making abuse and recovery more severe.
# Add credentials with custom prefix (e.g., MYACCOUNT_)
echo "MYACCOUNT_API_KEY=xxx" >> ~/.openclaw/.env
echo "MYACCOUNT_API_KEY_SECRET=xxx" >> ~/.openclaw/.env
echo "MYACCOUNT_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env
echo "MYACCOUNT_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
Additional API key secrets for multiple accounts expand the secret surface and account-compromise blast radius. In a skill with shell/file capabilities, consolidated plaintext secret storage is particularly risky.
# Add credentials with custom prefix (e.g., MYACCOUNT_)
echo "MYACCOUNT_API_KEY=xxx" >> ~/.openclaw/.env
echo "MYACCOUNT_API_KEY_SECRET=xxx" >> ~/.openclaw/.env
echo "MYACCOUNT_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env
echo "MYACCOUNT_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
Documented plaintext storage of multiple access tokens creates a straightforward target for exfiltration. Because these tokens enable public posting, misuse could impact several brands or personas simultaneously.
echo "MYACCOUNT_API_KEY=xxx" >> ~/.openclaw/.env echo "MYACCOUNT_API_KEY_SECRET=xxx" >> ~/.openclaw/.env echo "MYACCOUNT_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env echo "MYACCOUNT_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
Persisting multiple token secrets in a shared .env file increases exposure and operational risk. This is especially dangerous in environments where several skills may have broad filesystem access or where backups/logs include home-directory artifacts.
echo "MYACCOUNT_API_KEY=xxx" >> ~/.openclaw/.env echo "MYACCOUNT_API_KEY_SECRET=xxx" >> ~/.openclaw/.env echo "MYACCOUNT_ACCESS_TOKEN=xxx" >> ~/.openclaw/.env echo "MYACCOUNT_ACCESS_TOKEN_SECRET=xxx" >> ~/.openclaw/.env
**Usage:**
The skill depends on reading a local JSON file containing Farcaster private keys and wallet information. Handling plaintext long-lived credentials is inherently sensitive; compromise of the skill, its execution environment, or logs could lead to account takeover and financial loss from wallet misuse.
Required credentials (stored in /home/phan_harry/.openclaw/farcaster-credentials.json):
{
"fid": "your_farcaster_id",
No suspicious patterns detected.