T09 · Insecure Skill Coding Practices
- Location
references/contracts.md:29- Finding
Untrusted user data can assign verification status to an arbitrary address
- Content
View full analysis
Vulnerability Details
File Location:
references/contracts.md, lines 29–35
Vulnerability Type: Authorization bypass through untrusted identity binding
Risk Level: Highsolidity function customVerificationHook( bytes memory output, bytes memory userData ) internal override { address user = abi.decode(userData, (address)); verified[user] = true; }Technical Analysis
The verification callback ignores the verified proof output and derives the account receiving verification status exclusively from
userData. According to the documented flow, the user supplies the corresponding context data when submitting a proof.The example does not validate that the decoded address is cryptographically bound to the proof subject, an authenticated caller, or a trusted public signal. Consequently, possession of a valid proof may be sufficient to mark an unrelated address as verified.
Attack Path
- An attacker obtains or generates a valid identity proof.
- The attacker encodes a target address in the user-controlled context data.
- The attacker submits the valid proof together with the encoded target address.
- Hub V2 validates the proof and invokes the verification callback.
customVerificationHookdecodes the attacker-selected address without checking its relationship to the proof.- The contract executes
verified[target] = true, granting verification status to the selected account.
Impact Assessment
An attacker with one valid proof could potentially confer verified status on an arbitrary account. If downstream logic relies on
verified[address]for KYC enforcement, token gating, airdrop eligibility, governance, or restricted access, an account that has not independently completed identity verification could receive those privileges.The precise scope depends on how the mapping is used by the integrating contract and associated applications.
- Remediation
View remediation
Remediation Suggestions
- Bind the credited address to a proof-authenticated public signal or another value cryptographically covered by the proof.
- If verification is intended for the transaction initiator, use a trusted caller identity and ensure the callback architecture preserves and validates that binding.
- Explicitly compare the decoded address with the authenticated proof subject before modifying state.
- Reject zero addresses, malformed context data, and any identity mismatch.
- Track and consume scope-bound nullifiers where one-time or Sybil-resistant verification is required.
- Avoid using untrusted context data as an authorization principal unless it has been authenticated.
- Add negative tests demonstrating that a valid proof cannot verify an arbitrary third-party address or reuse a nullifier to grant benefits repeatedly.