Date of engagement: 12th February 2025 - 5th March 2025
-
Timur GüvenkayaPrincipal advisor -
Michal BajorSpecialist
Engagement Dashboard
Audit results
Guvenkaya conducted a security assessment of the NEAR Intents from 12th February 2025 to 5th March 2025. NEAR Intents are a new type of transaction that allow information, requests, assets, and actions to be exchanged between AI agents, services, and end users. During this engagement, a total of 4 findings were reported. 1 of the findings was medium and the remaining were either low or informational severity. The NEAR Intents team has not fixed the issues yet.
Engagement record
- Client
- NEAR Intents
- System
- NEAR Intents smart contracts
- Review period
- 12th February 2025 - 5th March 2025
- Reviewed baseline
6da9e2b3ab598f277d45fb356aee01a5d80ac0a6- Paths in scope
- 103
- Principal advisor
- Timur Güvenkaya
- Specialist
- Michal Bajor
Timeline
- Review start12th February 2025
- Draft report5th March 2025
Findings by severity
Finding status at final report
Remediation complexity
Impact
Likelihood
Advisory and Client
The advisory
Guvenkaya specializes in security for digital assets and financial infrastructure, from smart contracts and protocols to applications, infrastructure, custody and cryptography.
Our team, including the sitting Heads of Security at Gauntlet and Agora, brings experience from Kraken, OpenZeppelin, Binance, ZKsync, Nillion, Invicti and EY. Across the team: 200+ security reviews, $30B+ in volume secured, 13 published cryptography research papers, and credentials including OSCP, OSWE and CISM.
- Every reviewer has a public bio and is named before you sign. We match expertise to your system, with a principal leading scoping and checking findings.
The client
NEAR Intents is a cross-chain liquidity protocol for swaps, payments and asset onboarding. Users specify the assets and outcome they want, while the system coordinates routing and execution across supported blockchains. Wallets, applications and agents can integrate these capabilities into their own products.
Applications obtain quotes from competing solvers. Signed intents express the authorized asset movements, which the Verifier contract validates and executes on NEAR. Developers can integrate through a widget or API; the 1Click API handles quote requests, intent creation and execution tracking, reducing the need to build separate integrations for each supported chain and asset pair.
- Cross-chain swaps let users exchange an asset on one network for an asset on another.
- Cross-pay lets a sender use one token while the recipient receives a preferred asset on another supported chain.
- Asset onboarding lets a wallet or application accept deposits from a user's existing chain through the same network.
Scope and Review Boundaries
Review depths
- Deep
- Line-by-line review with explicit attack hypotheses, adversarial reasoning about state transitions, and reproduction attempts for each hypothesis that survived reading.
- Supporting
- The code was read for its effect on a reviewed flow. Behaviour outside that effect was not assessed.
- Targeted
- Entry points were exercised or triaged against the flow's security properties rather than read in full.
This is the code we read, and how closely. 103 paths are in scope. Each path links to the file at the reviewed commit.
Out of scope
The audit will include reviewing the code for security vulnerabilities. The audit does not include a review of the tests and dependencies.
Assessment Framework
Guvenkaya rates findings by likelihood and impact so remediation can be prioritized by technical risk, business context, and the decision the engagement is meant to support.
Rating chain applied to every finding
- 01 Likelihood Likely, possible or rare
- 02 Impact Severe, moderate or negligible
- 03 Severity Derived from the matrix below
- 04 Remediation complexity Simple, moderate or difficult
- 05 Status Not fixed, fixed, acknowledged or scheduled
Impact
| Impact | What it means here |
|---|---|
| Severe | Exploitation could result in critical loss or compromise, such as full system control, substantial financial loss, or severe reputational damage. |
| Moderate | Exploitation may lead to limited data loss, partial compromise, moderate financial impact, or noticeable degradation of services. |
| Negligible | Exploitation has minimal impact, such as minor data exposure without significant consequences or slight inconvenience without substantial disruption. |
Likelihood
| Likelihood | What it means here |
|---|---|
| Likely | The vulnerability is easily discoverable and not overly complex to exploit. |
| Possible | The vulnerability presents some challenges either in discovery or in the complexity of the attack. |
| Rare | The vulnerability is either very difficult to discover or complex to exploit, or both. |
This matrix provides a nuanced view, taking into account both the ease of discovering a vulnerability and the complexity involved in exploiting it.
| Attack Complexity \ Discovery Ease | Obvious | Concealed | Hidden |
|---|---|---|---|
| Complex | Possible | Rare | Rare |
| Moderate | Likely | Possible | Rare |
| Straightforward | Likely | Possible | Possible |
Severity
| Severity | What it means here |
|---|---|
| Critical | Assigned to vulnerabilities with severe impact and a likely likelihood of exploitation. |
| High | For vulnerabilities with either severe impact but only a possible likelihood, or moderate impact with a likely likelihood. |
| Medium | Used for vulnerabilities with severe impact but a rare likelihood, moderate impact with a possible likelihood, or negligible impact with a likely likelihood. |
| Low | For vulnerabilities with moderate impact and rare likelihood, or negligible impact with a possible likelihood. |
| Informational | The lowest severity rating, typically for vulnerabilities with negligible impact and a rare likelihood of exploitation. |
| Likelihood \ Impact | Severe | Moderate | Negligible |
|---|---|---|---|
| Likely | Critical | High | Medium |
| Possible | High | Medium | Low |
| Rare | Medium | Low | Informational |
Remediation complexity
This measures how difficult it is to remediate a finding once it has been identified.
| Remediation complexity | What it means here |
|---|---|
| Simple | Patches or fixes are readily available and easily implemented. |
| Moderate | Requires some time and resources to remediate, but well within the capabilities of most organizations. |
| Difficult | Remediation requires significant resources, specialized skills, or substantial changes to systems or architecture. |
Finding status
This tracks the client's response to each finding and whether remediation has been completed, accepted, or scheduled.
| Status | What it means here |
|---|---|
| Not Fixed | Indicates that the vulnerability has been identified but no remedial action has been taken yet. This status is crucial for newly discovered vulnerabilities or those awaiting prioritization. |
| Fixed | This status is applied when the vulnerability has been successfully remediated. It implies that appropriate measures, such as patching, configuration changes, or architectural modifications, have been implemented to resolve the issue. |
| Acknowledged | This status is used for vulnerabilities that have been recognized, but for various reasons (such as risk acceptance, cost, or other business decisions), have not been fixed. It indicates that the risk posed by the vulnerability is known and has been consciously accepted. |
| Scheduled | This status indicates that the vulnerability has been acknowledged and a plan is in place to fix it in the future. It signifies that while remediation hasn't yet occurred, the issue has been prioritized and is part of the planned development roadmap. |
Findings Summary
Findings register
| Finding | Impact | Likelihood | Severity | Remediation complexity | Status |
|---|---|---|---|---|---|
| GUV-1: Potential Funds Stealing From Users Via Repeating Failed Intents | Severe | Rare | Medium | Simple | Scheduled |
| GUV-2: Possible DoS Of Public Keys Viewing Per User | Negligible | Possible | Low | Simple | Not Fixed |
| GUV-3: Arbitrary Public Key Setting In Privileged Functions | Negligible | Rare | Informational | Simple | Not Fixed |
| GUV-4: Missing Event Emission For Critical Access Control Operations | Negligible | Rare | Informational | Simple | Not Fixed |
Detailed Findings
GUV-1: Potential Funds Stealing From Users Via Repeating Failed Intents
Description
Depending on the intent structure, it's possible to maliciously fail a transaction and then repeat specific intents, which could lead to:
- Stealing tokens
- Making solvers lose money or perform unauthorized operations
Mainnet deadlines are permissive, ranging from 20 seconds to 10 minutes. This provides ample time to fail a transaction and repeat failed intents. A transaction can be failed by:
- Invalidating the nonce after signing in a separate transaction.
- Adding an additional intent to your intent array that transfers funds out and fails your token diff
Malicious actor can:
- Repeat selected intents.
- Repeat selected intents and, to maintain
TokenDiffbalance, resign your controlled intents with new values. - Observe failed intents on the blockchain and reconstruct them like building blocks (while deadlines remain valid).
The risk is low when TokenDiff intent is used, as mainnet calculations are typically precise, making it difficult to modify the intent structure while maintaining zero delta and gaining benefits. The vulnerability is particularly dangerous in P2P transfer scenarios where TokenDiff intent isn't used, allowing for immediate exploitation with high success rates.
Impact
Funds can be stolen in scenarios where TokenDiff intent isn't used.
Recommendation
This behavior should be documented to emphasize that TokenDiff is the preferred method, while Transfer should be discouraged for facilitating swaps. Users must understand they are responsible for reviewing and approving what they sign.
Remediation
The NEAR Intents team has acknowledged the issue and will fix it soon by documenting this scenario.
GUV-2: Possible DoS Of Public Keys Viewing Per User
Description
It was observed that since user can have unlimited public keys, it is possible for a malicious user to cause a DoS of public_keys_of method when their account is used. That’s because public_keys_of iterates over public keys of a provided account and if account has a lot of public keys it can lead to the error due to a gas limit.
fn public_keys_of(&self, account_id: &AccountId) -> HashSet<PublicKey> { self.accounts.get(account_id).map_or_else( || { PublicKey::from_implicit_account_id(account_id) .into_iter() .collect() }, |account| account.iter_public_keys(account_id).collect(), )}Impact
- Errors in off-chain components, which utilize
public_keys_ofmethod. - If
iter_public_keysis utilized within the smart contract logic somewhere else, depending on a logic it can lead to the DoS on protocol level
Recommendation
It is recommended to limit the number of public keys each account can have
Remediation
The NEAR Intents team has not fixed the issue yet.
GUV-3: Arbitrary Public Key Setting In Privileged Functions
Description
The codebase accepts public keys in multiple locations without proper validation. The NEAR SDK's PublicKey type lacks comprehensive validation of public key formats and values. Malicious users could potentially inject invalid or malformed public keys, leading to undefined behavior in cryptographic operations.
PoC
fn test_parse_zero_pubkey() {use near_sdk::PublicKey;let zero_pubkey_str = "ed25519:11111111111111111111111111111111";let result = zero_pubkey_str.parse::<PublicKey>();assert!(result.is_err());}Impact
- Potential undefined behavior in cryptographic operations
- Potential injection of weak public keys that can lead to signature malleability
Recommendation
Implement comprehensive validation for public keys in all relevant functions.
- Account Public Key Management (add_public_key, remove_public_key)
- Relayer Keys Management (do_add_relayer_key, delete_relayer_key)
- Full Access Keys Management (add_full_access_key, delete_key)
Remediation
The NEAR Intents team has not fixed the issue yet.
GUV-4: Missing Event Emission For Critical Access Control Operations
Description
The relayer keys operations lacks event emissions for access control operations in delete_relayer_key() and do_add_relayer_key() methods. This omission makes it difficult to track and audit changes to the relayer key set off-chain. Events are essential for maintaining transparency and allowing external systems to monitor and react to important state changes in the contract.
Recommendation
Implement event emissions for both adding and removing relayer keys
Remediation
The NEAR Intents team has not fixed the issue yet.
The web version and the PDF (19 pages) are generated from the same source. The report as first delivered is kept in the public reports archive.