T09 · Insecure Skill Coding Practices
- Location
python/moonfun_sdk/client.py:31- Finding
Plaintext Image API Allows Interception and Manipulation of Token Content
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This SDK is purpose-aligned but should go to Review because it can spend wallet funds and has unsafe trading and network defaults.
Install only after reviewing the code and use a dedicated low-balance wallet. Avoid the default HTTP image API for sensitive prompts, prefer an HTTPS or self-hosted endpoint, and treat buy/sell methods as risky because quote failures can remove slippage protection. Do not use a main wallet private key with this SDK.
python/moonfun_sdk/client.py:31Plaintext Image API Allows Interception and Manipulation of Token Content
python/moonfun_sdk/trading.py:83Quote Failures Disable Slippage Protection for Buy and Sell Transactions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Environment variables
.env
*.key
secrets/
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
sdk = MoonfunSDK(private_key="0x123...") # Never do this!
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
sdk = MoonfunSDK(private_key="0x123...") # Never do this!
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
sdk = MoonfunSDK(private_key="0x123...") # Never do this!
If quote retrieval fails, the code sets min_received to 0 and still executes the buy, effectively disabling slippage protection. This allows the transaction to clear at any output amount, making the caller vulnerable to extreme price impact, manipulated pools, front-running, or sandwich attacks that can drain most of the value sent.
If quote retrieval fails during a sell, the code sets min_received to 0 and proceeds, removing any lower bound on proceeds. That means the sale can execute for a negligible amount of BNB under adverse pricing or manipulation, exposing users to severe value loss from low-liquidity conditions or MEV exploitation.
This markdown file includes repeated natural-language claims that documentation, comments, variable names, and error messages must be English only, including a dedicated "No Chinese Content" section. That is a language/locale policy constraint, and the file does not present it as an optional preference or justify it as a region-specific compliance requirement.
The README instructs users to place a raw private key in an environment variable but does not clearly warn that environment variables can be exposed through shell history, process inspection, logs, CI systems, or misconfigured hosting environments. In the context of a blockchain SDK, exposure of a private key directly enables wallet compromise and irreversible loss of funds, making this more dangerous than a typical secret-handling documentation issue.
The README states what fields are sent to the hosted image API, including prompt text, but does not prominently warn users that prompts are transmitted to a third-party remote service over the network. Because prompts may contain sensitive project ideas, proprietary content, or personal data, the skill context increases the risk: users may assume the SDK is primarily local and blockchain-focused and overlook off-chain data disclosure.
The guide instructs users to supply a blockchain private key via the PRIVATE_KEY environment variable but does not present a prominent warning about irreversible financial risk, wallet compromise, or best practices such as using a dedicated low-value wallet. In the context of a token-creation/trading SDK that signs transactions and authenticates to remote services, this omission can mislead users into exposing high-value keys to software and environments they may not fully trust.
The README states the image API sends only a signature and address, but the documented create flow necessarily includes user prompt content for image generation. This is a security/privacy documentation flaw because users may make trust decisions based on incorrect assurances and unknowingly send potentially sensitive prompts to a hosted third-party service.
The document makes a strong assurance that the SDK transmits only a narrow set of fields, but elsewhere in the same file it describes additional transmitted data such as prompts, login messages, token metadata, images, and session cookies. In security documentation, inaccurate or incomplete data-flow claims can mislead users into unsafe trust decisions and cause them to omit needed review or monitoring of other outbound data.
The security policy documents an image-generation API endpoint over plain HTTP, which exposes requests to interception and modification in transit. Even if private keys are not sent, the transmitted address, prompt, timestamp, and signature could be observed, replay-attempted within validity windows, or tampered with by an on-path attacker, undermining authentication and privacy guarantees.
The class-level security claim says the private key never leaves the class, but the public private_key property later exposes the raw secret directly. In an SDK auth component, this materially increases the chance of accidental logging, serialization, leakage to plugins, or misuse by downstream code, and it undermines the stated security boundary.
The property at lines 101–104 returns the raw Ethereum private key with no access control, masking, or meaningful friction. In the context of an authentication/signing SDK, exposing the signing key is especially dangerous because any consumer, dependency, debug tool, or compromised integration that can access the object can extract the key and fully impersonate the wallet owner.
The create_token method builds, signs, and broadcasts a blockchain transaction that creates a token and spends BNB, then waits for confirmation. Although the docstring describes the function technically, this file contains no user-facing confirmation, warning message, or explicit disclosure about the irreversible on-chain action and fee expenditure.
The SDK exposes direct buy_token and sell_token methods that can immediately submit blockchain transactions using the caller’s configured private key, with no built-in confirmation, simulation, or guardrails at this layer. In a wallet/trading context this is risky because downstream agents or applications can trigger irreversible financial actions programmatically, increasing the chance of accidental or unauthorized trades if the SDK is used in automation.
This code sends user-provided content and account-identifying/authentication data to a remote API via an HTTP POST. While the module and docstrings describe security properties, they do not disclose to the user that their prompt and wallet/address-related metadata will be transmitted off-box.
On 422 errors, the exception message includes the full request payload, which contains the user prompt, wallet address, timestamp, and cryptographic signature. If exceptions are logged, surfaced to telemetry, or shown to untrusted users, this can leak sensitive data and authentication artifacts beyond their intended scope, increasing privacy exposure and potentially aiding replay or forensic misuse depending on server-side validation.
This code performs a network upload of base64-decoded image content to the platform API, which is a data-transmitting operation. While the docstring describes the function's purpose, there is no confirmation prompt, user-facing notice, or explicit warning about sending user data off-system.
The request transmits descriptive fields, social links, and the creator wallet address to the platform API. Although creating metadata is the method's purpose, the code contains no explicit user-facing disclosure that this information is being sent to an external service.
The sell flow always submits a separate ERC-20 approval transaction before the sale, which changes on-chain state irreversibly even if the later sell fails or the user did not intend to grant spending rights yet. In an SDK context, silently performing approval as part of a sell operation can expose users to unexpected token allowances and additional gas loss, especially if the router address is wrong, compromised, or later misused.
Lines L011-L020 state private keys are used for two purposes only: transaction signing and message signing. Later, the best-practices example creates a wallet and prints its private key (L216-L220), which is a separate handling/use case and contradicts the absolute wording of the earlier statement.
The dependency specification for web3 uses a lower-bound version constraint instead of pinning to an exact known-good release. This makes builds non-reproducible and can cause the environment to resolve to a vulnerable or breaking version over time, especially significant here because web3 has known advisories and interacts with blockchain/network functionality.
web3>=7.0.0
eth-account>=0.13.0
httpx>=0.27.0
requests>=2.31.0
web3 has known advisories, but the manifest does not pin the version, so there is no way to verify whether deployments are using an affected or fixed release. In this context, that uncertainty matters more because web3 may process offchain lookup/network interactions, increasing the relevance of SSRF-class issues if an unsafe version is installed.
No suspicious patterns detected.