T09 · Insecure Skill Coding Practices
Error
- Location
- scan.js.js:92
- Finding
- Confirmed Honeypot Risk Is Incorrectly Downgraded<![CDATA[ ## Vulnerability Details **File Location**: `scan.js.js`, lines 92-97 **Vulnerability Type**: Risk severity overwrite caused by non-monotonic decision logic **Risk Level**: High ### Complete Code Snippet ```js let risk = "LOW"; if (honeypot === true) risk = "HIGH"; if (blacklist_capable) risk = "MEDIUM"; if (mintable && !owner_renounced) risk = "MEDIUM"; ``` ### Technical Analysis The risk checks are independent assignments rather than severity-preserving decisions. Although a positive honeypot result initially sets `risk` to `HIGH`, either subsequent condition can overwrite it with `MEDIUM`. This behavior is especially likely because the implementation's blacklist and mint capability checks inspect the manually supplied local ABI rather than the deployed contract. Those checks therefore tend to produce positive values and trigger the downgrade. A confirmed honeypot is a stronger warning than minting or blacklist capability and must never be reduced by later, lower-severity findings. ### Attack Path 1. An attacker deploys or promotes a token that prevents or severely restricts token sales. 2. A user or automated trading agent scans the token. 3. The external honeypot service returns `isHoneypot: true`. 4. The code temporarily assigns `HIGH`. 5. A later blacklist or mint condition assigns `MEDIUM`. 6. The consumer receives an understated risk classification and may proceed with the trade. ### Impact Assessment An attacker does not obtain local system privileges through this flaw. However, the attacker may influence a security-sensitive trading decision by having a confirmed honeypot represented as only medium risk. The scope includes any bot, agent, or user relying on the scanner's `risk` field. Potential consequences include purchasing an asset that cannot be resold and loss of the funds used in the trade. ]]>
- Remediation
- <![CDATA[ ## Remediation Suggestions Use severity-preserving logic so lower-priority findings cannot overwrite a higher-priority result. For example: ```js let risk = "LOW"; if (honeypot === true) { risk = "HIGH"; } else if (blacklist_capable || (mintable && owner_renounced === false)) { risk = "MEDIUM"; } ``` Alternatively, assign numeric severity scores and retain the maximum severity. Treat unavailable honeypot results separately as `UNKNOWN` rather than implicitly safe. Add regression tests covering combinations such as: - Honeypot only - Honeypot plus blacklist capability - Honeypot plus mint capability - Unknown owner status - Failed external API request Every case with `honeypot === true` must produce `HIGH`. ]]>