T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:63- Finding
Paper Trading Service Is Installed as a Persistent Root-Level System Service
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent Bybit futures trading skill, but it needs Review because it can place real leveraged orders and recommends persistent root-level deployment with weakly documented safety controls.
Install only if you are prepared to audit and modify it before any live use. Keep API keys restricted to contract trading with no withdrawals, run paper mode manually first, avoid the provided root systemd deployment or convert it to a locked-down user service, disable Telegram unless you accept sending trading details to that chat, and fix the risk-control gaps before connecting real funds.
SKILL.md:63Paper Trading Service Is Installed as a Persistent Root-Level System Service
scripts/risk_manager.py:23Live Trading Risk Limits Fail Open After Restart and Do Not Track Realized Losses
scripts/paper_trading_ws.py:91Paper Trading Bypasses Documented Daily-Loss and Concurrent-Position Controls
SKILL.md:12Dependencies Are Installed Without Version or Integrity Pinning
The skill documents Telegram notifications and other operational behaviors that are not surfaced clearly in the top-level declaration, creating a transparency gap around third-party data flows. In a trading skill that may handle account activity and operational alerts, undeclared outbound messaging materially changes the privacy and security posture.
The skill documents Telegram notifications and other operational behaviors that are not surfaced clearly in the top-level declaration, creating a transparency gap around third-party data flows. In a trading skill that may handle account activity and operational alerts, undeclared outbound messaging materially changes the privacy and security posture.
The instructions tell users to move from paper trading to live execution without an explicit warning that this can place real market orders and cause immediate financial loss. In this context, the omission is especially dangerous because the skill is expressly designed for leveraged futures trading, where mistakes can rapidly liquidate positions.
The skill advertises capabilities that inherently require network, file, and environment access, but it does not declare any explicit tool scope or permissions boundary. That makes the operational surface ambiguous and increases the risk that an agent may invoke the skill with broader access than the user expects, especially given it handles API keys and live trading workflows.
The activation text is extremely broad and could cause the skill to be selected for many generic coding or trading-related requests, including contexts where users did not intend live-trading or credential-handling behavior. Overbroad routing is risky here because the skill spans networked automation, persistent deployment, and real-money execution.
Recommending a systemd service on a VPS normalizes unattended persistent execution for an autonomous trading bot. That increases risk of long-lived unintended behavior, especially when combined with live trading, auto-reconnect, and state persistence features documented elsewhere in the skill.
Recommended: systemd service on a VPS.
# Create service file
sudo tee /etc/systemd/system/paper-trading.service << 'EOF'
[Unit]
Description=Paper Trading Bot (WebSocket)
The documentation instructs use of sudo to write a systemd service file under /etc/systemd/system, which requires elevated privileges and can modify system startup behavior. While common for deployment, embedding privileged commands in a skill increases the chance of unnecessary root use or accidental system-wide changes by users following instructions blindly.
# Create service file
sudo tee /etc/systemd/system/paper-trading.service << 'EOF'
[Unit]
Description=Paper Trading Bot (WebSocket)
After=network.target
Using sudo systemctl enable --now both starts the service and persists it across reboots, requiring elevated privileges and changing the host's startup configuration. In a network-connected trading bot, that persistence can prolong unintended operation or keep a misconfigured bot trading continuously.
WantedBy=multi-user.target EOF
sudo systemctl enable --now paper-trading
## Telegram Notifications
The instructions explicitly enable the bot as a persistent service, causing it to survive reboots and continue operating without interactive oversight. In this skill's context, persistence is more dangerous than usual because the service may perform autonomous trading and continue placing orders or sending data after mistakes or changed conditions.
WantedBy=multi-user.target EOF
sudo systemctl enable --now paper-trading
## Telegram Notifications
The skill encourages Telegram notifications without warning that trade events, timing, errors, and possibly other sensitive operational details are transmitted to a third party. That creates privacy and operational-security risk, particularly for a trading bot where account activity and incident data may be sensitive.
The code sends messages to the Telegram Bot API containing trade opens/closes and periodic account summaries, which transmits potentially sensitive financial activity to an external service. Although the function name implies Telegram use, there is no confirmation prompt or explicit warning comment/docstring near the network call disclosing that user trading data will be sent off-system.
This code transmits trading activity and account summary information to Telegram, a third-party external service, using credentials from local configuration. In the context of a futures trading system, those messages can reveal positions, balances, and strategy behavior, which may create privacy and operational security risk if tokens, chat IDs, or Telegram access are compromised.
if not config.TG_BOT_TOKEN:
return
try:
requests.post(
f"https://api.telegram.org/bot{config.TG_BOT_TOKEN}/sendMessage",
json={"chat_id": config.TG_CHAT_ID, "text": msg, "parse_mode": "HTML"},
timeout=10,
The hardcoded Telegram API endpoint confirms outbound transmission of bot-generated trade data to an external network service. In a trading-bot context, this increases risk because operationally sensitive market actions and account summaries leave the local environment and may be exposed through third-party retention, compromised bot credentials, or misdirected chat configuration.
return
try:
requests.post(
f"https://api.telegram.org/bot{config.TG_BOT_TOKEN}/sendMessage",
json={"chat_id": config.TG_CHAT_ID, "text": msg, "parse_mode": "HTML"},
timeout=10,
)
Skill requests more permissions than appear necessary for its stated functionality. Review if elevated access is justified.
## Account Setup
- Use **Unified Trading Account (UTA)** — supports spot + derivatives in one account
- API permissions: **Read-Write** for Contract. Never enable Assets/Withdrawal for trading bots
- Testnet available at `https://api-testnet.bybit.com` (set `sandbox: true` in ccxt)
## ccxt Configuration
The code makes an external HTTP/API call to Bybit via ccxt to retrieve market data, but the function itself has no docstring, comment, or user-facing notice explaining that external network access will occur. While the main script prints the candle count afterward, it does not disclose the outbound request before or at the point of execution.
The skill writes capital, positions, trades, prices, and timestamps to paper_state.json, which persists potentially sensitive trading records to disk. While logging exists for state loading, there is no nearby disclosure or warning that this data is stored locally.
No suspicious patterns detected.