T03 · Remote Payload Retrieval and Execution
- Location
README.md:40- Finding
Mutable Remote Script Is Downloaded and Executed Without Verification
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is coherent for an autonomous Solana prediction-market agent, but its setup and default template can execute unverified code and place live wagers too easily.
Install only after reviewing the remote installer or using a local audited setup path. Use a separate minimally funded wallet, avoid valuable keys in .env, start in dry-run or modify the template so it cannot place bets by default, and add hard limits before enabling live wagering or redemption flows.
README.md:40Mutable Remote Script Is Downloaded and Executed Without Verification
example_agent.py:266Default Agent Automatically Places Irreversible Wagers on Every Open Market
requirements.txt:1Security-Sensitive Dependencies Are Not Reproducibly Pinned
Direct execution of a remote shell script is not necessary to explain or use a prediction-market agent template and introduces an unnecessary code-execution channel. In this skill's context, users are likely to run setup on machines that may contain wallet credentials, making arbitrary shell execution materially more dangerous.
The command explicitly fetches a shell script from a remote origin and executes it locally. This is a classic software supply-chain risk because compromise of the remote content or delivery path yields immediate arbitrary code execution on user systems.
One-liner (curl):
curl -fsSL https://app.twzrd.xyz/raw/wzrd-trade.sh | bash
Manual setup:
The '| bash' construct turns downloaded data into executable commands without validation, creating a dangerous chaining pattern. In this skill's context, the same environment may later hold wallet credentials, so successful exploitation could lead to both host compromise and theft of trading keys or funds.
One-liner (curl):
curl -fsSL https://app.twzrd.xyz/raw/wzrd-trade.sh | bash
Manual setup:
The presence of .env usage alone is not inherently malicious, but here it is coupled with instructions to store a wallet private key in that file. That creates a real credential-exposure risk because the secret is highly sensitive and directly enables account control if leaked.
git clone https://github.com/twzrd/twzrd-agent-template cd twzrd-agent-template pip install -r requirements.txt cp .env.example .env
python example_agent.py
This finding refers to the same setup block directing users to create and edit a .env file containing a private key. In the context of a financial agent, credential leakage could let an attacker authenticate as the agent, place trades, and redeem value tied to the wallet.
cd twzrd-agent-template pip install -r requirements.txt cp .env.example .env
python example_agent.py
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Usage:
pip install -r requirements.txt
cp .env.example .env && $EDITOR .env
python example_agent.py
"""
Package name closely resembles a popular package, suggesting possible typosquatting. Attackers publish malicious packages with similar names to trick developers into installing them.
The README instructs users to fetch and immediately execute a remote shell script from the internet. That pattern is dangerous because the fetched content can change at any time, is not pinned or integrity-checked, and would run with the user's local privileges, which is especially risky in a project that also asks users to handle wallet private keys.
Piping curl output straight to bash bypasses normal review and provides no warning about the trust boundary being crossed. If the hosting endpoint, CDN, DNS, or TLS termination were compromised, users could unknowingly execute attacker-controlled commands immediately.
The setup tells users to place a raw Ed25519 private key into a .env file without clear security guidance. Storing long-lived wallet secrets in plaintext environment files increases the risk of accidental disclosure through source control, shell history, backups, logs, or multi-user systems.
The skill exposes significant networked and wallet-adjacent functionality through an MCP server and authenticated trading/redeem flows, but it does not declare any explicit tool scope such as allowed-tools or permissions. In an agent environment, this weakens containment and informed consent because the runtime may permit broader network or environment access than users expect, increasing the chance of unintended external calls or sensitive context exposure.
This skill promotes betting, staking-tier registration, swaps, and redemption/claim actions involving points, tokens, and potentially signed on-chain transactions, but it does not present a prominent warning about financial loss, irreversible submissions, or blockchain settlement risk. In an autonomous-agent context, missing risk disclosure is especially dangerous because an agent may treat market actions as routine API calls rather than high-impact financial operations.
The README promotes autonomous trading and autonomous purchasing agents with direct financial and account-impact capabilities, but does not place clear, proximate warnings beside those entries about loss of funds, unintended trades, API/account misuse, or the need for human approval. In a catalog of AI skills and agents, this can normalize high-risk automation and encourage unsafe adoption by users who may treat listed resources as vetted or low-risk despite only a general disclaimer at the top.
The agent automatically places predictions using client.predict(...) in a continuous loop without any user confirmation, approval threshold, dry-run mode, or hard spending cap beyond the per-bet amount. In this skill’s context, predictions consume account points and can repeatedly execute over time, so a misconfigured strategy or hostile API/market conditions could drain balances or cause unintended trading activity.
The dependency is specified with a minimum version only, which allows different environments to resolve to different aiohttp releases over time. This weakens build reproducibility and can unexpectedly introduce vulnerable or incompatible versions into a security-sensitive bot or market-facing service.
aiohttp>=3.9
base58>=2.1
PyNaCl>=1.5
python-dotenv>=1.0
aiohttp has multiple known advisories, and because no exact version is pinned, it is impossible to verify whether the deployed package is patched. Given this skill appears to support an internet-connected trading or prediction-market bot, an affected aiohttp version could expose the service to request-handling, cookie, or parsing flaws.
Using base58 with only a lower bound permits unreviewed future versions to be installed, reducing reproducibility and supply-chain assurance. While not an immediate exploit by itself, it increases the chance of unexpected behavior or a compromised release being pulled into deployments.
aiohttp>=3.9
base58>=2.1
PyNaCl>=1.5
python-dotenv>=1.0
PyNaCl is a cryptographic dependency, so leaving it unpinned is more sensitive than a typical utility package because cryptographic behavior and bundled native components can change across versions. An unconstrained upper bound increases supply-chain and compatibility risk for software likely handling keys or signatures on Solana.
aiohttp>=3.9
base58>=2.1
PyNaCl>=1.5
python-dotenv>=1.0
PyNaCl has reported advisories, and without version pinning there is no way to confirm whether the installed version includes fixes. Because this package is used for cryptographic operations, any underlying flaw could affect signature validation, key handling, or other security-critical logic in a blockchain-related application.
python-dotenv with only a minimum version allows uncontrolled version drift, which can pull in releases with security regressions or breaking behavior. In an automation or bot context, environment loading often influences secrets and runtime configuration, so deterministic dependency resolution matters.
aiohttp>=3.9
base58>=2.1
PyNaCl>=1.5
python-dotenv>=1.0
python-dotenv has known advisories, and the unpinned requirement makes it unverifiable whether deployments are using a safe release. In services that load secrets and configuration from .env files, a vulnerable version could contribute to file overwrite or unsafe file-handling issues depending on application usage.