A Meme Dog (AMD) security report
Radar AI scanned A Meme Dog on Ethereum and found a critical source-level allowance bypass: the deployer can use transferFrom without holder approval.
A Meme Dog has a critical source-level permission flaw: the deployer can call transferFrom for arbitrary token holders without their approval, subject to the holders having token balances. This creates a direct path to unauthorized token transfers.
Trust score: 20/100. Source verified: Yes. Chain: ethereum. Contract: 0x4cdeb26516a8d1f2cc07050166c5ba6e79346d76.
This report was last modified on 2026-11-04 and contains 2 material findings.
critical finding: Deployer can bypass transferFrom allowances
The constructor marks the deployer address in isExile. Every transfer invokes _transfer, which stores whether tx.origin is marked. During transferFrom, _spendAllowance skips the allowance validation whenever that stored flag is true. Consequently, a transaction originating from the deployer can transfer tokens from arbitrary addresses without an allowance.
Evidence: In ERC20's constructor, isExile[msg.sender] = true. In _transfer, bunnyhop = isExile[tx.origin] is written to transient storage slot 192. In _spendAllowance, the condition if (!vigod && currentAllowance < type(uint256).max) prevents all allowance validation when vigod is true. transferFrom calls _transfer before _spendAllowance, so the deployer can invoke transferFrom(from, to, value) without approval from from, provided from has sufficient balance.
Recommendation: Remove the tx.origin-based authorization and transient-storage bypass. Use the standard ERC-20 allowance check for every transferFrom call, and redeploy the token because the deployed contract's behavior cannot be safely corrected without an upgrade mechanism, which this contract does not expose.
medium finding: Authorization depends on tx.origin across call chains
The token uses tx.origin rather than the immediate caller to determine whether allowance checks are bypassed. Any transaction initiated by the marked deployer inherits this privileged behavior through intermediary contracts, making authorization dependent on the entire external call chain rather than the approved spender.
Evidence: _transfer evaluates isExile[tx.origin], stores the result in transient storage, and _spendAllowance reads that value to decide whether to enforce allowance checks. The constructor marks the deployment sender, while no function can remove that marker.
Recommendation: Do not use tx.origin for token authorization. Enforce spender approval based on msg.sender and the allowance mapping on every transferFrom execution. Treat the existing deployment as having a persistent privileged transfer path.