T09 · Insecure Skill Coding Practices
- Location
SYSTEMD_SETUP.md:53- Finding
Unnecessary Persistent Storage of the Wallet Private Key
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a real Polymarket scanning/trading skill, but its setup instructions repeatedly encourage storing a powerful wallet private key in long-lived files even though the bot does not need it at runtime.
Review carefully before installing. Do not store a real wallet private key in systemd, ~/.bashrc, a project .env, or /etc/polymarket-oracle/credentials.env. If testing, use simulation mode or a low-value wallet, generate API credentials on a trusted local machine, remove WALLET_PRIVATE_KEY from runtime configuration, pin and verify dependencies used for credential generation, and confirm the code’s actual trading behavior before using real funds.
SYSTEMD_SETUP.md:53Unnecessary Persistent Storage of the Wallet Private Key
CONFIGURATION.md:50Unpinned Third-Party Package Used in Wallet Credential Generation
The systemd example embeds WALLET_PRIVATE_KEY directly in the unit configuration even though the guide previously says the private key must never be stored on the server. A systemd unit may be readable by privileged support tooling, backups, misconfigured permissions, process inspection, or accidental sharing, and exposure of this key grants irreversible full wallet control and fund theft.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# On your SERVER (where bot runs)
# Create secure credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Paste ONLY these (NO private key!):
POLYMARKET_API_KEY=your_api_key_from_step1
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
❌ Commit WALLET_PRIVATE_KEY to git
❌ Store private key anywhere long-term
# ❌ NEVER use .env file in project directory
❌ cat > .env << 'EOF'
❌ WALLET_PRIVATE_KEY="..."
❌ EOF
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
❌ Commit WALLET_PRIVATE_KEY to git
❌ Store private key anywhere long-term
# ❌ NEVER use .env file in project directory
❌ cat > .env << 'EOF'
❌ WALLET_PRIVATE_KEY="..."
❌ EOF
The stray 'chmod 600 .env' line appears immediately after a section warning never to use a project .env for the private key, creating contradictory guidance around local secret storage. Even though chmod tightens permissions, this inconsistency can normalize creation of a project-directory .env that may later contain sensitive material and be accidentally committed, backed up, or exposed.
The bot code uses ONLY API credentials at runtime.
chmod 600 .env
---
The document explicitly states the wallet private key is only needed once and must never be stored on the server, but later instructs users to export and persist WALLET_PRIVATE_KEY in their shell environment and startup files. This contradiction can lead operators to store a full-control blockchain secret long-term on disk, making theft via local compromise, backups, logs, shell history, or config disclosure far more damaging than exposure of limited-scope API keys.
The configuration section instructs users to store the wallet private key in environment variables and to make it permanent in ~/.bashrc or ~/.zshrc, despite earlier advice forbidding long-term server storage. Persisting secrets in shell startup files increases exposure through backups, home directory compromise, debug output, and accidental disclosure to other tools or users on the host.
The unit file example places multiple secrets directly in the service definition, including the wallet private key, without a local warning in that section. Inline secrets in unit files are easy to mishandle operationally and especially dangerous here because one of them is a non-revocable wallet key that enables total asset compromise.
The documented purpose emphasizes scanning and arbitrage detection, but the skill also describes authenticated order placement, Telegram transmission, and local data persistence that are not clearly bounded in the high-level description. This mismatch is dangerous because users or orchestration systems may invoke what appears to be an analysis tool while actually authorizing real-money execution and external data transfer.
The documented capability includes authenticated POST /order and DELETE /order operations, enabling the skill to place and cancel live market orders. In a real-money trading environment, this is dangerous if exposed without strict parameter validation, explicit authorization boundaries, and execution controls, because malformed or abused parameters can trigger unintended trades, excessive churn, or financial loss.
GET /midpoint?token_id={id} - Midpoint price GET /price?token_id={id}&side={BUY/SELL} - Best price POST /order - Place order DELETE /order - Cancel order
Rate limit: Public 60/min, Authenticated 100/min
The documentation tells users to create a plaintext credentials file containing exchange secrets, a wallet private key, and messaging tokens. Even with restrictive permissions, plaintext secret files on disk remain high-value targets for local compromise, backup leakage, operator mishandling, or accidental exposure, especially given the presence of a private key that can authorize trades and move funds.
# Create credentials file
sudo mkdir -p /etc/polymarket-oracle
sudo nano /etc/polymarket-oracle/credentials.env
# Content:
POLYMARKET_API_KEY=your_key
The parity arbitrage detector fabricates the NO price as 1.0 - yes_price instead of querying the actual opposing market price, so yes_price + no_price will always equal 1 and meaningful arbitrage detection cannot occur. In an automated trading bot, flawed strategy logic can cause systematically incorrect signals, missed opportunities, or unsafe execution decisions if later extended to trading, creating direct financial risk.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
## Step 1: Polymarket Account Setup
### **Create Account**
1. Go to https://polymarket.com
2. Click "Connect Wallet"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
POLYMARKET_CAPITAL=10000
sudo chmod 600 /etc/polymarket-oracle/credentials.env sudo chown root:root /etc/polymarket-oracle/credentials.env
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
POLYMARKET_CAPITAL=10000
sudo chmod 600 /etc/polymarket-oracle/credentials.env sudo chown root:root /etc/polymarket-oracle/credentials.env
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
POLYMARKET_CAPITAL=10000
sudo chmod 600 /etc/polymarket-oracle/credentials.env sudo chown root:root /etc/polymarket-oracle/credentials.env
The 'Make Permanent' section tells users to place secrets, including WALLET_PRIVATE_KEY, into ~/.bashrc or ~/.zshrc for automatic loading. That creates long-lived secret persistence in common user files that are broadly exposed to backups, support access, accidental sharing, and post-compromise harvesting, and it directly conflicts with the earlier rule never to store the private key long-term.
# Add to ~/.bashrc or ~/.zshrc
cat >> ~/.bashrc << 'EOF'
# Polymarket Oracle
export POLYMARKET_API_KEY="..."
No suspicious patterns detected.