Quick Answer
NEAR's sharded, receipt-based execution model eliminates same-frame reentrancy but introduces cross-shard callback state management as a critical audit surface — state must remain consistent even when cross-shard calls fail.
| Vulnerability | Severity | Description | Example |
|---|---|---|---|
| Cross-Shard Call Reentrancy (Receipt Callbacks) | Critical | NEAR's sharded architecture executes cross-contract calls asynchronously via receipts — not in the same transaction frame as EVM external calls. A contract that calls another contract on a different shard and handles the callback must properly manage intermediate state. If state is updated before the callback resolves, a failed cross-shard call may leave state inconsistent, causing balance discrepancies or double-withdrawals. | A NEAR contract that sends tokens to a user on shard B and marks the withdrawal as 'completed' before the cross-shard receipt is processed — if the cross-shard call fails, the local state shows completed but tokens were never transferred. |
| Access Key Privilege Escalation | Critical | NEAR's access key model allows contracts to grant function call access keys with specific method and allowance restrictions. If a contract creates function call keys with too-broad method permissions or NEAR token allowances, or fails to revoke keys after use, an attacker with the key can call any permitted method — including those that drain funds or transfer ownership. | A protocol that creates a function call key with `allowedMethods: null` (all methods permitted) for a worker account — the worker account, or an attacker who compromises it, can call any contract method including admin functions. |
| Borsh Deserialization Vulnerabilities | High | NEAR contracts serialize/deserialize state using Borsh (Binary Object Representation Serializer for Hashing). Incorrect Borsh schema definitions — wrong field ordering, missing fields, or type mismatches — can cause silent deserialization failures where a malicious input decodes to unexpected values. Unlike JSON's error-on-unknown-fields behavior, Borsh is length-prefixed and may silently accept malformed data. | A NEAR contract struct that adds a new field but doesn't migrate existing stored data — when the contract reads old state with the new struct definition, Borsh reads a different number of bytes than expected, interpreting subsequent bytes as different fields. |
| Gas Attachment and Refund Manipulation | High | NEAR requires contracts to attach gas explicitly to cross-contract calls. Incorrect gas attachment — too little (call panics with out-of-gas), or the gas refund routing — can be exploited. If a contract panics after a cross-shard call but the refund callback is not properly handled, the NEAR token refund may be misdirected or lost. | A NEAR contract that makes a cross-contract call with insufficient gas — the cross-contract call panics with `GasExceeded`, but the callback panic leaves the local state in an intermediate position with locked funds and no recovery path. |
| Human-Readable Account Name Phishing | Medium | NEAR uses human-readable account names (like `uniswap.near`, `token.berryclub.near`) instead of hex addresses. Attackers create visually similar account names (`uni5wap.near`, `token.berrrc1ub.near`) to phish users who copy-paste account names from untrusted sources. Contracts that accept user-supplied destination account names without verification can send funds to attacker-controlled lookalike accounts. | A user-facing NEAR transfer function that accepts `destination` as a string parameter — a social engineering attack tricks a user into calling with `uni5wap.near` instead of `uniswap.near`, sending funds to the attacker's account. |